Xcode - An Apple Embarrassment

Cannot see strings in 4.3 …. and 4.3 sure does do goofy things …. lots of (Empty editor) entries in the Window menu which propagate to the 4.2.1 window menu.

I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.

After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.

Apple and Xcode are an embarrassment to professional software development.

Come on Apple, get with it or give back MPW at least it did not crash all the time.

What is it called in software development when you're introducing bugs faster than you're fixing them? Because this is the problem the Xcode development team is facing here.

Apple should clearly get some serious Q&A people on Xcode!

On 28 févr. 2012, at 19:37, koko <koko...> wrote:

> Cannot see strings in 4.3 …. and 4.3 sure does do goofy things …. lots of (Empty editor) entries in the Window menu which propagate to the 4.2.1 window menu.
>
> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.
>
> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
>
> Apple and Xcode are an embarrassment to professional software development.
>
> Come on Apple, get with it or give back MPW at least it did not crash all the time.
>
> -koko
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<tclementdev...>
>
> This email sent to <tclementdev...>

> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.

Might be an LLDB issue. Try switching the debugger back to GDB. I haven’t tried LLDB myself but by many reports it’s not quite ready for prime time yet.

> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
> Apple and Xcode are an embarrassment to professional software development.

Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)

> What is it called in software development when you're introducing bugs faster than you're fixing them? Because this is the problem the Xcode development team is facing here.

Alpha.

> On 28 févr. 2012, at 19:37, koko <koko...> wrote:
> >> Cannot see strings in 4.3 …. and 4.3 sure does do goofy things …. lots of (Empty editor) entries in the Window menu which propagate to the 4.2.1 window menu.
>>
>> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.
>>
>> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
>>
>> Apple and Xcode are an embarrassment to professional software development.
>>
>> Come on Apple, get with it or give back MPW at least it did not crash all the time.
>>
>> -koko

>
> On Feb 28, 2012, at 10:37 AM, koko wrote:
> >> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.>
> Might be an LLDB issue. Try switching the debugger back to GDB. I haven’t tried LLDB myself but by many reports it’s not quite ready for prime time yet.
> >> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
>> Apple and Xcode are an embarrassment to professional software development.>
> Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)
>
> —Jens

>
>
> Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)
>
> —Jens
>

While I'm aware how easy it is to get over-exercised about frustrations with dev tools, I think the problems with Xcode 4 are worse than you suggest. That's certainly the impression I get from others' comments in the twitterverse etc, though clearly that's hard to gauge, subject to lots of silliness, etc. But many really smart people have lost faith in Xcode.

I was an Xcode defender early on, being initially very pleased by its design clarity and consistency. But I've found myself ground down by time wasted by crashes, interaction design problems, and implementation infelicities. That all this comes from a *released* product from the richest company in the world makes it clear to me that something is deeply wrong with the Xcode 4 project as a whole. Hopefully Apple can do the rabbit-trick and somehow turn it around, but I need tools that work smoothly, right now.

For now my solution has been to surrender and use JetBrains' AppCode, which lacks surface elegance, and suffers from clutter, but is for the most part a pleasure to actually write code in.

>
>
> Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)
>
> —Jens
>

While I'm aware how easy it is to get over-exercised about frustrations with dev tools, I think the problems with Xcode 4 are worse than you suggest. That's certainly the impression I get from others' comments in the twitterverse etc, though clearly that's hard to gauge, subject to lots of silliness, etc. But many really smart people have lost faith in Xcode.

I was an Xcode defender early on, being initially very pleased by its design clarity and consistency. But I've found myself ground down by time wasted by crashes, interaction design problems, and implementation infelicities. That all this comes from a *released* product from the richest company in the world makes it clear to me that something is deeply wrong with the Xcode 4 project as a whole. Hopefully Apple can do the rabbit-trick and somehow turn it around, but I need tools that work smoothly, right now.

For now my solution has been to surrender and use JetBrains' AppCode, which lacks surface elegance, and suffers from clutter, but is for the most part a pleasure to actually write code in.

You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options. You mention VS specifically.

Visual Studio is a nice tool, but then again, the C++ tool chain has not changed in any significant manner in over 7 years, and has in many ways regressed from the Vs6 days. visual Studio is a good tool for .net development, particularly in the c# world. For C++ it is a mediocre tool, at best, and is handicapped by inconsistent behaviors of the underlying frameworks. Like Xcode, it is not perfect, I crashed it three times today working with cross platform STL code.

But look deeper. What about other tools, like Delphi, or RealStudio., or even the open source MonoDevelop. Delphi is probably more like Xcode in terms of what it does with it's integrated UI tools, and it's robust underlying framework(s). With current versions, you can target windows or OS x with the same code base. It works, but I crash it multiple times a day as well.

MonoDevelop? Great tool, nice workable tool chain. Kicks off much of visual studio, it crashes often and strangely.

But here is the thing, Xcode and Visual Studio are platform specific, the others are not. At least Xcode can be, and it is very flexible. It is moving forward, and there are some bits that have surpassed vs.net, others it lags behind.

Ultimately though, you will never convince people that are comfortable in one platform that another is better. Witness the vim/emacs wars. Use the tool that works for you, and grasp that Xcode and Visual Studio do not play well together. The dialect of c++ that Vs devs use is laced with incompatible macros that do not play well with other platforms. It takes work and discipline to make them play well together.

Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad

On Feb 28, 2012, at 3:48 PM, Jeffrey Walton <noloader...> wrote:

> On Tue, Feb 28, 2012 at 2:27 PM, Thomas CLEMENT <tclementdev...> wrote:>> What is it called in software development when you're introducing bugs faster than you're fixing them? Because this is the problem the Xcode development team is facing here.> Alpha.
> >> On 28 févr. 2012, at 19:37, koko <koko...> wrote:
>> >>> Cannot see strings in 4.3 …. and 4.3 sure does do goofy things …. lots of (Empty editor) entries in the Window menu which propagate to the 4.2.1 window menu.
>>>
>>> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.
>>>
>>> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
>>>
>>> Apple and Xcode are an embarrassment to professional software development.
>>>
>>> Come on Apple, get with it or give back MPW at least it did not crash all the time.
>>>
>>> -koko>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<dru...>
>
> This email sent to <dru...>

What is it called in software development when you're introducing bugs faster than you're fixing them? Because this is the problem the Xcode development team is facing here.

Apple should clearly get some serious Q&A people on Xcode!

On 28 févr. 2012, at 19:37, koko <koko...> wrote:

> Cannot see strings in 4.3 …. and 4.3 sure does do goofy things …. lots of (Empty editor) entries in the Window menu which propagate to the 4.2.1 window menu.
>
> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.
>
> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
>
> Apple and Xcode are an embarrassment to professional software development.
>
> Come on Apple, get with it or give back MPW at least it did not crash all the time.
>
> -koko
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<tclementdev...>
>
> This email sent to <tclementdev...>

> On 29/02/2012, at 5:54 AM, Jens Alfke wrote:>> Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)> While I'm aware how easy it is to get over-exercised about frustrations with dev tools, I think the problems with Xcode 4 are worse than you suggest. That's certainly the impression I get from others' comments in the twitterverse etc, though clearly that's hard to gauge, subject to lots of silliness, etc. But many really smart people have lost faith in Xcode.
>
> I was an Xcode defender early on, being initially very pleased by its design clarity and consistency. But I've found myself ground down by time wasted by crashes, interaction design problems, and implementation infelicities. That all this comes from a *released* product from the richest company in the world makes it clear to me that something is deeply wrong with the Xcode 4 project as a whole. Hopefully Apple can do the rabbit-trick and somehow turn it around, but I need tools that work smoothly, right now.
>
> For now my solution has been to surrender and use JetBrains' AppCode, which lacks surface elegance, and suffers from clutter, but is for the most part a pleasure to actually write code in.

I have to agree as well. Xcode 3 was getting pretty good for awhile,
but then Xcode 4 was released, a massive backwards step in
functionality which has only been getting worse with its point
releases. I have suffered, shockingly, very few of the crashes and
data loss bugs which people here have been plagued with, but I have
plenty of gripes just the same.

Xcode 4's integrated layout may look good on paper, and even work
better for some people, but for others it's a hopeless struggle to
manage screen space and get a consistent workflow going. Xcode 3's
ability to pop open and then close the build progress window was
delightful; with Xcode 4 I just get the build log in my editor pane
without being able to see the code I'm working on. Ditto that the IB
integration into Xcode; with a windowed layout that would have been
tolerable, but as it is I spend considerable time just going back and
forth between interface and code views to see what the heck I'm doing
- and no, tearing off Xcode 4's tabs doesn't make it better, because
that has a near-100% tendency to completely destroy my window position
and layout settings. Xcode 4 took away the class hierarchy view. It
took away the ability to compile one file at a time. The integrated
debugger console is painful and takes away from code editor screen
space. Workspaces are just plain broken and do not work as advertised.
The configuration editor is a step up, but unfortunately the "scheme"
concept is a two steps down. Switching between Debug and Release
should not require chugging through three settings panels to find the
right switch. And don't talk to me about the inability to shut off Git
integration on a per-project basis (or, for that matter, at all). Why
can't I enable Guard Malloc or change the debugger used for unit
tests? Why am I sacrificing valuable screen space (and I say that
having a 27" screen, fully aware that people are doing dev with Xcode
4 on 11" Macbook Airs) for an iTunes-like status display when Xcode
3's status bar was just as useful?

And Xcode 4 itself is, as a whole, sluggish in every respect.
Operations of all kinds, from editing text to creating connections in
IB to switching between code files, which were perceptually
instantaneous in Xcode 3 take visible time in 4. Even those 200
milliseconds here and there add up to an overall feeling that I'm
spending more time waiting for my development environment to catch up
with my thinking than I am actually writing code. Yes, it's very nice
that the debugger console and utility panels slide neatly in and out
with smooth animation, but I'm a developer; Apple doesn't have to
market eyecandy to me. I'd -strongly- prefer instant response. And all
I get for all this trouble is ridiculously bloated memory usage
forcing a restart of the program every several hours of serious work.

Before anyone asks, yes, I've filed several Radars. All have been
closed as duplicates (which means I'll never hear anything about them
again) or ignored (same result). The impression I get from Apple is
that they think that they have enough people who build their
livelihoods on the iOS ecosystem that they don't have to put any
effort into improving the tools for those who give a darn about a time
when writing code wasn't an exercise in stockpiling $20,000 for a
tripped out Mac Pro whose stats can compensate for Xcode's flaws.

Now there's a word you don't hear or see every day :-) (at least not from the company I'm keeping)

While 3.2.6 was not perfect it worked really well for me. Arbitrarily deciding that "one window does all" is the one true way, is a monumental regression in terms of usability. Everything is cramped and tiny, buttons are scattered all over etc. etc..

I _like_ having many "single purpose" editor windows open. I _like_ having searching, debugging etc. be distinct activities in their own window.

My opinion in this matter obviously does not matter to whoever has designed Xcode 4. He has decided that he knows better.

My preferred development machine is 10.6 using Xcode 3.2.6. I use 10.7 grudgingly if I have to, and Xcode 4.3 only if absolutely necessary. Lately that has been the case, so I've spent a couple of months on 4.2 and 4.3 so I believe I've had enough time to form a valid opinion

I think if you pass the original email through the Spok filter (to suck the
emotion out of it), and realize that it was most likely written by a
developer who was massively frustrated, there is a point to be taken.

The point is that recent releases of Xcode have been buggier than they
should be. In fact, I'd say 4.3 was buggier than 4.2, and so on. If
someone at Apple is listening, your developer community is asking you to
please take note of this and improve things.

Developers LIVE in Xcode all day. Even the "silly bug" can become
massively frustrating when it's hitting you between the eyes 12 hours a
day. A product like Xcode must be pretty darn close to perfect to not be
annoying.

Here's an example. Right now, in my project, the Issue Navigator is
broken. When I click on an issue, I am not taken to the source line.
Instead, I have to "Reveal in Log", find the error, note the line, click
the error again, find the line of code, and fix it. It's driving me crazy,
and it will continue to drive me crazy until the next release of Xcode -
which is most likely months from now.

I brought this up here the other day, and no one has told me a workaround,
and I haven't found one myself. I also don't know how to reproduce the
issue so I can report it. I just know it's broken now, and it used to work.

I think that it is helpful to bear in mind that people who have never had a significant issue with Xcode are likely to never have joined this list, so you are already dealing with a subset of the developers, ones who are more likely to have come across a significant issue or had a question that made them join this list.

And it is unlikely that people who are happy with Xcode (like me) would be posting messages on this thread.

Sure I have encountered a few little glitches (e.g completions in GDB), and one or two crashes, but overall the more I use it the more I like it. Yes, it would be nice to have a completely bug free environment, but it is massively better than the previous version, and I hate it when I have to go back and do some maintenance work using Xcode 3.

And seeing as they are using it themselves for the development of OSX, I'm sure they'll be getting plenty of feedback from their own engineers to keep improving it.

….just sending this on behalf of the silent (probably) majority...

Gideon

On 29/02/2012, at 9:24 AM, Crispin Bennett wrote:

>
> While I'm aware how easy it is to get over-exercised about frustrations with dev tools, I think the problems with Xcode 4 are worse than you suggest. That's certainly the impression I get from others' comments in the twitterverse etc, though clearly that's hard to gauge, subject to lots of silliness, etc. But many really smart people have lost faith in Xcode.
>
> I was an Xcode defender early on, being initially very pleased by its design clarity and consistency. But I've found myself ground down by time wasted by crashes, interaction design problems, and implementation infelicities. That all this comes from a *released* product from the richest company in the world makes it clear to me that something is deeply wrong with the Xcode 4 project as a whole. Hopefully Apple can do the rabbit-trick and somehow turn it around, but I need tools that work smoothly, right now.
>
> For now my solution has been to surrender and use JetBrains' AppCode, which lacks surface elegance, and suffers from clutter, but is for the most part a pleasure to actually write code in.
>
>

+1 Gwynne. I was in the middle of a similar post, but you said it so
much better.

Sent from my iPad

On Feb 28, 2012, at 10:55 PM, Gwynne Raskind <gwynne...> wrote:

> On Tue, Feb 28, 2012 at 17:57, Crispin Bennett <cb.lists...> wrote:>> On 29/02/2012, at 5:54 AM, Jens Alfke wrote:>>> Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)>> While I'm aware how easy it is to get over-exercised about frustrations with dev tools, I think the problems with Xcode 4 are worse than you suggest. That's certainly the impression I get from others' comments in the twitterverse etc, though clearly that's hard to gauge, subject to lots of silliness, etc. But many really smart people have lost faith in Xcode.
>>
>> I was an Xcode defender early on, being initially very pleased by its design clarity and consistency. But I've found myself ground down by time wasted by crashes, interaction design problems, and implementation infelicities. That all this comes from a *released* product from the richest company in the world makes it clear to me that something is deeply wrong with the Xcode 4 project as a whole. Hopefully Apple can do the rabbit-trick and somehow turn it around, but I need tools that work smoothly, right now.
>>
>> For now my solution has been to surrender and use JetBrains' AppCode, which lacks surface elegance, and suffers from clutter, but is for the most part a pleasure to actually write code in.>
> I have to agree as well. Xcode 3 was getting pretty good for awhile,
> but then Xcode 4 was released, a massive backwards step in
> functionality which has only been getting worse with its point
> releases. I have suffered, shockingly, very few of the crashes and
> data loss bugs which people here have been plagued with, but I have
> plenty of gripes just the same.
>
> Xcode 4's integrated layout may look good on paper, and even work
> better for some people, but for others it's a hopeless struggle to
> manage screen space and get a consistent workflow going. Xcode 3's
> ability to pop open and then close the build progress window was
> delightful; with Xcode 4 I just get the build log in my editor pane
> without being able to see the code I'm working on. Ditto that the IB
> integration into Xcode; with a windowed layout that would have been
> tolerable, but as it is I spend considerable time just going back and
> forth between interface and code views to see what the heck I'm doing
> - and no, tearing off Xcode 4's tabs doesn't make it better, because
> that has a near-100% tendency to completely destroy my window position
> and layout settings. Xcode 4 took away the class hierarchy view. It
> took away the ability to compile one file at a time. The integrated
> debugger console is painful and takes away from code editor screen
> space. Workspaces are just plain broken and do not work as advertised.
> The configuration editor is a step up, but unfortunately the "scheme"
> concept is a two steps down. Switching between Debug and Release
> should not require chugging through three settings panels to find the
> right switch. And don't talk to me about the inability to shut off Git
> integration on a per-project basis (or, for that matter, at all). Why
> can't I enable Guard Malloc or change the debugger used for unit
> tests? Why am I sacrificing valuable screen space (and I say that
> having a 27" screen, fully aware that people are doing dev with Xcode
> 4 on 11" Macbook Airs) for an iTunes-like status display when Xcode
> 3's status bar was just as useful?
>
> And Xcode 4 itself is, as a whole, sluggish in every respect.
> Operations of all kinds, from editing text to creating connections in
> IB to switching between code files, which were perceptually
> instantaneous in Xcode 3 take visible time in 4. Even those 200
> milliseconds here and there add up to an overall feeling that I'm
> spending more time waiting for my development environment to catch up
> with my thinking than I am actually writing code. Yes, it's very nice
> that the debugger console and utility panels slide neatly in and out
> with smooth animation, but I'm a developer; Apple doesn't have to
> market eyecandy to me. I'd -strongly- prefer instant response. And all
> I get for all this trouble is ridiculously bloated memory usage
> forcing a restart of the program every several hours of serious work.
>
> Before anyone asks, yes, I've filed several Radars. All have been
> closed as duplicates (which means I'll never hear anything about them
> again) or ignored (same result). The impression I get from Apple is
> that they think that they have enough people who build their
> livelihoods on the iOS ecosystem that they don't have to put any
> effort into improving the tools for those who give a darn about a time
> when writing code wasn't an exercise in stockpiling $20,000 for a
> tripped out Mac Pro whose stats can compensate for Xcode's flaws.
>
> -- Gwynne
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<heath.borders...>
om
>
> This email sent to <heath.borders...>

> On 29/02/2012, at 5:54 AM, Jens Alfke wrote:
> >>
>>
>> Oh, come on. You ran into some bugs, and they’re frustrating no doubt, but this is an overreaction. If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears. It’s unfortunate but it happens. Especially idiosyncratic bugs that only happen to a small number of users; it sounds like Xc 4.3 is behaving worse for you than for most people. (I haven’t had any real problems with it myself.)
>>
>> —Jens
>> >
>
> While I'm aware how easy it is to get over-exercised about frustrations with dev tools, I think the problems with Xcode 4 are worse than you suggest. That's certainly the impression I get from others' comments in the twitterverse etc, though clearly that's hard to gauge, subject to lots of silliness, etc. But many really smart people have lost faith in Xcode.
>
> I was an Xcode defender early on, being initially very pleased by its design clarity and consistency. But I've found myself ground down by time wasted by crashes, interaction design problems, and implementation infelicities. That all this comes from a *released* product from the richest company in the world makes it clear to me that something is deeply wrong with the Xcode 4 project as a whole. Hopefully Apple can do the rabbit-trick and somehow turn it around, but I need tools that work smoothly, right now.
>
> For now my solution has been to surrender and use JetBrains' AppCode, which lacks surface elegance, and suffers from clutter, but is for the most part a pleasure to actually write code in.

Xcode is getting more and more complex with each release. The problem with more complex systems is that I feel at some point that "you're losing control" over it. Nobody really can understand it as a whole. There are just a bunch of engineers maintaining their own area and trying to get together so that all those parts work together. I think it's a bit the same in OS X, the system. There are so many subsystems that it feels a little bit out of hands. There are bugs and will always been bugs. For most users, it is OK but not all users exercise the same areas and the systems are getting so complex that there is a multitude of possibilities. When basing things like closing my MacBook Pro when Mail, iChat and Safari are open and it takes 10 seconds for the system to go to sleep, something is not right. I could (and I'm sure a lot of others) could list a multitude of annoying little problems with the system, as well as for Xcode. For those of us that have been in commercial software development, we know how it goes. You try to fix the most glaring bugs but you know that there are some that you won't be able to fix and the time to release a new update comes when it is stable for most people. That's how it is. Unfortunate a bit but I believe that's the truth in software development these days.

So, Xcode has problems. It will always have problems. Each time a new release is made available, I just hope that I can live with the new issues.

I've found that writing Xcode plugins to fix bugs to be much effective
than praying to the Xcode gods. (Such conduct is grounds for
excommunication, but at least you get results.) Check out 'Xcode 4
fixins'.

> I _like_ having many "single purpose" editor windows open. I _like_ having searching, debugging etc. be distinct activities in their own window.
>
> My opinion in this matter obviously does not matter to whoever has designed Xcode 4. He has decided that he knows better.
>
> My preferred development machine is 10.6 using Xcode 3.2.6. I use 10.7 grudgingly if I have to, and Xcode 4.3 only if absolutely necessary. Lately that has been the case, so I've spent a couple of months on 4.2 and 4.3 so I believe I've had enough time to form a valid opinion

+1

Xc4 has brought tremendous new functionality in terms of debugging multiple targets simultaneously, but shoots itself in the foot with the very "browser style" UI it espouses in that regard.

I still do 95% of my work in XCode3. I don't foresee that changing. XCode4 doesn't have a chance of indexing my project, which makes all the cool code completion, jump to definition, and everything else that makes an IDE more than a glorified TextEdit useless. Plus there's no file splitter or jump to documentation.

> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options.

People are talking about some pretty basic problems with Xcode, though; certainly more than just small bugs and annoyances. And they're in many cases to do with really basic facilities, things like syntax highlighting, and moving between tabs within a reasonable amount of time. And above all: crashes (and far too many of them).

No tools are perfect, of course, but that doesn't make them all of equal quality, either. Xcode is one of the bad ones, and, coming from Apple, it shouldn't be.

>
> And it is unlikely that people who are happy with Xcode (like me) would be posting messages on this thread.

That's certainly true. But the complaints about Xcode 4 are loud and numerous (and certainly chime with my experience of it). I think there's a prima facie case that the problems are real.

>
> And seeing as they are using it themselves for the development of OSX, I'm sure they'll be getting plenty of feedback from their own engineers to keep improving it.
>

That's my hope. But the fact that such an important product at this stage of its development is as poor as it is suggests to me some fundamental failure of the project as a whole. It's certainly not a failure of talent or knowledge, so my (uninformed) guess is that it's process-related in some way.

> I've found that writing Xcode plugins to fix bugs to be much effective
> than praying to the Xcode gods. (Such conduct is grounds for
> excommunication, but at least you get results.) Check out 'Xcode 4
> fixins'.
>
> Hath pity upon my soul, Xcode team
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<rmann...>
>
> This email sent to <rmann...>

> For those of us that have been in commercial software development, > > we know how it goes. You try to fix the most glaring bugs but you > know that there are some that you won't be able to fix and the> time to release a new update comes when it is stable for most > people. That's how it is. Unfortunate a bit but I believe that's > the truth in software development these days. But this is Apple here. Reportedly, they have people working on fake projects until they can be trusted. How many such employees do you have?

Maybe Apple should put new hires to work on "fake project" of putting latest SDKs into Xcode 3 and then release the result just for the fun of it.
Igor

> That's my hope. But the fact that such an important product at this stage of its development is as poor as it is suggests to me some fundamental failure of the project as a whole. It's certainly not a failure of talent or knowledge, so my (uninformed) guess is that it's process-related in some way.

I'd say it's organizational/managerial.

I suspect the Xcode team simply has too few resources available to adequately tackle their given tasks while maintaining high quality.

At a bare minimum they need to add support for new versions of iOS and OS X every year (the Xcode team must have been over the moon when they heard about the decision to put OS X on a yearly release schedule too). Plus I assume they have long-term efforts on the go to add support for improvements in runtimes/languages (or even completely new ones) and it's easy to see how only the most central use-cases and high priority issues get significant attention.

I'm not trying to excuse Apple. Xcode's quality is lacking and this needs to be addressed by management.

Apple has undermined developer confidence in a number of ways over the last couple of years and next to the shoddy handling of the ongoing sandboxing saga on OS X, Xcode 4 is the #1 source of frustration with Apple amongst the iOS and OS X devs I know over here in Europe.

Developers can't understand how the world's richest company (as has been mentioned here before) can release something that fails to meet their most basic requirements of stability and performance.

I bet the bright and talented engineers working on Xcode care deeply about the product, but from where we're sitting it looks like Apple as a whole doesn't place a high priority on the quality of their developer tools.

>> For those of us that have been in commercial software development,
>>
>> we know how it goes. You try to fix the most glaring bugs but you
>> know that there are some that you won't be able to fix and the
>> time to release a new update comes when it is stable for most
>> people. That's how it is. Unfortunate a bit but I believe that's
>> the truth in software development these days.> But this is Apple here. Reportedly, they have people working on fake projects until they can be trusted. How many such employees do you have?
>
> Maybe Apple should put new hires to work on "fake project" of putting latest SDKs into Xcode 3 and then release the result just for the fun of it.

Copy / Paste the SDK from Xcode 4.3 to Xcode 3 Developer dir and you're done. I'm using Xcode 3 on Lion, with 10.7 SDKs for some times now, and it works nicely.
I'm also using the svn version of clang to be sure it supports all features of Xcode 4 and recent SDKs.

And to build release versions, I'm using Xcode 4's xcodebuild, so my product is finally built using a supported configuration.

>
> On 2012-02-28, at 6:24 PM, Crispin Bennett wrote:
> >> infelicities>
> Now there's a word you don't hear or see every day :-) (at least not from the company I'm keeping)
>
> While 3.2.6 was not perfect it worked really well for me. Arbitrarily deciding that "one window does all" is the one true way, is a monumental regression in terms of usability. Everything is cramped and tiny, buttons are scattered all over etc. etc..

Yep.

> I _like_ having many "single purpose" editor windows open. I _like_ having searching, debugging etc. be distinct activities in their own window.

Yep.

> My opinion in this matter obviously does not matter to whoever has designed Xcode 4. He has decided that he knows better.
>
> My preferred development machine is 10.6 using Xcode 3.2.6. I use 10.7 grudgingly if I have to, and Xcode 4.3 only if absolutely necessary. Lately that has been the case, so I've spent a couple of months on 4.2 and 4.3 so I believe I've had enough time to form a valid opinion

It seems like Apple got some designer from the Windows world and Inflicted him upon us.

Lion simply blows with this pushing of iOS and Windows metaphors onto the Mac with animated everything. This "whole screen" move is SO Windows and is just idiotic when many of us have huge monitors. Even the blatant copying of the (terrible) Windows file copy error message shows that Apple is more focused with integrating a Windows feel onto the Mac.

I want to be able to use different windows for things, trying to lump everything onto one window ends up making things more difficult - like in Xcode, the loss of the lines of error messages, instead, we get a small column with the messages cut off. WHO LET THIS PASS? It's terrible.

And then there is the mass of different command keys to use, etc, etc.

Apple could have spent their valuable developer time making Xcode 3 and Snow Leopard better, rather than pushing poor usability metaphors on us rather than redesigning for the sake of redesigning.

And in Lion, if you use a magic mouse in Safari and turn gestures off? The Safari window will still wobble when you approach the edge of the screen. It's irritating and so much LESS useful than Snow Leopard. No way in hell do I want to pay to upgrade my OS, and then spend my valuable time to try to hack it back to the level of usability I just upgraded from.

We have these command keys that we can use to move between different windows. It's silly to try to force us to do everything on one.

You need to spend time in the "good" ones then. The same issues exist.

Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad

On Feb 29, 2012, at 2:52 AM, Crispin Bennett <crispin...> wrote:

> On 29/02/2012, at 10:16 AM, Andrew Satori wrote:
> >> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options.>
> People are talking about some pretty basic problems with Xcode, though; certainly more than just small bugs and annoyances. And they're in many cases to do with really basic facilities, things like syntax highlighting, and moving between tabs within a reasonable amount of time. And above all: crashes (and far too many of them).
>
> No tools are perfect, of course, but that doesn't make them all of equal quality, either. Xcode is one of the bad ones, and, coming from Apple, it shouldn't be.

> I think if you pass the original email through the Spok filter (to suck the emotion out of it), and realize that it was most likely written by a developer who was massively frustrated, there is a point to be taken.
>
> The point is that recent releases of Xcode have been buggier than they should be. In fact, I'd say 4.3 was buggier than 4.2, and so on. If someone at Apple is listening, your developer community is asking you to please take note of this and improve things.
>
> Developers LIVE in Xcode all day. Even the "silly bug" can become massively frustrating when it's hitting you between the eyes 12 hours a day. A product like Xcode must be pretty darn close to perfect to not be annoying.
>
> Here's an example. Right now, in my project, the Issue Navigator is broken. When I click on an issue, I am not taken to the source line. Instead, I have to "Reveal in Log", find the error, note the line, click the error again, find the line of code, and fix it. It's driving me crazy, and it will continue to drive me crazy until the next release of Xcode - which is most likely months from now.
>
> I brought this up here the other day, and no one has told me a workaround, and I haven't found one myself. I also don't know how to reproduce the issue so I can report it. I just know it's broken now, and it used to work.

For things as important as errors and issues, these should NEVER be hidden. It's amazing and sad that we have to go through such indirect operations to see the full errors and issues.

> You need to spend time in the "good" ones then. The same issues exist.

That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
And yes, I have a bug opened about this issue.

>
> Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad
>
> On Feb 29, 2012, at 2:52 AM, Crispin Bennett <crispin...> wrote:
> >> On 29/02/2012, at 10:16 AM, Andrew Satori wrote:
>> >>> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options.>>
>> People are talking about some pretty basic problems with Xcode, though; certainly more than just small bugs and annoyances. And they're in many cases to do with really basic facilities, things like syntax highlighting, and moving between tabs within a reasonable amount of time. And above all: crashes (and far too many of them).
>>
>> No tools are perfect, of course, but that doesn't make them all of equal quality, either. Xcode is one of the bad ones, and, coming from Apple, it shouldn't be.>

Spend some quality time with Embarcadero's RadStuido XE2. It will frequently get into an issue where the debugger will fail to exit. The only option is to restart Windows. In Visual Studio, yes it rarely causes the system to hang, but it's not unusual at all for it's syntax highlighting get completely out of sorts, and I have a solution that I can load that I can reliably build and debug about 3 times before VS gets confused about dependancies and starts to block with unable to write file errors. I have the same issues in other platforms as I do in Xcode, and I feel that I push all of them pretty hard, with large workspaces that contain multiple projects with multiple dependancies.

I don't care what IDE you want to talk about, they all break when we push them in unexpected ways, and as developers, we tend to push tools to fit our workflows, not to conform to theirs. I think if you look at your problems, and get serious about understanding them, you will find that you are creating some of your own problems. I know that every single serious 'flaw' I have found in Xcode 4 has been where I have been forcing a behavior. Learning to relax and go with it, I have found Xcode 4 to be very productive, and I haven't crashed it once in the last 2 weeks.

It is all about what you make of it. You can fight it, or you can resist change and force it. I spend every single day with RadSTudio, Visual Studio and Xcode all three up and running, usually compiling the exact same code. It has taken a good bit of patience to get things to a place where that wasn't painful, and I cannot point to any one of those IDE's as being better or worse in terms of bugs. I have been bitten by all of them in different ways.

To sit here and kvetch that Apple is doing wrong is, IMO, inappropriate. Can they do better? yes, and specific suggestions on specific things is productive, but a general, Xcode sucks position, Xcode crashes 10 times a day doesn't help much.

"It's Broke" is absolutely worthless, as you should well know as a commercial developer. You want good bug reports, file good bug reports, work WITH Apple to fix it, document your workarounds, share with the community. In short, contribute to fixing things.

And yes, I have bugs filed against all three environments, one of which has been open for 6 years with Microsoft.

On Feb 29, 2012, at 9:57 AM, Jean-Daniel Dupas wrote:

>
> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
> >> You need to spend time in the "good" ones then. The same issues exist.>
> That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
> And yes, I have a bug opened about this issue.
> >>
>> Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad
>>
>> On Feb 29, 2012, at 2:52 AM, Crispin Bennett <crispin...> wrote:
>> >>> On 29/02/2012, at 10:16 AM, Andrew Satori wrote:
>>> >>>> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options.>>>
>>> People are talking about some pretty basic problems with Xcode, though; certainly more than just small bugs and annoyances. And they're in many cases to do with really basic facilities, things like syntax highlighting, and moving between tabs within a reasonable amount of time. And above all: crashes (and far too many of them).
>>>
>>> No tools are perfect, of course, but that doesn't make them all of equal quality, either. Xcode is one of the bad ones, and, coming from Apple, it shouldn't be.>> >
> -- Jean-Daniel
>
>
>
>
>

>
> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
> >> You need to spend time in the "good" ones then. The same issues exist.>
> That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
> And yes, I have a bug opened about this issue.

As a guy who ran one of the Shockwave QA and beta programs back in the mid/late '90s, it's simply hard for me to spend the time to enter a bug. There is no guarantee that my time will be spent well. I know I'm not going to be notified if the bug is to have any resolution. If the bug is closed, marked a dup, will be addressed, or not, I'm never going to know. For me to write up a proper bug report that doesn't waste the developer's time, then I have to spend a lot of time. But I'm never going to get an answer and that leaves the users in a bad state.

Now, this is not normally possible, for time and corporate image factors, but here is what I did, and why it matters.

I got on the Director listserv email lists in 1994/1995 and said this:

"Hey guys, we're going to do this new product that's going to allow you to take your CD ROM product, modify it (a lot) and deliver it (to some extent) over this new 'Internet' thing. I'm willing to open this up to you guys. If you want to be part of the Beta for Shockwave, then you will need to be able to report the bugs and issues to me as if I were 3 years old and give me the code that is causing the problem in a simple case (remember, I'm not next to your desk and have no idea what's going on). In turn, what I will do is PERSONALLY enter your bugs in our database and make sure they get looked at. To the best of my ability, I'll tell you if something's going to be fixed or not, so you can find a work around if needed. The point here is that you are not submitting requests to a black hole.

I'm going to set up a new list, Shocker-L and will be monitoring the list on a daily (hourly) basis. Lemmie know if you want to join by sending me an email and I'll put on the Shockwave Beta program, but I expect you to participate. Please feel free to email me directly."

So, we did this, and I ran the whole effort. We increased out QA effort by a factor of THREE with no additional staff and got out a much better product (on Windows first, then the Mac) than we ever could have hoped without this openness.

We were not apologetic or spinmeisters (well, one other great very knowledgeable guy sadly was), we called a bug a bug, we addressed them, some were not fixed, but we ended up putting out the product that really created multimedia on the internet and it was enough to keep Macromedia in business for time after the CD ROM market tanked.

We had a following for quite a while until Flash took over and it was good for the company and good for our users.

Then Rob Burgess put the dev team in the basement and it took Steve Jobs to ask Macromedia to put out an OS X version of Director. Then several teams in India cratered it and turned it into a bad Windows port.

But the point was that the open QA program made sure the product wasn't a complete barge of garbage and it was simply badly needed and IMHO, a stellar, non traditional and very successful way to do it.

> I have to agree as well. Xcode 3 was getting pretty good for awhile,
> but then Xcode 4 was released, a massive backwards step in
> functionality which has only been getting worse with its point
> releases.

You should bear in mind that Xcode 3 had been in release for three or four years at the time. It was awful for a year after release, and was becoming awful again with the many bags that had to be hung on it (and the many that couldn't) to support modern development techniques.

> Xcode 4's integrated layout may look good on paper, and even work
> better for some people, but for others it's a hopeless struggle to
> manage screen space and get a consistent workflow going. Xcode 3's
> ability to pop open and then close the build progress window was
> delightful; with Xcode 4 I just get the build log in my editor pane
> without being able to see the code I'm working on.

I understand the problem, and it was hard for me, too. Tabs and behaviors go a long way to relieving it. I'll start my season of shameless self-promotion by saying that my book, "Xcode 4 Unleashed" (now in preview on the Safari books site, and final, probably, in April), has a chapter on how to cope, if not to love it. Until then, look for those topics in the Xcode docset in the Documentation organizer.

For other things, I wonder if you aren't just annoyed at the same things being there, only changed. The Symbol navigator presents class hierarchies. The Debug area and navigator don't consume as much screen space as the equivalent views in the old Debugger and console windows. Devoting a whole window to a list of breakpoints was ludicrous.

> Why can't I enable Guard Malloc

Scheme editor > Run panel (the default) > Diagnostics tab. Two gestures, and it's possible to use the option along with others.

> or change the debugger used for unit tests?

Scheme editor > Test panel > Info tab (the default). Two gestures, and a dedicated editor related to the target, not a three-or-four-gesture bag hung over the obscure notion of "not-exactly-an-executable" in the file list.

Take some time to see what's in the Scheme editor, even if you're seething over it.

> And Xcode 4 itself is, as a whole, sluggish in every respect.

It's an appalling memory hog, and Xcode engineer postings here have been insouciant about "but I _want_ to use every byte of RAM I paid for!" And, apparently, every byte of swap space. It's getting better, but I still have to quit the thing every couple of days. Switching between code files isn't a problem on my three-year-old MacBook Pro, but my IB tab is a pain. That you're having more trouble than I am makes me wonder if you have room for more RAM. My MBP carries 8 GB.

I hope I don't get "fanboi" responses. There are bugs. I think the switch to a browser was a close call, and reasonable people are entitled to be angry about it. I just opened a project in which all but a handful of files had disappeared from the navigator. (No, I toggled all the filters. The solution was to right-click a file in a Compile Sources phase, and select Reveal in Project Navigator). That was frightening and vexatious. Bugs do seem to be accumulating (though you should see the difference between final previews and releases). I'm just saying that workarounds for many issues are there if you're willing to see them, and that Xcode 3 doesn't deserve unconditional nostalgia.

Xcode is an all-purpose tool for building arbitrarily complicated iOS and
OS X applications. Whatever can be expressed in Xcode, be it number of
source files, number of configurations, complexity of code, etc., should
just work. It's ridiculous to anthropomorphize the tool and think of it as
being "pushed too far". It's software. It is either correct or it is
incorrect. It either works or it doesn't.

When an IDE crashes, for any reason whatsoever, it's a bug. When an IDE
loses data, for any reason whatsoever, it's a bug. When an IDE silently
fails to be able to open a file, build a project, take you to an error,
show code sense, design a NIB, etc., it's a bug.

My point is, if Xcode allows you to do something, and then doesn't work in
some way once you've done it, it's busted and can be fixed.

Brian

On Wed, Feb 29, 2012 at 7:46 AM, Andrew Satori <dru...> wrote:

>
> Spend some quality time with Embarcadero's RadStuido XE2. It will
> frequently get into an issue where the debugger will fail to exit. The
> only option is to restart Windows. In Visual Studio, yes it rarely causes
> the system to hang, but it's not unusual at all for it's syntax
> highlighting get completely out of sorts, and I have a solution that I can
> load that I can reliably build and debug about 3 times before VS gets
> confused about dependancies and starts to block with unable to write file
> errors. I have the same issues in other platforms as I do in Xcode, and I
> feel that I push all of them pretty hard, with large workspaces that
> contain multiple projects with multiple dependancies.
>
> I don't care what IDE you want to talk about, they all break when we push
> them in unexpected ways, and as developers, we tend to push tools to fit
> our workflows, not to conform to theirs. I think if you look at your
> problems, and get serious about understanding them, you will find that you
> are creating some of your own problems. I know that every single serious
> 'flaw' I have found in Xcode 4 has been where I have been forcing a
> behavior. Learning to relax and go with it, I have found Xcode 4 to be
> very productive, and I haven't crashed it once in the last 2 weeks.
>
> It is all about what you make of it. You can fight it, or you can resist
> change and force it. I spend every single day with RadSTudio, Visual
> Studio and Xcode all three up and running, usually compiling the exact same
> code. It has taken a good bit of patience to get things to a place where
> that wasn't painful, and I cannot point to any one of those IDE's as being
> better or worse in terms of bugs. I have been bitten by all of them in
> different ways.
>
> To sit here and kvetch that Apple is doing wrong is, IMO, inappropriate.
> Can they do better? yes, and specific suggestions on specific things is
> productive, but a general, Xcode sucks position, Xcode crashes 10 times a
> day doesn't help much.
>
> "It's Broke" is absolutely worthless, as you should well know as a
> commercial developer. You want good bug reports, file good bug reports,
> work WITH Apple to fix it, document your workarounds, share with the
> community. In short, contribute to fixing things.
>
> And yes, I have bugs filed against all three environments, one of which
> has been open for 6 years with Microsoft.
>
>
> On Feb 29, 2012, at 9:57 AM, Jean-Daniel Dupas wrote:
> >>
>> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
>> >>> You need to spend time in the "good" ones then. The same issues exist.>>
>> That's wrong. I don't know any IDE but Xcode that force me to hard> reboot my machine 10 times a day.>> And yes, I have a bug opened about this issue.
>> >>>
>>> Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad
>>>
>>> On Feb 29, 2012, at 2:52 AM, Crispin Bennett <crispin...> wrote:
>>> >>>> On 29/02/2012, at 10:16 AM, Andrew Satori wrote:
>>>> >>>>> You know, I find this comical to read. No Xcode is not perfect. Yes> it has issues, but here is the thing, I prefer IDE development, and I have
> used a bunch over the years. Let us call a spade a spade. They all suck
> in new and glorious ways. Xcode is has some really great features, along
> with some really silly bugs. Most of the bugs have workarounds, but a few
> are truly annoying. The problem is, so do most of the other options.>>>>
>>>> People are talking about some pretty basic problems with Xcode,> though; certainly more than just small bugs and annoyances. And they're in
> many cases to do with really basic facilities, things like syntax
> highlighting, and moving between tabs within a reasonable amount of time.
> And above all: crashes (and far too many of them).>>>>
>>>> No tools are perfect, of course, but that doesn't make them all of> equal quality, either. Xcode is one of the bad ones, and, coming from
> Apple, it shouldn't be.>>> >>
>> -- Jean-Daniel
>>
>>
>>
>>
>> >
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
>
> https://lists.apple.com/mailman/options/xcode-users/<brianlambert...>
m
>
> This email sent to <brianlambert...>

Really, Xcode is fine in projects that have lots of files. Where it gets strange and most of it's bugs really start to show up is when you start dealing with workspaces that contain multiple projects with multiple targets and dependancy trees.

Let me give you an example, and this literally the workspace that took me the longest to make happy in Xcode.

The project in question has 14 Applications, 3 common Frameworks, and 2 static libraries. A full build will build every thing in the tree, but there are multiple smaller build cycles that can be done in there. How this works in each IDE is a little different. Even how it works between Xcode3 and Xcode4 is different. When I first tried this, I was 'forcing' things to work the way I thought it should be done. It was a mess. I crashed Xcode, and sometimes the entire OS repeatedly. Finally, after some trial and error, I reworked things to fit the model that Xcode 4 presents. Not changing code, but changing how I was assembling things. Using targets instead of sub projects, and voila, almost all of my problems went away.

What I am getting at, is that yes, they all have bugs, and I don't find that Xcode has any more egregious bugs than any other IDE or dev environment I have ever used, and that includes a LOT of IDE's, from MEtrowerks, to Watcom, to Borland, to MS, Eclipse, MonoDevelop, BeIDE, and many others. Ultimately, if you want to leverage the power of an IDE, you have to learn to work within it's quirks, not force it to fit yours. If you want to force it fit yours, then I highly recommend Makefiles and a good Text Editor, because nothing will ever fit everyones workflow.

On Feb 29, 2012, at 12:07 PM, Brian Lambert wrote:

> Andrew,
>
> What you're saying is silly. Actually, it's flat-out absurd.
>
> Xcode is an all-purpose tool for building arbitrarily complicated iOS and OS X applications. Whatever can be expressed in Xcode, be it number of source files, number of configurations, complexity of code, etc., should just work. It's ridiculous to anthropomorphize the tool and think of it as being "pushed too far". It's software. It is either correct or it is incorrect. It either works or it doesn't.
>
> When an IDE crashes, for any reason whatsoever, it's a bug. When an IDE loses data, for any reason whatsoever, it's a bug. When an IDE silently fails to be able to open a file, build a project, take you to an error, show code sense, design a NIB, etc., it's a bug.
>
> My point is, if Xcode allows you to do something, and then doesn't work in some way once you've done it, it's busted and can be fixed.
>
> Brian
>
> On Wed, Feb 29, 2012 at 7:46 AM, Andrew Satori <dru...> wrote:
>
> Spend some quality time with Embarcadero's RadStuido XE2. It will frequently get into an issue where the debugger will fail to exit. The only option is to restart Windows. In Visual Studio, yes it rarely causes the system to hang, but it's not unusual at all for it's syntax highlighting get completely out of sorts, and I have a solution that I can load that I can reliably build and debug about 3 times before VS gets confused about dependancies and starts to block with unable to write file errors. I have the same issues in other platforms as I do in Xcode, and I feel that I push all of them pretty hard, with large workspaces that contain multiple projects with multiple dependancies.
>
> I don't care what IDE you want to talk about, they all break when we push them in unexpected ways, and as developers, we tend to push tools to fit our workflows, not to conform to theirs. I think if you look at your problems, and get serious about understanding them, you will find that you are creating some of your own problems. I know that every single serious 'flaw' I have found in Xcode 4 has been where I have been forcing a behavior. Learning to relax and go with it, I have found Xcode 4 to be very productive, and I haven't crashed it once in the last 2 weeks.
>
> It is all about what you make of it. You can fight it, or you can resist change and force it. I spend every single day with RadSTudio, Visual Studio and Xcode all three up and running, usually compiling the exact same code. It has taken a good bit of patience to get things to a place where that wasn't painful, and I cannot point to any one of those IDE's as being better or worse in terms of bugs. I have been bitten by all of them in different ways.
>
> To sit here and kvetch that Apple is doing wrong is, IMO, inappropriate. Can they do better? yes, and specific suggestions on specific things is productive, but a general, Xcode sucks position, Xcode crashes 10 times a day doesn't help much.
>
> "It's Broke" is absolutely worthless, as you should well know as a commercial developer. You want good bug reports, file good bug reports, work WITH Apple to fix it, document your workarounds, share with the community. In short, contribute to fixing things.
>
> And yes, I have bugs filed against all three environments, one of which has been open for 6 years with Microsoft.
>
>
> On Feb 29, 2012, at 9:57 AM, Jean-Daniel Dupas wrote:
> >>
>> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
>> >>> You need to spend time in the "good" ones then. The same issues exist.>>
>> That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
>> And yes, I have a bug opened about this issue.
>> >>>
>>> Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad
>>>
>>> On Feb 29, 2012, at 2:52 AM, Crispin Bennett <crispin...> wrote:
>>> >>>> On 29/02/2012, at 10:16 AM, Andrew Satori wrote:
>>>> >>>>> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options.>>>>
>>>> People are talking about some pretty basic problems with Xcode, though; certainly more than just small bugs and annoyances. And they're in many cases to do with really basic facilities, things like syntax highlighting, and moving between tabs within a reasonable amount of time. And above all: crashes (and far too many of them).
>>>>
>>>> No tools are perfect, of course, but that doesn't make them all of equal quality, either. Xcode is one of the bad ones, and, coming from Apple, it shouldn't be.>>> >>
>> -- Jean-Daniel
>>
>>
>>
>>
>> >
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<brianlambert...>
m
>
> This email sent to <brianlambert...>
>

I can't agree more, especially when "too far" for Xcode 4 in my case is a project that works perfectly on Xcode 3.

Le 29 févr. 2012 à 18:07, Brian Lambert a écrit :

> Andrew,
>
> What you're saying is silly. Actually, it's flat-out absurd.
>
> Xcode is an all-purpose tool for building arbitrarily complicated iOS and OS X applications. Whatever can be expressed in Xcode, be it number of source files, number of configurations, complexity of code, etc., should just work. It's ridiculous to anthropomorphize the tool and think of it as being "pushed too far". It's software. It is either correct or it is incorrect. It either works or it doesn't.
>
> When an IDE crashes, for any reason whatsoever, it's a bug. When an IDE loses data, for any reason whatsoever, it's a bug. When an IDE silently fails to be able to open a file, build a project, take you to an error, show code sense, design a NIB, etc., it's a bug.
>
> My point is, if Xcode allows you to do something, and then doesn't work in some way once you've done it, it's busted and can be fixed.
>
> Brian
>
> On Wed, Feb 29, 2012 at 7:46 AM, Andrew Satori <dru...> wrote:
>
> Spend some quality time with Embarcadero's RadStuido XE2. It will frequently get into an issue where the debugger will fail to exit. The only option is to restart Windows. In Visual Studio, yes it rarely causes the system to hang, but it's not unusual at all for it's syntax highlighting get completely out of sorts, and I have a solution that I can load that I can reliably build and debug about 3 times before VS gets confused about dependancies and starts to block with unable to write file errors. I have the same issues in other platforms as I do in Xcode, and I feel that I push all of them pretty hard, with large workspaces that contain multiple projects with multiple dependancies.
>
> I don't care what IDE you want to talk about, they all break when we push them in unexpected ways, and as developers, we tend to push tools to fit our workflows, not to conform to theirs. I think if you look at your problems, and get serious about understanding them, you will find that you are creating some of your own problems. I know that every single serious 'flaw' I have found in Xcode 4 has been where I have been forcing a behavior. Learning to relax and go with it, I have found Xcode 4 to be very productive, and I haven't crashed it once in the last 2 weeks.
>
> It is all about what you make of it. You can fight it, or you can resist change and force it. I spend every single day with RadSTudio, Visual Studio and Xcode all three up and running, usually compiling the exact same code. It has taken a good bit of patience to get things to a place where that wasn't painful, and I cannot point to any one of those IDE's as being better or worse in terms of bugs. I have been bitten by all of them in different ways.
>
> To sit here and kvetch that Apple is doing wrong is, IMO, inappropriate. Can they do better? yes, and specific suggestions on specific things is productive, but a general, Xcode sucks position, Xcode crashes 10 times a day doesn't help much.
>
> "It's Broke" is absolutely worthless, as you should well know as a commercial developer. You want good bug reports, file good bug reports, work WITH Apple to fix it, document your workarounds, share with the community. In short, contribute to fixing things.
>
> And yes, I have bugs filed against all three environments, one of which has been open for 6 years with Microsoft.
>
>
> On Feb 29, 2012, at 9:57 AM, Jean-Daniel Dupas wrote:
> >>
>> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
>> >>> You need to spend time in the "good" ones then. The same issues exist.>>
>> That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
>> And yes, I have a bug opened about this issue.
>> >>>
>>> Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad
>>>
>>> On Feb 29, 2012, at 2:52 AM, Crispin Bennett <crispin...> wrote:
>>> >>>> On 29/02/2012, at 10:16 AM, Andrew Satori wrote:
>>>> >>>>> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options.>>>>
>>>> People are talking about some pretty basic problems with Xcode, though; certainly more than just small bugs and annoyances. And they're in many cases to do with really basic facilities, things like syntax highlighting, and moving between tabs within a reasonable amount of time. And above all: crashes (and far too many of them).
>>>>
>>>> No tools are perfect, of course, but that doesn't make them all of equal quality, either. Xcode is one of the bad ones, and, coming from Apple, it shouldn't be.>>> >>
>> -- Jean-Daniel
>>
>>
>>
>>
>> >
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<brianlambert...>
m
>
> This email sent to <brianlambert...>
>

Frustrations and operational bugs aside, I believe the underlying issue many developers have is that the Xcode 4 redesign is based on a flawed model: an all-in-one "this way or the highway" workflow. No one seems to know why it was changed. What was the problem in Xcode 3 that brought us Xcode 4? New management team, perhaps?

Xcode 3 (and previous) had an inherent flexibility that allowed a developer to develop HIS OWN WAY. I started out using Xcode 3 very simply, with a single project, using a single window. I grew to using it to develop 4 interrelated projects in tandem (a client, server, and 2 libraries). Awesome! I naturally think multithreaded and Xcode 3 allowed me the flexibility to develop that way -- if I chose to. But now, in Xcode 4, that's all been taken away, replaced with a changeling Xcode (ostensibly) dictated by someone at Apple who thinks he knows better than I do how my mind works and how I should be doing my development.

Sadly, this Windowsesque mindset has now beset all of Apple. Look at Lion, look at iOS, look at iCloud, heck even look at Objc 2.0. End-use flexibility is getting straightjacketed whilst the underlying complexity is increasing out of bounds. One can see that Xcode 4 is based on a bad design in the way that it requires a flood of tabs, buttons, and command key sequences to band-aid over the complexity choking the fundamental things that ought to be simple and direct. No slick implementation can make up for a flawed foundation.

I was taught by a great professor who had spent his entire career developing large projects (industrial, defense, aerospace). His projects always worked because he knew how to control design complexity. In short: Keep the core design simple and flexible and you'll have a 10X greater chance of producing a robust, extensible, and usable software product in the end.

> For other things, I wonder if you aren't just annoyed at the same things being there, only changed.

The things that bother me most are not the crashes and sluggishness, though I admit they annoy me when they happen.

If it were possible to revert to 3.x behaviour when an exception is thrown during iOS debugging, I'd probably shrug off everything else. How someone thought that pointing to a line in main.m was a good idea...I don't know. Telling Xcode to set a breakpoint on uncaught Objective-C exceptions at the point they're thrown works only unpredictably; it's more likely to stop without reporting a reason than it is to work the old way and display what is wrong.

Although it's not a regression like the one above, the failure of the debug environment to keep pace with the use of non-ivar properties is also a big time-waster.

>
> Spend some quality time with Embarcadero's RadStuido XE2. It will frequently get into an issue where the debugger will fail to exit. The only option is to restart Windows. In Visual Studio, yes it rarely causes the system to hang, but it's not unusual at all for it's syntax highlighting get completely out of sorts, and I have a solution that I can load that I can reliably build and debug about 3 times before VS gets confused about dependancies and starts to block with unable to write file errors. I have the same issues in other platforms as I do in Xcode, and I feel that I push all of them pretty hard, with large workspaces that contain multiple projects with multiple dependancies.
>
> I don't care what IDE you want to talk about, they all break when we push them in unexpected ways, and as developers, we tend to push tools to fit our workflows, not to conform to theirs. I think if you look at your problems, and get serious about understanding them, you will find that you are creating some of your own problems. I know that every single serious 'flaw' I have found in Xcode 4 has been where I have been forcing a behavior. Learning to relax and go with it, I have found Xcode 4 to be very productive, and I haven't crashed it once in the last 2 weeks.
>
> It is all about what you make of it. You can fight it, or you can resist change and force it. I spend every single day with RadSTudio, Visual Studio and Xcode all three up and running, usually compiling the exact same code. It has taken a good bit of patience to get things to a place where that wasn't painful, and I cannot point to any one of those IDE's as being better or worse in terms of bugs. I have been bitten by all of them in different ways.

I totally agree with you, issues can be found in every single IDE. If
someone is facing an issue with an IDE, the workaround is easy and
cheap: add a bumper around your computer.

More seriously, I didn't get the impression that most of the problems
reported in this thread are related to forcing the behavior of Xcode.
But I could be wrong as I still spend most of my time in Project Buil…
ahem… Xcode 3.2.something.

> To sit here and kvetch that Apple is doing wrong is, IMO, inappropriate. Can they do better? yes, and specific suggestions on specific things is productive, but a general, Xcode sucks position, Xcode crashes 10 times a day doesn't help much.
>
> "It's Broke" is absolutely worthless, as you should well know as a commercial developer. You want good bug reports, file good bug reports, work WITH Apple to fix it, document your workarounds, share with the community. In short, contribute to fixing things.

Also there used to be a xcode-feedback e-mail address in the past.
It's probably still working and the guys who are/were reading it
do/did care about their product.

> I don't care what IDE you want to talk about, they all break when we push them in unexpected ways, and as developers, we tend to push tools to fit our workflows, not to conform to theirs. I think if you look at your problems, and get serious about understanding them, you will find that you are creating some of your own problems.

<snip>

This is one of the few grown up responses on this topic. I started programming more than 40 years ago and very soon learned to ask "What am I doing wrong here and why?" when the inevitable unexpected occurred.

Many of the complaints about the single window metaphor may be coming from programmers who only have a single monitor such as a laptop (but perhaps I'm wrong here.) A laptop is OK on a plane or off site. But I personally would not be able to be really productive unless I had a desktop system and all the peripherals that go with it. YMMV.

IAC I only have 2 monitors these days, (although before retiring always had at minimum 3) and can easily double click and get separate tabbed windows with xib's and library on one screen (an old 19" CRT) and the source code on my 30" Cinema. It all works well once I learned the new paradigm.

Which is what I decided to do rather than trying to preserve older habits from XC 3.
Like others I also have filed bug reports into the bottomless pit.
But that's all I'm asked to do - the rest is up to Apple. Meanwhile I just get on with it.

> Frustrations and operational bugs aside, I believe the underlying issue many developers have is that the Xcode 4 redesign is based on a flawed model: an all-in-one "this way or the highway" workflow. No one seems to know why it was changed. What was the problem in Xcode 3 that brought us Xcode 4? New management team, perhaps?
>
> Xcode 3 (and previous) had an inherent flexibility that allowed a developer to develop HIS OWN WAY.

Exactly. Having to continually go backward and forward through the recent files, or having to remember you already have a file open in another tab, or (on the not so uncommon chance that you do this by mistake when you double-click a file/link) trying to keep track of separate windows when the monolithic project window (which is only usable if it's large) and bringing it forward hides the other windows, etc, is a big ol' pain in the ass. I can't work that way. It's worst than Visual Studio.

This is especially maddening when you're the new guy at a company whose hundreds of files are scattered all willy nilly and you need to keep a couple dozen open at all times just so you can refer to them. It's NOT a good way to get stuff done. Period. Using a separate *small* project window and separate source windows IS the way to get stuff done (like Xcode 3's Condensed layout). Bring it back, Apple.

> Frustrations and operational bugs aside, I believe the underlying issue many developers have is that the Xcode 4 redesign is based on a flawed model: an all-in-one "this way or the highway" workflow. No one seems to know why it was changed. What was the problem in Xcode 3 that brought us Xcode 4? New management team, perhaps?

To me, the biggest issue is Xcode 4.3 unreliability, not usability. If reliability is fixed, then we can start talking about usability, all IMHO.

*No*. I've said it before (right here) and I'll say it again; this is *not* jumping to the documentation, and it is *not* doing what Xcode 3 did. It switches to the documentation window and it enters the double-clicked word into the search field, and it does the search, but it ****doesn't display the actual documentation**** on the double-clicked word.

Compare simple Option-click. It brings up the hated Quick Help pop-up, but at least if you then click on the tiny "book" icon you are shown *the actual documentation* on the clicked term. What is wanted is a simple *direct* way to do *that* (without the intermediate clicking on the tiny book icon). That is what Xcode 3 used to do.

Also, reverting to Option-double-click: if this search word is a method name with multiple parameters, it enters the term incorrectly so it's useless. For example:

Option-double-click on "application:" and it wrongly enters "application" in the search field, when it should be "application:didFinishLaunchingWithOptions:". Pretty lame, eh?

<wildAndCrazy>

Once again I put forward my pet wild-and-crazy "dog food" theory that the people at Apple do not actually *use* Xcode for serious work. I know it sounds wild and crazy, but I have two kinds of evidence for this theory:

(1) Apple employees are right there on the spot, in the same building as the people who write Xcode, so if they really needed to get work done with Xcode they'd insist on having those problems solved.

(2) Watch the WWDC 2011 videos *carefully* and look at how the presenters interact with Xcode 4. They encounter bugs all the time and either skip past them or are stymied by them. This makes me think they are not familiar with or dependent on Xcode in their real lives.

> Yes, by a standard of "higher quality" that ignores its not providing 3/4 of the functionality you say you need. By that standard, "cat > main.m" is your ideal IDE.
>

No. I use Xcode maybe a couple of times a week for short spells. Typically I'd use it to add another entity to a model, change a build setting, or tweak a nib. I'm in AppCode the vast majority of my time.

AppCode provides a far larger and more functional set of facilities for writing and maintaining code and running unit tests than does Xcode. It doesn't crash, and JetBrains communicates really well about the problems it does have. They fix bugs, quickly. They let you see their progress on bugs and features. The entire experience is orders of magnitude better than with Xcode.

I'll be honest, this discussion has alot of 'it crashes' and 'it's unreliable' in it, but I am not seeing specific cases, which others might be able to offer workarounds. Yes, sometimes the workaround is 'don't do that' but so far the ONLY issue I have found that I cannot work around is one that I have not sorted out a rhyme or reason to (yet). That problem is that every couple of weeks, I will start a debug session, and it will simply hang there, requiring a force quit and restart. Of the 'Crashing', I have seen it, but as far as I can tell it is always when I do something I know better than to to, open a project that that is a linked 'subproject' that is already open in another workspace. Could it be handled better? sure. but I know not to do it, and generally avoid it.

Short version, quit kvetching about generalities, post specific issues, and let the community gnaw on them.

On Feb 29, 2012, at 4:58 PM, Laurent Daudelin wrote:

> On Feb 29, 2012, at 09:37, Nathan Sims wrote:
> >> Frustrations and operational bugs aside, I believe the underlying issue many developers have is that the Xcode 4 redesign is based on a flawed model: an all-in-one "this way or the highway" workflow. No one seems to know why it was changed. What was the problem in Xcode 3 that brought us Xcode 4? New management team, perhaps?>
> To me, the biggest issue is Xcode 4.3 unreliability, not usability. If reliability is fixed, then we can start talking about usability, all IMHO.
>
> -Laurent.
> --
> Laurent Daudelin
> AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/
> Logiciels Nemesys Software <laurent...>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<dru...>
>
> This email sent to <dru...>
>

>
> Exactly. Having to continually go backward and forward through the recent files, or having to remember you already have a file open in another tab, or (on the not so uncommon chance that you do this by mistake when you double-click a file/link) trying to keep track of separate windows when the monolithic project window (which is only usable if it's large) and bringing it forward hides the other windows, etc, is a big ol' pain in the ass. I can't work that way. It's worst than Visual Studio.
>
> This is especially maddening when you're the new guy at a company whose hundreds of files are scattered all willy nilly and you need to keep a couple dozen open at all times just so you can refer to them. It's NOT a good way to get stuff done. Period. Using a separate *small* project window and separate source windows IS the way to get stuff done (like Xcode 3's Condensed layout). Bring it back, Apple.

There's an actual simple fix to this that I've put up in Radar. I like the multiple window interface, but I also work with Visual Studio and NetBeans so I can work just as well in the tabbed interface. The big problem is the tabs are NOT consistent.

If you have a tab open, and click the file in the navigator, it will open over that tab; if you double-click, it will open in another tab EVEN if the original already exists.

The solution is to just do it the same way NetBeans, Eclipse, and Visual Studio do it. A double click to open a file. If the tab exist, bring that tab to the front. If it doesn't, create a new one. Or give us that option in preferences. The tabs containing the navigation pane (and changing it when they are changed, also in radar) and the weird way it creates tabs are so completely different from other environments that it's quite bizarre the behavior ever got in there :)

The big thing is development environments are not apps that are used by the general population; they are very old apps, they've been around for decades, and they all work in a similar way for a reason. Sometimes re-inventing the wheel is a great thing, sometimes it isn't.

> If you have a tab open, and click the file in the navigator, it will open over that tab; if you double-click, it will open in another tab EVEN if the original already exists.
>
> The solution is to just do it the same way NetBeans, Eclipse, and Visual Studio do it. A double click to open a file. If the tab exist, bring that tab to the front. If it doesn't, create a new one. Or give us that option in preferences. The tabs containing the navigation pane (and changing it when they are changed, also in radar) and the weird way it creates tabs are so completely different from other environments that it's quite bizarre the behavior ever got in there :)

This is what I've been most bothered about in Xc4. I've written several bugs about it. I think of it as a document-window binding. That is, a document should "belong" to a window (and vice-versa).

Note that "document" is used loosely. Of course, source files are actual documents, but you can also think of an execution context as a document in this concept. For example, if I debug my app on one device, that should open a debug-specific window (or bring said window forward). That window should remember its shape and position. If I debug my app on the sim, a *different* debug-specific window should open (or come forward).

> This is one of the few grown up responses on this topic. I started programming more than 40 years ago and very soon learned to ask "What am I doing wrong here and why?" when the inevitable unexpected occurred.
>
> Many of the complaints about the single window metaphor may be coming from programmers who only have a single monitor such as a laptop (but perhaps I'm wrong here.) A laptop is OK on a plane or off site. But I personally would not be able to be really productive unless I had a desktop system and all the peripherals that go with it. YMMV.

My Mileage varies indeeed. I code quite happily on single-monitor setups in Xc4s single-window layout. On my dual-monitor setup, usually Xcode Windows stay on one screen, the other is reserved for other stuff

Xcode 4 is not as reliable as we would like it to be, and I swear at it occasionally when it crashes and does other silly things. But I still belive Xc4 is a step in the right direction.

>
> But the point was that the open QA program made sure the product wasn't a complete barge of garbage and it was simply badly needed and IMHO, a stellar, non traditional and very successful way to do it.
>

Interesting anecdote, and well put. There are companies that have similarly open processes now, JetBrains and Atlassian are the two examples I'm familiar with. It seems to work.

But Apple's process also can work well, sometimes spectacularly so (their OSs; iWork, plenty more). So why the difference with Xcode? Is it that a closed process doesn't work well for dev tools in particular? (both the companies I mentioned are in this space). Or has Apple just under-resourced Xcode, knowing that people are going to make great software for the AppStore(s) pretty much regardless?

I totally agree with you Matt.
Not being able to quickly access documentation from code is a major pain :(

Thomas

ps: I have filed a bug report long time ago about this but nothing has changed.

On Feb 29, 2012, at 11:13 PM, Matt Neuburg <matt...> wrote:

> On Wed, 29 Feb 2012 00:09:36 -0800, Joar Wingfors <joar...> said:>>
>> On 28 feb 2012, at 22:26, Lee Ann Rucker wrote:
>> >>> Plus there's no [...] jump to documentation.>>
>>
>> Is too!
>>
>> Option+DoubleClick>
> *No*. I've said it before (right here) and I'll say it again; this is *not* jumping to the documentation, and it is *not* doing what Xcode 3 did. It switches to the documentation window and it enters the double-clicked word into the search field, and it does the search, but it ****doesn't display the actual documentation**** on the double-clicked word.
>
> Compare simple Option-click. It brings up the hated Quick Help pop-up, but at least if you then click on the tiny "book" icon you are shown *the actual documentation* on the clicked term. What is wanted is a simple *direct* way to do *that* (without the intermediate clicking on the tiny book icon). That is what Xcode 3 used to do.
>
> Also, reverting to Option-double-click: if this search word is a method name with multiple parameters, it enters the term incorrectly so it's useless. For example:
>
> - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
>
> Option-double-click on "application:" and it wrongly enters "application" in the search field, when it should be "application:didFinishLaunchingWithOptions:". Pretty lame, eh?
>
> <wildAndCrazy>
>
> Once again I put forward my pet wild-and-crazy "dog food" theory that the people at Apple do not actually *use* Xcode for serious work. I know it sounds wild and crazy, but I have two kinds of evidence for this theory:
>
> (1) Apple employees are right there on the spot, in the same building as the people who write Xcode, so if they really needed to get work done with Xcode they'd insist on having those problems solved.
>
> (2) Watch the WWDC 2011 videos *carefully* and look at how the presenters interact with Xcode 4. They encounter bugs all the time and either skip past them or are stymied by them. This makes me think they are not familiar with or dependent on Xcode in their real lives.
>
> :)
>
> </wildAndCrazy>

The problem often seems to be that Apple will choose the most complicated
yet half-assed solution to problems that shouldn't even merit much design
time, or that have already been solved quite well by others. Witness the
fact that there's not even an option to keep files sorted alphabetically in
the treeview. What file browser on the planet doesn't do that? The
workaround is a manually triggered sort, that you have to do over and over.
Under what priority system does this become the FIRST design to implement?
Then again, it comes from the company that gave us Finder, the only file
browser that doesn't put folders where they belong: AT THE TOP.

Another result of this approach is that it turns people off to what should
have been a step forward. The single-window design should have cleaned
things up immensely, and saved the time formerly spent herding windows
around the screen. Whee, we can actually minimize or resize Xcode now!
And yet the implementation is so bizarre, not to mention overblown, that
one wonders how they ever arrived at it. And for those who like floating
windows, the tear-off tab option should have been acceptable (I'm going by
people's comments); but again the implementation is defective.

They even got rid of time-saving enhancements, like the "switch to
counterpart" button. Now you have to dig through a menu. And the
"assistant" or whatever it is randomly decides to stop showing counterparts
by default and switches to "manual" mode, showing arbitrary files when
activated. Then when you hit a breakpoint, Xcode decides to switch the
contents of the first editing pane to show it, even when it's already
available in another pane. Come to think of it, I waste as much time
cajoling Xcode to show the file I want in each pane as I would herding
windows around. And Xcode 3's all-in-one view didn't mess up the editing
panes anywhere near as much.

I used Visual C++ starting with version 1, continuing through Visual
Studio's latest incarnation. Today it suffers from the same idiotic
defects (and several more) that it did almost 20 years ago. But one thing
it does far better than Xcode: UI management. It's incredible that the
Xcode team would change the UI so radically, but ignore the example set by
the dominant IDE and proven effective over many, many years:

They should go back and implement exactly this UI and work forward from
there. Xcode has come a long way since Project Builder, and now does
several things better than Visual Studio. I prefer Cocoa to MFC, and the
far more standard environment. But Apple and the Xcode team need to
abandon what appears to be a petty refusal to acknowledge that,
occasionally, someone else has a better way of doing things.

> You know, I find this comical to read. No Xcode is not perfect. Yes it has issues, but here is the thing, I prefer IDE development, and I have used a bunch over the years. Let us call a spade a spade. They all suck in new and glorious ways. Xcode is has some really great features, along with some really silly bugs. Most of the bugs have workarounds, but a few are truly annoying. The problem is, so do most of the other options. You mention VS specifically.
>
> Visual Studio is a nice tool, but then again, the C++ tool chain has not changed in any significant manner in over 7 years, and has in many ways regressed from the Vs6 days. visual Studio is a good tool for .net development, particularly in the c# world. For C++ it is a mediocre tool, at best, and is handicapped by inconsistent behaviors of the underlying frameworks. Like Xcode, it is not perfect, I crashed it three times today working with cross platform STL code.
>

I've never had it crash one while doing VB 6, though - granted - most of my app development there is database front-ends for MS Access databases. Ditto for VS for .Net and VB.Net - no crashes there, either.

> But look deeper. What about other tools, like Delphi, or RealStudio., or even the open source MonoDevelop. Delphi is probably more like Xcode in terms of what it does with it's integrated UI tools, and it's robust underlying framework(s). With current versions, you can target windows or OS x with the same code base. It works, but I crash it multiple times a day as well.
>
> RealStudio is another one, cross platform, robust library. Compares well to Visual basic 6 circa 2002.
>

Actually, even better as RB has OO features way above VB 6. There are minor annoyances with some IDE bugs - especially the debugger. Anyone see a pattern here? :)

> MonoDevelop? Great tool, nice workable tool chain. Kicks off much of visual studio, it crashes often and strangely.
>
> But here is the thing, Xcode and Visual Studio are platform specific, the others are not. At least Xcode can be, and it is very flexible. It is moving forward, and there are some bits that have surpassed vs.net, others it lags behind.
>
> Ultimately though, you will never convince people that are comfortable in one platform that another is better. Witness the vim/emacs wars. Use the tool that works for you, and grasp that Xcode and Visual Studio do not play well together. The dialect of c++ that Vs devs use is laced with incompatible macros that do not play well with other platforms. It takes work and discipline to make them play well together.
>

Though I think that says more about the C++ standard (or lack thereof), than of C++ itself. I also notice you didn't mention LiveCode or Eclipse IDEs

> Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad
>
> On Feb 28, 2012, at 3:48 PM, Jeffrey Walton <noloader...> wrote:
> >> On Tue, Feb 28, 2012 at 2:27 PM, Thomas CLEMENT <tclementdev...> wrote:>>> What is it called in software development when you're introducing bugs faster than you're fixing them? Because this is the problem the Xcode development team is facing here.>> Alpha.
>> >>> On 28 févr. 2012, at 19:37, koko <koko...> wrote:
>>> >>>> Cannot see strings in 4.3 …. and 4.3 sure does do goofy things …. lots of (Empty editor) entries in the Window menu which propagate to the 4.2.1 window menu.
>>>>
>>>> I use a library Str Lib which is a string class. Until 4.3 right clicking on the local variable and choosing show memory of *dptr would reveal the string … in 4.3 it display an empty memory panel.
>>>>
>>>> After giving Xcode 4 kudos I must recall all such praise … Xcode 4 is a severe impediment to timely software development and I am tired of trying to defend it against Visual Studio 2010 which my mates use.
>>>>
>>>> Apple and Xcode are an embarrassment to professional software development.
>>>>
>>>> Come on Apple, get with it or give back MPW at least it did not crash all the time.
>>>>
>>>> -koko>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (<Xcode-users...>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/xcode-users/<dru...>
>>
>> This email sent to <dru...>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<wsquires...>
>
> This email sent to <wsquires...>

See, on the Mac and in the Finder, this pretty much never mattered, you could simply click in the Finder Window and type out the name of the file/folder you wanted to navigate to it. Why people actually like this feature (and want it) is beyond my meager comprehension.

- Alex Zavatone

On Mar 01, 2012, at 06:04 AM, G S <stokestack...> wrote:

The problem often seems to be that Apple will choose the most complicated yet half-assed solution to problems that shouldn't even merit much design time, or that have already been solved quite well by others. Witness the fact that there's not even an option to keep files sorted alphabetically in the treeview. What file browser on the planet doesn't do that? The workaround is a manually triggered sort, that you have to do over and over. Under what priority system does this become the FIRST design to implement? Then again, it comes from the company that gave us Finder, the only file browser that doesn't put folders where they belong: AT THE TOP.

Another result of this approach is that it turns people off to what should have been a step forward. The single-window design should have cleaned things up immensely, and saved the time formerly spent herding windows around the screen. Whee, we can actually minimize or resize Xcode now! And yet the implementation is so bizarre, not to mention overblown, that one wonders how they ever arrived at it. And for those who like floating windows, the tear-off tab option should have been acceptable (I'm going by people's comments); but again the implementation is defective.

They even got rid of time-saving enhancements, like the "switch to counterpart" button. Now you have to dig through a menu. And the "assistant" or whatever it is randomly decides to stop showing counterparts by default and switches to "manual" mode, showing arbitrary files when activated. Then when you hit a breakpoint, Xcode decides to switch the contents of the first editing pane to show it, even when it's already available in another pane. Come to think of it, I waste as much time cajoling Xcode to show the file I want in each pane as I would herding windows around. And Xcode 3's all-in-one view didn't mess up the editing panes anywhere near as much.

I used Visual C++ starting with version 1, continuing through Visual Studio's latest incarnation. Today it suffers from the same idiotic defects (and several more) that it did almost 20 years ago. But one thing it does far better than Xcode: UI management. It's incredible that the Xcode team would change the UI so radically, but ignore the example set by the dominant IDE and proven effective over many, many years:

They should go back and implement exactly this UI and work forward from there. Xcode has come a long way since Project Builder, and now does several things better than Visual Studio. I prefer Cocoa to MFC, and the far more standard environment. But Apple and the Xcode team need to abandon what appears to be a petty refusal to acknowledge that, occasionally, someone else has a better way of doing things.

>
> I used Visual C++ starting with version 1, continuing through Visual Studio's latest incarnation. Today it suffers from the same idiotic defects (and several more) that it did almost 20 years ago. But one thing it does far better than Xcode: UI management. It's incredible that the Xcode team would change the UI so radically, but ignore the example set by the dominant IDE and proven effective over many, many years:
>
> http://farm6.staticflickr.com/5027/5580217267_3e8c21d599_b.jpg
>

This btw is almost exactly AppCode's default layout. It really is only a default -- everything can be kept in separate windows if desired -- but it's a practical and (for many) familiar one.

Ahhh, Alex. Good times. Nice to see you on the list. This thread is beginning to remind me of Hopper-Ex. ;)

I have to agree that, I too have become reticent to submit bugs. It just feels too much like I've wasted 20 minutes or so on writing up regression steps etc... only to toss them into the ether when i hit "submit".. (May as well be the trash).

As a QA Team Lead at Macromedia from '98-'04, (and brief stint as dev engineer before leaving) I remember well that we were VERY hands-on with our Director users and bug submissions. Once submitted, each bug was given personal attention by a responsible QA 'Feature Lead'. Users were informed of their bug number and QA Response (New, Dupe, Fixed, Deferred, etc..). Often, a dialogue was started with the bug submitter that gave us more insight into how the product was being used than any of the on-site visits or web-surveys we posted.

Arguably, it's a "free" IDE and the user-base is larger than Director's. But, it's also the face of Apple development and the only real tool for IOS/Cocoa development since Apple squashed competitors by making xcode free. ~ Which, in my mind, means there's even more responsibility to "get it right".

Also, it's 12yrs later. So there's really no excuse for the lack of feedback. (i.e. There are much more robust and scriptable bugbases out there today than the hand-rolled Filemaker Pro one that ran on a Mac Plus in the corner of the QA Lab back in the 90's).

Director listserv's were a great mix of end-users and engineers (both QA and Dev), providing a feedback loop that really worked.

> Then Rob Burgess put the dev team in the basement and it took Steve Jobs to ask Macromedia to put out an OS X version of Director. Then several teams in India cratered it and turned it into a bad Windows port.

Yes. Sadly. OT. The cratering came as Rob's plan to get rid of engineering overhead and make macr more attractive to Adobe. Net result: mediocre product, abandoned user base, laid off or disbursed workers and lower profit == shelved product.

XCode 4 kind of reminds me of the (lame) attempt that was made to pull Flash users into Directorland by blurring the lines between the IDEs. It didn't work.

Personally, I find the workflow to be a frustratingly clunky non-Apple (I have to say WINDOWS) experience that pigeonholes me into a way of working that is rigid and uncomfortable. (Not to mention fraught with hideous UI bugs).

I dunno, Crash bugs are "Show Stoppers" in my book. - Not sure what book everyone else is reading.

jp

On Feb 29, 2012, at 8:00 AM, Alex Zavatone wrote:

>
> On Feb 29, 2012, at 9:57 AM, Jean-Daniel Dupas wrote:
> >>
>> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
>> >>> You need to spend time in the "good" ones then. The same issues exist.>>
>> That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
>> And yes, I have a bug opened about this issue.>
> As a guy who ran one of the Shockwave QA and beta programs back in the mid/late '90s, it's simply hard for me to spend the time to enter a bug. There is no guarantee that my time will be spent well. I know I'm not going to be notified if the bug is to have any resolution. If the bug is closed, marked a dup, will be addressed, or not, I'm never going to know. For me to write up a proper bug report that doesn't waste the developer's time, then I have to spend a lot of time. But I'm never going to get an answer and that leaves the users in a bad state.
>
> Now, this is not normally possible, for time and corporate image factors, but here is what I did, and why it matters.
>
> I got on the Director listserv email lists in 1994/1995 and said this:
>
> "Hey guys, we're going to do this new product that's going to allow you to take your CD ROM product, modify it (a lot) and deliver it (to some extent) over this new 'Internet' thing. I'm willing to open this up to you guys. If you want to be part of the Beta for Shockwave, then you will need to be able to report the bugs and issues to me as if I were 3 years old and give me the code that is causing the problem in a simple case (remember, I'm not next to your desk and have no idea what's going on). In turn, what I will do is PERSONALLY enter your bugs in our database and make sure they get looked at. To the best of my ability, I'll tell you if something's going to be fixed or not, so you can find a work around if needed. The point here is that you are not submitting requests to a black hole.
>
> I'm going to set up a new list, Shocker-L and will be monitoring the list on a daily (hourly) basis. Lemmie know if you want to join by sending me an email and I'll put on the Shockwave Beta program, but I expect you to participate. Please feel free to email me directly."
>
>
> So, we did this, and I ran the whole effort. We increased out QA effort by a factor of THREE with no additional staff and got out a much better product (on Windows first, then the Mac) than we ever could have hoped without this openness.
>
> We were not apologetic or spinmeisters (well, one other great very knowledgeable guy sadly was), we called a bug a bug, we addressed them, some were not fixed, but we ended up putting out the product that really created multimedia on the internet and it was enough to keep Macromedia in business for time after the CD ROM market tanked.
>
> We had a following for quite a while until Flash took over and it was good for the company and good for our users.
>
> Then Rob Burgess put the dev team in the basement and it took Steve Jobs to ask Macromedia to put out an OS X version of Director. Then several teams in India cratered it and turned it into a bad Windows port.
>
> But the point was that the open QA program made sure the product wasn't a complete barge of garbage and it was simply badly needed and IMHO, a stellar, non traditional and very successful way to do it.
>
> Cheers,
> - Alex Zavatone
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<nina...>
>
> This email sent to <nina...>

>
> .. it's also the face of Apple development and the only real tool for IOS/Cocoa development

That isn't really true any more. JetBrains' offering replaces Xcode for most purposes, and is superior at everything it does do. I'm delighted there's some competition at last. Paradoxically, though, this currently depends on Xcode remaining free, as it's still needed for Interface Builder and Core Data modelling.

> since Apple squashed competitors by making xcode free. ~ Which, in my mind, means there's even more responsibility to "get it right".

Responsibility, yes. But incentive, unfortunately, no. They don't make money from it, and there's no near-term risk of developers fleeing the platform, whatever Xcode's condition.

> The problem often seems to be that Apple will choose the most complicated
> yet half-assed solution to problems that shouldn't even merit much design
> time, or that have already been solved quite well by others. Witness the
> fact that there's not even an option to keep files sorted alphabetically in
> the treeview. What file browser on the planet doesn't do that? The
> workaround is a manually triggered sort, that you have to do over and over.
> Under what priority system does this become the FIRST design to implement?
> Then again, it comes from the company that gave us Finder, the only file
> browser that doesn't put folders where they belong: AT THE TOP.
> [...]
> It's incredible that the Xcode team
> would change the UI so radically, but ignore the example set by the dominant
> IDE and proven effective over many, many years:
>
> http://farm6.staticflickr.com/5027/5580217267_3e8c21d599_b.jpg
>
> They should go back and implement exactly this UI and work forward from
> there.

Your opinions sounds very windows-centric. Just like the mac, windows
doesn't get everything right. I've moved in an out of developing with
Visual C++/Visual Studio and it's never been a satisfying experience.
Just because I like the emacs experience doesn't mean you should, or
should have to work that way. You should work in whatever way is most
productive for you. IMHO, the biggest failing of every IDE I've used
is that they are only able to work ONE WAY, and if you do not conform,
then you are doomed to frustration at best.

> Xcode has come a long way since Project Builder

Actually, I rather liked Project Builder--at least the one on
NeXTStep. Did one thing, and did it well.

> That isn't really true any more. JetBrains' offering replaces Xcode for most purposes, and is superior at everything it does do. I'm delighted there's some competition at last. Paradoxically, though, this currently depends on Xcode remaining free, as it's still needed for Interface Builder and Core Data modelling.

> Responsibility, yes. But incentive, unfortunately, no. They don't make money from it, and there's no near-term risk of developers fleeing the platform, whatever Xcode's condition.

Yes, that was a discussion I was having the other day as well; How to quantify the value of putting money into proper product development for (a free) xcode, based on the impact on the quantity or quality of applications developed and revenue generated by AppStore sales. Something I imagine is just too tough to quantify for the bean counters.

On the other hand, $200 for a "near total solution that still requires a full install of the app you're attempting to replace.." seems quite a stretch from Free. (Only my opinion)

Though I have to say, to each his/her own. Which is to say, if you want to be able to configure your IDE to look like something else that you're familiar with, you should be able to do so.

Personally, I would like the flexibility to create window groups (much like Logic Audio.. and I guess Photoshop and Director have them as well ...) that allow me to set up key commands to switch between different window configurations. Complex - maybe, but robust enough to satisfy anyone's workflow.

>
>
> On the other hand, $200 for a "near total solution that still requires a full install of the app you're attempting to replace.." seems quite a stretch from Free. (Only my opinion)
>

Well, (assuming you're talking about AppCode) it's free for open-source projects, and $99 for indies. I don't know whether or not it qualifies as a rational purchase, but Xcode would need years' worth of development to catch up with it. My work is a pleasure again, rather than a fight.

> >> http://farm6.staticflickr.com/5027/5580217267_3e8c21d599_b.jpg>
> Yikes! Frightening.
>
> Though I have to say, to each his/her own. Which is to say, if you want to be able to configure your IDE to look like something else that you're familiar with, you should be able to do so.
>
> Personally, I would like the flexibility to create window groups (much like Logic Audio.. and I guess Photoshop and Director have them as well ...) that allow me to set up key commands to switch between different window configurations. Complex - maybe, but robust enough to satisfy anyone's workflow.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<michael.lehn...>.
de
>
> This email sent to <michael.lehn...>

ok Crispin has been talking about AppCode so I downloaded it a couple of days back when it was first mentioned and stuck through a day of not knowing that function key did what. It's very good, very good indeed, my coding speed has gone up, simple tasks I do dozens of times a day like add and synthesize properties with my own backing variables are easier, function extraction, code refactoring, all much easier to do.

I haven't crashed it yet either.

I like it enough to buy it at this point although I will keep using the free demo for a while just incase I find something horrible, not expecting to. I never used any of the other JetBrains products so it's not like I'm used to the 'JetBrains' way, I had to learn from scratch but found almost everything obvious.

That's a pretty good example of an IDE which really supports programmer productivity, understands the code at more than a surface level and really makes the coding part, which is what I spend most of my time doing, easier. And this is a 1.0 release, interested to see where it goes from here.

On Mar 2, 2012, at 3:15 PM, Crispin Bennett wrote:

>
> On 02/03/2012, at 4:00 PM, jp wrote:
> >>
>>
>> On the other hand, $200 for a "near total solution that still requires a full install of the app you're attempting to replace.." seems quite a stretch from Free. (Only my opinion)
>> >
> Well, (assuming you're talking about AppCode) it's free for open-source projects, and $99 for indies. I don't know whether or not it qualifies as a rational purchase, but Xcode would need years' worth of development to catch up with it. My work is a pleasure again, rather than a fight.
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<rols...>
>
> This email sent to <rols...>

>
> On 02/03/2012, at 4:00 PM, jp wrote:
> >>
>>
>> On the other hand, $200 for a "near total solution that still requires a full install of the app you're attempting to replace.." seems quite a stretch from Free. (Only my opinion)
>> >
> Well, (assuming you're talking about AppCode) it's free for open-source projects, and $99 for indies. I don't know whether or not it qualifies as a rational purchase, but Xcode would need years' worth of development to catch up with it. My work is a pleasure again, rather than a fight.

>
> On Feb 29, 2012, at 19:50 , Brian Barnes wrote:
> >> If you have a tab open, and click the file in the navigator, it will open over that tab; if you double-click, it will open in another tab EVEN if the original already exists.
>>
>> The solution is to just do it the same way NetBeans, Eclipse, and Visual Studio do it. A double click to open a file. If the tab exist, bring that tab to the front. If it doesn't, create a new one. Or give us that option in preferences. The tabs containing the navigation pane (and changing it when they are changed, also in radar) and the weird way it creates tabs are so completely different from other environments that it's quite bizarre the behavior ever got in there :)>
> This is what I've been most bothered about in Xc4. I've written several bugs about it. I think of it as a document-window binding. That is, a document should "belong" to a window (and vice-versa).
>
> Note that "document" is used loosely. Of course, source files are actual documents, but you can also think of an execution context as a document in this concept. For example, if I debug my app on one device, that should open a debug-specific window (or bring said window forward). That window should remember its shape and position. If I debug my app on the sim, a *different* debug-specific window should open (or come forward).
>
> My project is yet another document...

This has been mentioned several times - here and elsewhere. I called it the "spatial" model, in reference to the spatial Finder that Mac OS X has gotten away from, much to the disappointment of many, especially John Siracusa in his series of Mac OS reviews. I and others have beaten that horse so thoroughly the poor beast is completely dead. Despite un-humanly hurting that animal, Apple has never even once acknowledged the possibility that there might be something to it, stubbornly driving many of us mad until we broke the bank to buy a couple of screens the size of a football field. As we say in French, all that amounted to no more than "pisser dans un violon" (look it up if you like). At this point in time, I have personally lost any hope for Apple to show any care about this issue (as well as about a few others, first and foremost its bug filing tool). I have now come to live with the fact that every time Xcode replaces the content of a pane against my will, God kills a kitten (or two). Yes I know, many dead animals in this sorry story - though not enough bugs.

You don't have to let Visual Studio look like that. Mine certainly doesn't. I think it looks a bit like that when you first run it, but you can move stuff around to arrange it all the way you like. You can attach panels to the main window in a tiling fashion, group them in tab groups, then tear panels or tab groups off to create their own top-level windows. I don't want to sound like I'm advocating anarchy, nor that I subscribe to the most un-Apple like theory that Big Brother does not know best, but I think that Xcode 4.x would benefit from some of this sort of configurability.

The Visual Studio experience isn't perfect by any means. Torn-off panels aren't true top-level windows, and, ridiculously, you can't open the same file in multiple windows. But you can put things where you want, at least. It would be nice to have that in Xcode.

--Tom

On 2 Mar 2012, at 06:52, jp wrote:

> >> http://farm6.staticflickr.com/5027/5580217267_3e8c21d599_b.jpg>
> Yikes! Frightening.
>
> Though I have to say, to each his/her own. Which is to say, if you want to be able to configure your IDE to look like something else that you're familiar with, you should be able to do so.
>
> Personally, I would like the flexibility to create window groups (much like Logic Audio.. and I guess Photoshop and Director have them as well ...) that allow me to set up key commands to switch between different window configurations. Complex - maybe, but robust enough to satisfy anyone's workflow.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<xcode-users...>
.plus.com
>
> This email sent to <xcode-users...>

But the only barrier here is legal and marketing and an immense lack of balls.

Decision makers would really not want to admit that there are so many bugs in their product. It "could" look bad for Apple but the right thing would be to have a 2 way relationship with the customers reporting the problem so that the issues could get fixed faster while not exposing the Apple employee's real internal email address to the world. Something like a managed email account for each bug should be automatically set up.

Damn, that's a patent right there that I'm not going to be able to file. Ohh well.

But there are ways to do this that DRASTICALLY increase the productivity of the dev teams fixing the product AND drastically increases the quality of the product.

You NEED people on the Xcode lists from Apple just like we used to do in the Hopper-Ex, Direct-L and Shocker days.

Some of those guys need to be the product directors. It's us who ARE YOUR CUSTOMERS and if you fix what we hate - INSTEAD OF COMPLETELY REDESIGNING THE THING WITHOUT ENOUGH TIME TO DO IT PROPERLY - then we are both left with a system THAT WORKS and one THAT WE LIKE.

I mean, that's almost crazy enough to work!

Seriously. That is how you do it.

And most of all, it takes balls to admit that, "yes, we have some things that are wrong with our product". But if you do not admit to them, then all you get is a marketing message/blatant lie of "everything's fine" and the product doesn't improve.

Apple needs to have an open continuous dialog with its customers and not pull the "look at us, we are in the club, aren't we important and chatty" BS that was the Lion beta users forum.

Cheers man.

On Mar 1, 2012, at 8:24 PM, jp wrote:

> Ahhh, Alex. Good times. Nice to see you on the list. This thread is beginning to remind me of Hopper-Ex. ;)
>
> I have to agree that, I too have become reticent to submit bugs. It just feels too much like I've wasted 20 minutes or so on writing up regression steps etc... only to toss them into the ether when i hit "submit".. (May as well be the trash).
>
> As a QA Team Lead at Macromedia from '98-'04, (and brief stint as dev engineer before leaving) I remember well that we were VERY hands-on with our Director users and bug submissions. Once submitted, each bug was given personal attention by a responsible QA 'Feature Lead'. Users were informed of their bug number and QA Response (New, Dupe, Fixed, Deferred, etc..). Often, a dialogue was started with the bug submitter that gave us more insight into how the product was being used than any of the on-site visits or web-surveys we posted.
>
> Arguably, it's a "free" IDE and the user-base is larger than Director's. But, it's also the face of Apple development and the only real tool for IOS/Cocoa development since Apple squashed competitors by making xcode free. ~ Which, in my mind, means there's even more responsibility to "get it right".
>
> Also, it's 12yrs later. So there's really no excuse for the lack of feedback. (i.e. There are much more robust and scriptable bugbases out there today than the hand-rolled Filemaker Pro one that ran on a Mac Plus in the corner of the QA Lab back in the 90's).
>
> Director listserv's were a great mix of end-users and engineers (both QA and Dev), providing a feedback loop that really worked.
> >> Then Rob Burgess put the dev team in the basement and it took Steve Jobs to ask Macromedia to put out an OS X version of Director. Then several teams in India cratered it and turned it into a bad Windows port.>
>
> Yes. Sadly. OT. The cratering came as Rob's plan to get rid of engineering overhead and make macr more attractive to Adobe. Net result: mediocre product, abandoned user base, laid off or disbursed workers and lower profit == shelved product.
>
> XCode 4 kind of reminds me of the (lame) attempt that was made to pull Flash users into Directorland by blurring the lines between the IDEs. It didn't work.
>
> Personally, I find the workflow to be a frustratingly clunky non-Apple (I have to say WINDOWS) experience that pigeonholes me into a way of working that is rigid and uncomfortable. (Not to mention fraught with hideous UI bugs).
>
> I dunno, Crash bugs are "Show Stoppers" in my book. - Not sure what book everyone else is reading.
>
> jp
>
>
> On Feb 29, 2012, at 8:00 AM, Alex Zavatone wrote:
> >>
>> On Feb 29, 2012, at 9:57 AM, Jean-Daniel Dupas wrote:
>> >>>
>>> Le 29 févr. 2012 à 13:56, Andrew Satori a écrit :
>>> >>>> You need to spend time in the "good" ones then. The same issues exist.>>>
>>> That's wrong. I don't know any IDE but Xcode that force me to hard reboot my machine 10 times a day.
>>> And yes, I have a bug opened about this issue.>>
>> As a guy who ran one of the Shockwave QA and beta programs back in the mid/late '90s, it's simply hard for me to spend the time to enter a bug. There is no guarantee that my time will be spent well. I know I'm not going to be notified if the bug is to have any resolution. If the bug is closed, marked a dup, will be addressed, or not, I'm never going to know. For me to write up a proper bug report that doesn't waste the developer's time, then I have to spend a lot of time. But I'm never going to get an answer and that leaves the users in a bad state.
>>
>> Now, this is not normally possible, for time and corporate image factors, but here is what I did, and why it matters.
>>
>> I got on the Director listserv email lists in 1994/1995 and said this:
>>
>> "Hey guys, we're going to do this new product that's going to allow you to take your CD ROM product, modify it (a lot) and deliver it (to some extent) over this new 'Internet' thing. I'm willing to open this up to you guys. If you want to be part of the Beta for Shockwave, then you will need to be able to report the bugs and issues to me as if I were 3 years old and give me the code that is causing the problem in a simple case (remember, I'm not next to your desk and have no idea what's going on). In turn, what I will do is PERSONALLY enter your bugs in our database and make sure they get looked at. To the best of my ability, I'll tell you if something's going to be fixed or not, so you can find a work around if needed. The point here is that you are not submitting requests to a black hole.
>>
>> I'm going to set up a new list, Shocker-L and will be monitoring the list on a daily (hourly) basis. Lemmie know if you want to join by sending me an email and I'll put on the Shockwave Beta program, but I expect you to participate. Please feel free to email me directly."
>>
>>
>> So, we did this, and I ran the whole effort. We increased out QA effort by a factor of THREE with no additional staff and got out a much better product (on Windows first, then the Mac) than we ever could have hoped without this openness.
>>
>> We were not apologetic or spinmeisters (well, one other great very knowledgeable guy sadly was), we called a bug a bug, we addressed them, some were not fixed, but we ended up putting out the product that really created multimedia on the internet and it was enough to keep Macromedia in business for time after the CD ROM market tanked.
>>
>> We had a following for quite a while until Flash took over and it was good for the company and good for our users.
>>
>> Then Rob Burgess put the dev team in the basement and it took Steve Jobs to ask Macromedia to put out an OS X version of Director. Then several teams in India cratered it and turned it into a bad Windows port.
>>
>> But the point was that the open QA program made sure the product wasn't a complete barge of garbage and it was simply badly needed and IMHO, a stellar, non traditional and very successful way to do it.
>>
>> Cheers,
>> - Alex Zavatone
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (<Xcode-users...>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/xcode-users/<nina...>
>>
>> This email sent to <nina...>>
>
>
>
>
>

Isn't the GUI pretty ugly though? The font and layout screams "this is Java" to me.

On Mar 1, 2012, at 11:37 PM, Crispin Bennett wrote:

> On 02/03/2012, at 11:24 AM, jp wrote:
> >>
>> .. it's also the face of Apple development and the only real tool for IOS/Cocoa development>
> That isn't really true any more. JetBrains' offering replaces Xcode for most purposes, and is superior at everything it does do. I'm delighted there's some competition at last. Paradoxically, though, this currently depends on Xcode remaining free, as it's still needed for Interface Builder and Core Data modelling.
> >> since Apple squashed competitors by making xcode free. ~ Which, in my mind, means there's even more responsibility to "get it right".>
> Responsibility, yes. But incentive, unfortunately, no. They don't make money from it, and there's no near-term risk of developers fleeing the platform, whatever Xcode's condition.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<zav...>
>
> This email sent to <zav...>

JP because it is like saying you sell things that require a stove to make, but don't want to make the stove.

On Mar 2, 2012, at 1:00 AM, jp wrote:

> >> That isn't really true any more. JetBrains' offering replaces Xcode for most purposes, and is superior at everything it does do. I'm delighted there's some competition at last. Paradoxically, though, this currently depends on Xcode remaining free, as it's still needed for Interface Builder and Core Data modelling.> >> Responsibility, yes. But incentive, unfortunately, no. They don't make money from it, and there's no near-term risk of developers fleeing the platform, whatever Xcode's condition.>
> Yes, that was a discussion I was having the other day as well; How to quantify the value of putting money into proper product development for (a free) xcode, based on the impact on the quantity or quality of applications developed and revenue generated by AppStore sales. Something I imagine is just too tough to quantify for the bean counters.
>
> On the other hand, $200 for a "near total solution that still requires a full install of the app you're attempting to replace.." seems quite a stretch from Free. (Only my opinion)
>
> jp
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<zav...>
>
> This email sent to <zav...>

Documenting your work flow would be a good thing. I don't know why your synthesizing properties would be faster in AppCode. Care to share?

On Mar 2, 2012, at 4:11 AM, Roland King wrote:

> ok Crispin has been talking about AppCode so I downloaded it a couple of days back when it was first mentioned and stuck through a day of not knowing that function key did what. It's very good, very good indeed, my coding speed has gone up, simple tasks I do dozens of times a day like add and synthesize properties with my own backing variables are easier, function extraction, code refactoring, all much easier to do.
>
> I haven't crashed it yet either.
>
> I like it enough to buy it at this point although I will keep using the free demo for a while just incase I find something horrible, not expecting to. I never used any of the other JetBrains products so it's not like I'm used to the 'JetBrains' way, I had to learn from scratch but found almost everything obvious.
>
> That's a pretty good example of an IDE which really supports programmer productivity, understands the code at more than a surface level and really makes the coding part, which is what I spend most of my time doing, easier. And this is a 1.0 release, interested to see where it goes from here.
>
> On Mar 2, 2012, at 3:15 PM, Crispin Bennett wrote:
> >>
>> On 02/03/2012, at 4:00 PM, jp wrote:
>> >>>
>>>
>>> On the other hand, $200 for a "near total solution that still requires a full install of the app you're attempting to replace.." seems quite a stretch from Free. (Only my opinion)
>>> >>
>> Well, (assuming you're talking about AppCode) it's free for open-source projects, and $99 for indies. I don't know whether or not it qualifies as a rational purchase, but Xcode would need years' worth of development to catch up with it. My work is a pleasure again, rather than a fight.
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (<Xcode-users...>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/xcode-users/<rols...>
>>
>> This email sent to <rols...>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<zav...>
>
> This email sent to <zav...>

>
> On 1 mars 2012, at 08:35, Rick Mann wrote:
> >>
>> On Feb 29, 2012, at 19:50 , Brian Barnes wrote:
>> >>> If you have a tab open, and click the file in the navigator, it will open over that tab; if you double-click, it will open in another tab EVEN if the original already exists.
>>>
>>> The solution is to just do it the same way NetBeans, Eclipse, and Visual Studio do it. A double click to open a file. If the tab exist, bring that tab to the front. If it doesn't, create a new one. Or give us that option in preferences. The tabs containing the navigation pane (and changing it when they are changed, also in radar) and the weird way it creates tabs are so completely different from other environments that it's quite bizarre the behavior ever got in there :)>>
>> This is what I've been most bothered about in Xc4. I've written several bugs about it. I think of it as a document-window binding. That is, a document should "belong" to a window (and vice-versa).
>>
>> Note that "document" is used loosely. Of course, source files are actual documents, but you can also think of an execution context as a document in this concept. For example, if I debug my app on one device, that should open a debug-specific window (or bring said window forward). That window should remember its shape and position. If I debug my app on the sim, a *different* debug-specific window should open (or come forward).
>>
>> My project is yet another document...>
> This has been mentioned several times - here and elsewhere. I called it the "spatial" model, in reference to the spatial Finder that Mac OS X has gotten away from, much to the disappointment of many, especially John Siracusa in his series of Mac OS reviews. I and others have beaten that horse so thoroughly the poor beast is completely dead. Despite un-humanly hurting that animal, Apple has never even once acknowledged the possibility that there might be something to it, stubbornly driving many of us mad until we broke the bank to buy a couple of screens the size of a football field. As we say in French, all that amounted to no more than "pisser dans un violon" (look it up if you like). At this point in time, I have personally lost any hope for Apple to show any care about this issue (as well as about a few others, first and foremost its bug filing tool). I have now come to live with the fact that every time Xcode replaces the content of a pane against my will, God kills a kitten (or two). Yes I know, many dead animals in this sorry story - though not enough bugs.
>
> Jean-Denis

This is what I have been alluding to as well. Whomever is responsible at Apple for this "whole screen everything" needs to be shot into the sun. It's so terrible that the OS we used to love has taken this direction.

> On Thu, Mar 1, 2012 at 6:04 AM, G S <stokestack...> wrote:
> >> Xcode has come a long way since Project Builder>
> Actually, I rather liked Project Builder--at least the one on
> NeXTStep. Did one thing, and did it well.

Ditto. And it is still the way I use Xcode: as a project manager. All coding happens in TextMate.

Xcode4 added many great features that I'd like to have, but along with it came a lot of "features" that really are deal breakers. Xcode4 does too many things, and few of them well.

>
> On Mar 2, 2012, at 8:13 AM, Jean-Denis MUYS wrote:
> >>
>> On 1 mars 2012, at 08:35, Rick Mann wrote:
>> >>>
>>> On Feb 29, 2012, at 19:50 , Brian Barnes wrote:
>>> >>>> If you have a tab open, and click the file in the navigator, it will open over that tab; if you double-click, it will open in another tab EVEN if the original already exists.
>>>>
>>>> The solution is to just do it the same way NetBeans, Eclipse, and Visual Studio do it. A double click to open a file. If the tab exist, bring that tab to the front. If it doesn't, create a new one. Or give us that option in preferences. The tabs containing the navigation pane (and changing it when they are changed, also in radar) and the weird way it creates tabs are so completely different from other environments that it's quite bizarre the behavior ever got in there :)>>>
>>> This is what I've been most bothered about in Xc4. I've written several bugs about it. I think of it as a document-window binding. That is, a document should "belong" to a window (and vice-versa).
>>>
>>> Note that "document" is used loosely. Of course, source files are actual documents, but you can also think of an execution context as a document in this concept. For example, if I debug my app on one device, that should open a debug-specific window (or bring said window forward). That window should remember its shape and position. If I debug my app on the sim, a *different* debug-specific window should open (or come forward).
>>>
>>> My project is yet another document...>>
>> This has been mentioned several times - here and elsewhere. I called it the "spatial" model, in reference to the spatial Finder that Mac OS X has gotten away from, much to the disappointment of many, especially John Siracusa in his series of Mac OS reviews. I and others have beaten that horse so thoroughly the poor beast is completely dead. Despite un-humanly hurting that animal, Apple has never even once acknowledged the possibility that there might be something to it, stubbornly driving many of us mad until we broke the bank to buy a couple of screens the size of a football field. As we say in French, all that amounted to no more than "pisser dans un violon" (look it up if you like). At this point in time, I have personally lost any hope for Apple to show any care about this issue (as well as about a few others, first and foremost its bug filing tool). I have now come to live with the fact that every time Xcode replaces the content of a pane against my will, God kills a kitten

(or two). Yes I know, many dead animals in this sorry story - though not enough bugs.

>>
>> Jean-Denis>
> This is what I have been alluding to as well. Whomever is responsible at Apple for this "whole screen everything" needs to be shot into the sun. It's so terrible that the OS we used to love has taken this direction.
>
> One rotten apple spoils the GUI direction for a whole platform.
>
> WHO LET THIS HAPPEN?
>
> How many years did they spend at Microsoft?
>
> Can we resurrect Steve?

If there is a focus, it should be on fixing what we have now; again, I
use lots of development environments and while I preferred the
multi-window approach, fixing the single window approach as it stands
would go a long way to making this better.

For instance, a lot of people who don't like the single window approach
are actually basing this view on a *broken* single window approach.
This isn't to start an argument on which is better, but you can't even
form an argument when one side is so broken.

Let's get the bug system to work for us. I've submitted an over-all bug
that combines all my other reports, a copy is below:

Summary:
Xcode's single-window tab pane behaves very bizarrely, and doesn't
reflect any other development environment out there. The main problems are:

1) single clicking a file in the navigator refreshes the current tab
2) double-clicking a file will create a new tab regardless if the file
already exists in a tab
3) The tab pane window contains the navigation tree, the console, and
the info pane

The solution would be:

1) single-clicks only select an item in the navigation tree
2) double-clicks only open a new tab if the file doesn't already exist
in a tab. If it does exist, bring the tab to front
3) The navigation/console/info panes should exist outside the tab pane
(and the tabs should only cover the area of the tab pane.)

Steps to Reproduce:

No steps, this is just how the UI works

Expected Results:

n/a

Actual Results:

n/a

Regression:

n/a

Notes:
This is a combination of a couple bugs that I have posted before, but
they all belong in the same area so hopefully this will make them easier
to track.

Anybody that thinks this is a problem, please submit this bug again.
Mention this bug's ID. This is what Apple tells us to do, and I have
faith they are listening :) Let's follow the rules and drop some bug
reports!

I vehemently disagree. It's never too late to turn back from a wrong path, and Xcode 4's path is so very, very wrong.
Go back to Xcode 3.2.6 as a baseline, keep the underlying workflow, expand from that foundation, and the universe will be saved (not to mention many hapless kittens).

These things take up screen width. Depending on your style, a lot of screen width. And you're working with a 13" MacBook Air. I've actually done this, with a modicum of comfort.

What you don't need:

* Any navigator. It takes up width (depending on your purpose, such as examining error messages or search results, quite a lot of width). You can get by with the jump bar, particularly if you keep your XIBs in a single group. (Yes, I wish Xcode's jump bars would not irretrievably drop context.)

Now suppose you also debug code. For debugging, you need:

* A navigator, for stack traces, or to refer to other files.
* The Debug area, which doesn't figure into this discussion because it doesn't take up width.

You do not need:

* The Inspector area.
* An assistant editor.

Your proposal is that whenever you use a tab to switch tasks, you should have to manually reconfigure the navigator, the inspector, the debugger, and the assistant. Every time you switch files.

Forgive me, but I think that's crazy.

_Xcode isn't TextMate. Not being TextMate is not a bug._ The two applications serve different functions. Just because they both have features named "tabs," that does not oblige Apple to have Xcode's feature do no more than TextMate's. Plain-text editors switch among files. Xcode switches among tasks. Those are different functions, and it's confusing only if you expect an IDE to have no more responsibilities than a text editor.

> Go back to Xcode 3.2.6 as a baseline, keep the underlying workflow, expand from that foundation, and the universe will be saved (not to mention many hapless kittens).

I should get back to work, but…

People are forgetting how objectively bad Xcode 3.2 had become. I wrote nearly 400 pages of a book about it. It was not pretty. Neither was the announcement of Xcode 4, so it isn't as though I didn't have my own investment in the old way.

Returning to Xcode 3.2 as a baseline would still require rewriting it nearly from scratch, and it would still suck for a year until the developers got it back under control.

This isn't unusual for Apple, nor outside its culture. They make radical changes to their products all the time. Zombie Steve will not rescue you.

As for the book, if I haven't alienated you, Xcode 4 Unleashed will hit the shelves in April, or shortly thereafter.

> And here's an example of how different people have different priorities.
>
> On 2 Mar 2012, at 9:38 AM, Brian Barnes wrote:
> >> 3) The tab pane window contains the navigation tree, the console, and the info pane> >> 3) The navigation/console/info panes should exist outside the tab pane (and the tabs should only cover the area of the tab pane.)>
> I'll restrain myself from the general tone of hysteria, but I believe this isn't how it should work at all.
>
> Suppose your screen isn't infinitely wide. Suppose you want to wire up a XIB. You'll need:
>
> * The XIB outline fully extended.
> * An editor containing the XIB.
> * An assistant editor containing the counterpart header.
> * The Inspector area.
>
> These things take up screen width. Depending on your style, a lot of screen width. And you're working with a 13" MacBook Air. I've actually done this, with a modicum of comfort.
>
> What you don't need:
>
> * Any navigator. It takes up width (depending on your purpose, such as examining error messages or search results, quite a lot of width). You can get by with the jump bar, particularly if you keep your XIBs in a single group. (Yes, I wish Xcode's jump bars would not irretrievably drop context.)
>
> Now suppose you also debug code. For debugging, you need:
>
> * A navigator, for stack traces, or to refer to other files.
> * The Debug area, which doesn't figure into this discussion because it doesn't take up width.
>
> You do not need:
>
> * The Inspector area.
> * An assistant editor.
>
>
> Your proposal is that whenever you use a tab to switch tasks, you should have to manually reconfigure the navigator, the inspector, the debugger, and the assistant. Every time you switch files.
>
> Forgive me, but I think that's crazy.
>
> _Xcode isn't TextMate. Not being TextMate is not a bug._ The two applications serve different functions. Just because they both have features named "tabs," that does not oblige Apple to have Xcode's feature do no more than TextMate's. Plain-text editors switch among files. Xcode switches among tasks. Those are different functions, and it's confusing only if you expect an IDE to have no more responsibilities than a text editor.
>
> — F
>

This falls under the 90/10 rule. 90% of my time I'm navigating files.
10% of my time I'm debugging (actually, I hardly ever use the debugger,
but that's just me.) Being annoyed by a bad interface 90% of the time
beats 10% of the time.

Also, there are a couple good solutions:

1) Give us some auto-hide options. Go to a debug code, auto hide the
navigation.

2) Make the navigation pane consistent for type. If you are in a file,
you see the same navigation pane. If you go into a debugger, you see a
different one.

Let me give you an example I encounter all the time where the switching
navigation pane is a hassle. Do a find in files, which I do all the
time. Every time I double-click to get a new tab (I want them all
open), the navigator gets replaced and the find in files disappears! I
have to switch back to the older tab to get the find in files back!
There's no way that's a good idea, even if it's frustrating to see the
navigation pane while debugging.

Again: There is NO OTHER development environment that works this way.
Not Netbeans, not eclipse, not MSVC. That should tell you something :)

> 1) Give us some auto-hide options. Go to a debug code, auto hide the navigation.
>
> 2) Make the navigation pane consistent for type. If you are in a file, you see the same navigation pane. If you go into a debugger, you see a different one.

Funny you should ask. Bone up on behaviors. They allow for rearranging the display automatically in response to development-cycle events or key commands. At least for that, it isn't all Xcode's way or the highway.

> Again: There is NO OTHER development environment that works this way. Not Netbeans, not eclipse, not MSVC. That should tell you something :)

It doesn't tell me much, and it would actively antagonize anybody in Apple's culture. "'Better' necessarily means 'different.'" Xcode 4 goes a long way in the direction of Visual Studio, but Apple isn't obliged to (it prefers not to) do only what other companies imagine.

Apple is unsentimentally radical about design. That's ultimately why the people on this list think they can make good money developing for Apple products. But even as end-users get bitten by the death of magnetic media, we get bitten by a radical rewrite of the developer tools. Maybe we deserve different treatment, but I'm not sure Apple engineers and managers can bring themselves to think that way. And maybe it's better that there is _no_ foothold for conservative design anywhere in the company.

It's like pitching your tent under an elephant: It's not that the elephant hates you, but you can't afford to get comfortable.

> On 2 Mar 2012, at 11:40 AM, Brian Barnes wrote:
> >> 1) Give us some auto-hide options. Go to a debug code, auto hide the navigation.
>>
>> 2) Make the navigation pane consistent for type. If you are in a file, you see the same navigation pane. If you go into a debugger, you see a different one.>
> Funny you should ask. Bone up on behaviors. They allow for rearranging the display automatically in response to development-cycle events or key commands. At least for that, it isn't all Xcode's way or the highway.

I know this. This actually solves your problem, not mine.

Mine is that the navigator and other panes INFORMATION randomly changes.
Yours is the POSITION and SHOW/HIDE state of the navigator (and other
panes.)

They are two completely separate problems with separate solutions.

>> Again: There is NO OTHER development environment that works this way. Not Netbeans, not eclipse, not MSVC. That should tell you something :)>
> It doesn't tell me much, and it would actively antagonize anybody in Apple's culture. "'Better' necessarily means 'different.'" Xcode 4 goes a long way in the direction of Visual Studio, but Apple isn't obliged to (it prefers not to) do only what other companies imagine.
>
> Apple is unsentimentally radical about design. That's ultimately why the people on this list think they can make good money developing for Apple products. But even as end-users get bitten by the death of magnetic media, we get bitten by a radical rewrite of the developer tools. Maybe we deserve different treatment, but I'm not sure Apple engineers and managers can bring themselves to think that way. And maybe it's better that there is _no_ foothold for conservative design anywhere in the company.
>
> It's like pitching your tent under an elephant: It's not that the elephant hates you, but you can't afford to get comfortable.

I have no problems with trying to radical and new, and, in fact, I
welcome it.

What we should have a problem with is not listening to the users who
tell you that's it's not working out.

This is in real danger of going way OT and chewing up unnecessary time.

> This has been mentioned several times - here and elsewhere. I called it the "spatial" model, in reference to the spatial Finder that Mac OS X has gotten away from, much to the disappointment of many, especially John Siracusa in his series of Mac OS reviews. I and others have beaten that horse so thoroughly the poor beast is completely dead. Despite un-humanly hurting that animal, Apple has never even once acknowledged the possibility that there might be something to it, stubbornly driving many of us mad until we broke the bank to buy a couple of screens the size of a football field. As we say in French, all that amounted to no more than "pisser dans un violon" (look it up if you like). At this point in time, I have personally lost any hope for Apple to show any care about this issue (as well as about a few others, first and foremost its bug filing tool). I have now come to live with the fact that every time Xcode replaces the content of a pane against my will, God kills a kitten (or two). Yes I know, many dead animals in this sorry story - though not enough bugs.

I had to use both 3.2 and 4.x in my last operation and 4 was/is definitely more of a nightmare IMHO.

One of the major PITA factors that crosses both is the cert/license/provisioning/distribution issue(s). That needs to be MAJORLY streamlined.

Why do we select "archive" when we want to build an app for deployment/distribution?

On Mar 2, 2012, at 12:24 PM, Fritz Anderson wrote:

> On 2 Mar 2012, at 10:33 AM, Nathan Sims wrote:
> >> Go back to Xcode 3.2.6 as a baseline, keep the underlying workflow, expand from that foundation, and the universe will be saved (not to mention many hapless kittens).>
> I should get back to work, but…
>
> People are forgetting how objectively bad Xcode 3.2 had become. I wrote nearly 400 pages of a book about it. It was not pretty. Neither was the announcement of Xcode 4, so it isn't as though I didn't have my own investment in the old way.
>
> Returning to Xcode 3.2 as a baseline would still require rewriting it nearly from scratch, and it would still suck for a year until the developers got it back under control.
>
> This isn't unusual for Apple, nor outside its culture. They make radical changes to their products all the time. Zombie Steve will not rescue you.
>
>
> As for the book, if I haven't alienated you, Xcode 4 Unleashed will hit the shelves in April, or shortly thereafter.
>
> — F
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/<zav...>
>
> This email sent to <zav...>

> On 2 Mar 2012, at 11:40 AM, Brian Barnes wrote:
> >> 1) Give us some auto-hide options. Go to a debug code, auto hide the> navigation.>>
>> 2) Make the navigation pane consistent for type. If you are in a file,> you see the same navigation pane. If you go into a debugger, you see a
> different one.
>
> Funny you should ask. Bone up on behaviors. They allow for rearranging the
> display automatically in response to development-cycle events or key
> commands. At least for that, it isn't all Xcode's way or the highway.
> >> Again: There is NO OTHER development environment that works this way.> Not Netbeans, not eclipse, not MSVC. That should tell you something :)
>
> It doesn't tell me much, and it would actively antagonize anybody in
> Apple's culture. "'Better' necessarily means 'different.'" Xcode 4 goes a
> long way in the direction of Visual Studio, but Apple isn't obliged to (it
> prefers not to) do only what other companies imagine.
>
> Apple is unsentimentally radical about design. That's ultimately why the
> people on this list think they can make good money developing for Apple
> products. But even as end-users get bitten by the death of magnetic media,
> we get bitten by a radical rewrite of the developer tools. Maybe we deserve
> different treatment, but I'm not sure Apple engineers and managers can
> bring themselves to think that way. And maybe it's better that there is
> _no_ foothold for conservative design anywhere in the company.
>
> It's like pitching your tent under an elephant: It's not that the elephant
> hates you, but you can't afford to get comfortable.
>
> — F
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (<Xcode-users...>)
> Help/Unsubscribe/Update your Subscription:
>
> https://lists.apple.com/mailman/options/xcode-users/<treaves...>
ech.com
>
> This email sent to <treaves...>
>

Yep, it is. I had an early EAP (JetBrains-speak for beta), and dumped it after a very quick look in part because of that, and because it's a real memory hog. But Xcode irritated me into giving it another go, and I learned to live with (if not like) AppCode's appearance, and discovered that the memory use is high but at least stable (unlike Xcode, which sat running on my machine the other day with nothing open but its egregious docs browser, using 1GB of real mem).

Xcode is pretty in a screenshot, but ugly to interact with in so many ways, that it's just not worth wasting my time on now that I have only minimal need of it.

>> Go back to Xcode 3.2.6 as a baseline, keep the underlying workflow, expand from that foundation, and the universe will be saved (not to mention many hapless kittens).

> I should get back to work, but…

> People are forgetting how objectively bad Xcode 3.2 had become. I wrote nearly 400 pages of a book about it. It was not pretty. Neither was the announcement of Xcode 4, so it isn't as though I didn't have my own investment in the old way.

I'm not forgetting anything - I run XCode 3.2.2 and 4.2.1 at the same time. XCode3 can index the thousands of files in my project; 4 not only can't, but because it can't it doesn't recognize AppKit classes either. But 4 is the only one that can debug or edit nibs (except for the content of NSTextViews - that needs Interface Builder and Snow Leopard).

>> Go back to Xcode 3.2.6 as a baseline, keep the underlying workflow, expand from that foundation, and the universe will be saved (not to mention many hapless kittens).

> I should get back to work, but…

> People are forgetting how objectively bad Xcode 3.2 had become. I wrote nearly 400 pages of a book about it. It was not pretty. Neither was the announcement of Xcode 4, so it isn't as though I didn't have my own investment in the old way.

I'm not forgetting anything - I run XCode 3.2 and 4.2 at the same time. XCode3 can index the thousands of files in my project; 4 not only can't, but because it can't it doesn't recognize AppKit classes either. But 4 is the only one that can debug or edit nibs (except for the content of text views - that needs Interface Builder and Snow Leopard), so I'm stuck.

> XCode3 can index the thousands of files in my project; 4 not only can't, but because it can't it doesn't recognize AppKit classes either.

You should hunt down that bug and file a bug report. You may have a malformed .h file in your project directory (it doesn't need to be referenced in your project, just a stray .h file in the directory along with your projects. etc. ... or a C++ syntax error that Xcode 4 can't parse (it happens...).

For us, Xcode 4 indexes about million lines of code over 1000 files or so. So, it is doable (in our case).

> But 4 is the only one that can debug or edit nibs (except for the content of NSTextViews - that needs Interface Builder and Snow Leopard).

You should file a bug report ...

but editing static text in NSTextViews isn't that useful (IMHO). We removed all that stuff from our nibs a long time ago because it just didn't seem right.

... being in tech support myself, a "review" on a forum or list is no where near as useful as a bug report.

> If you’ve been around long enough to remember MPW, you’ve certainly had to deal with many buggy releases from many different vendors. I’ve certainly heard a lot of cursing from co-workers about Visual Studio over the hears.

Hey, I'm so old I remember Symantec tech support systematically lying about bugs in their C++ code generation because management ordered them to go along with the marketing claim that all known bugs had been fixed. So at least Apple is better than that!

> This falls under the 90/10 rule. 90% of my time I'm navigating files. 10% of my time I'm debugging (actually, I hardly ever use the debugger, but that's just me.) Being annoyed by a bad interface 90% of the time beats 10% of the time.

You're lucky. 50% of my time, I code, 10% I debug, and 40%, I resize and reorganize the Xcode panes and windows to make them fit my needs ;-)

> On 2 Mar 2012, at 11:40 AM, Brian Barnes wrote:
> >> 1) Give us some auto-hide options. Go to a debug code, auto hide the navigation.
>>
>> 2) Make the navigation pane consistent for type. If you are in a file, you see the same navigation pane. If you go into a debugger, you see a different one.>
> Funny you should ask. Bone up on behaviors. They allow for rearranging the display automatically in response to development-cycle events or key commands. At least for that, it isn't all Xcode's way or the highway.
>

Thank you for this insightful comment. You made my day. I didn't notice before that you can create custom behaviors with user defined shortcuts :-). It's going to save me a lot of headaches.

Now, I have a simple way to open full-screen "Console Tab" when I want one.