Re: [Xcode 4] Number of recommended displays/spaces?
Re: [Xcode 4] Number of recommended displays/spaces?
- Subject: Re: [Xcode 4] Number of recommended displays/spaces?
- From: Jean-Denis Muys <email@hidden>
- Date: Thu, 17 Mar 2011 10:03:24 +0000
- Thread-topic: [Xcode 4] Number of recommended displays/spaces?
On 17 mars 2011, at 06:42, David Dunham wrote:
> On 14 Mar 2011, at 10:39, Stephane Sudre wrote:
>
>> Maybe I just need more practice using it but I would be interested in
>> knowing how people organizes their environment to work with Xcode 4 to
>> see if I can improve things on my side. (I certainly need more
>> practice as I usually end up quitting Xcode 4 when I've finished
>> modifying a xib as I think I'm in Interface Builder).
>
> I foolishly keep trying to use Xcode 4 as a multi-window IDE. This is why I hate it so much. Practice makes it a little better (and Xcode has gotten a little better since early previews), but Xcode invariably changes what a window displays, rather than opening a new one when it would make sense to show a symbol or breakpoint in a way that didn't mess things up.
>
> More to your point, I keep the Organizer on a second display, so I can easily see documentation.
I too have very bad feelings about the new one-window-fits-all UI paradigm. I feel like I'm back to the times when Windows was tiling, not overlapping (Windows 2.x IIRC). The problem is mitigated partially by the possibility to double-click a source file to open it in its own window.
But a large part remains whereby window content is not stable: Xcode will change its content without warning. I try to keep various relevant point of views on my project in different tabs. Typically, I have several for source code editing, split with the assistant editor, another for Interface Builder, with the single editor AND the right toolbar open, another for Core Data models, another for debugging. They are all laid out differently, expectedly.
It all breaks down because I tend to click the run button right after editing my source. Or to click on one source file in the project file list. Of course I forget to change tabs beforehand. Very soon my carefully set up set of tabs become a total mess: several tabs with the same file in the wrong set ups. Of course, it's because of *my* failure to switch context the correct way. But the least that can be said is that Xcode will *not* help you there.
It can be compared with the whole spacial Finder debate: when you double click on a folder in the Finder, do you expect the Finder to open a new window with the folder content, or to bring the existing window with the folder content to the front? I expect the latter. The same pertains to Xcode. If I click on myWindow.xib in the file list, and myWindow.xib is already open in some window or tab, I would like Xcode to assume I want to switch context to myWindow.xib *in the editor* I have already set up for it. The fact that it doesn't is a nightmare.
Also, this one-window arrangement is a nightmare in Interface Builder, *especially* for iPad development where the iPad window is large. On most screen it's *impossible* to see the whole iPad Window without sacrificing some part of the user interface. So you spend your time hiding the file list, or the assistant editor, or the object list. Not to mention pulling up/down the limit between the inspector and the object pane. Why ? Because they are not floating palettes anymore.
The net result? I now had to add a secondary 24", 1920x1200 screen to my 30", 2560x1600 primary screen, Without which the frustration is too unbearable.
Forget development on my 17" MacBook Pro. It's become too small except for limited tasks.
Yet I have switched to Xcode 4 full time. It makes no sense to stay with Xcode 3: Xcode 3 doesn't work with Lion anyway. Very soon, those on Xcode 3 will be left behind for good. I reckon the best course of action is to swallow the cod liver oil as fast as possible, despite its bitter taste.
At least, Xcode has plenty of very nice improvements elsewhere. Too bad for the regression to the early 1990's.
Jean-Denis
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden