Re: XCode usable?
Re: XCode usable?
- Subject: Re: XCode usable?
- From: Scott Tooker <email@hidden>
- Date: Wed, 5 Nov 2003 19:20:25 -0800
On Nov 5, 2003, at 5:30 PM, Josh Anon wrote:
> I can't speak for others, but here are some of my specific issues:
> When I open a project, I care about my files and an editor. Rarely do
> I open a project and immediately want to go to search results or a
> smart group--I want to scroll to a file (or see the last file I was
> editing), and a full editor window. PB did this, and Xcode doesn't.
One feature we don't have that I think we need is a quick way to hide
the detail view (like you can hide the editor) and have it remembered.
I think there is a Radar for this somewhere.
>
> When I do a build, I want to immediately see detailed build info, and
> I want context. It's annoying to have to hit command-shift-b or hunt
> for a window to see detailed info (radar 3462826). If I'm trying to
> do > 1 build, I can't tell which build window refers to what build for
> similar projects.
One though in a future release is to allow the errors & warnings smart
group to show a table view or an outline view (like the one in the
Build Results window). We'd might use a segmented control (think Finder
views) to allow you to switch the state.
>
> When I'm debugging, I want my file browser right there so that if I
> want to add a specific breakpoint, I can easily go to a different file
> and add it. I can sometimes use the popup menu from the editor, but
> if I haven't opened the file yet, it might not appear (radar 3462823).
>
> Generally, if I'm editing a target, I am not editing code at the same
> time--I want my target inspector to be big, and again associated with
> my project so that it's easy to drag things from my file browser to
> various build phases (e.g. if I have a copy phase for my html-based
> manual, and I want to add a new html file). Single window mode made
> this easy. The target editor in an inspector makes this annoying.
> The lack of an "edit active target" button is also a pain (3467718),
> although not specifically related.
The "edit active target" is something we want to bring back in a future
release (the current thinking is that this would bring up a 'Get Info'
window on the current target).
In 1.0 you should be able to set what is in a build phase just by
dragging it underneath the target in the groups view (there may be
problems/issues, I know we fixed a fair number of bugs for the next
release in this area).
>
> There are other various annoyances that make the pseudo single window
> mode that I can get hard to use, for instance (3467709) if I want to
> see the .m file in my main editor window, and open a different editor
> window with a different .h, double-clicking in the file view also
> causes selection in the main editor window, so I end up with 2 windows
> pointing at the .h file.
Known bug that is fixed in the next release.
>
> Another nice thing that was perhaps a side effect of single window
> mode was that the editor splitter worked really well, and it was easy
> to see 3 editors in 1 window. It seems to be broken in Xcode. A
> quick example is click the split button, and watch it disappear from
> the 2nd editor, making it seem you can only have 1 split. Then (in
> the 2nd editor), hit command-". The editor's split resizing controls
> and split collapse completely falls apart. Plus, the split editor
> seems to be part of the text editor and not the general editor, as I
> can't split an image view (which PB could do). There are other things
> like this, all filed (3474846, 3467762, 3462840, 3467759) that just
> make it tough to even fake a single window mode.
Right now we only allow one split per editor. Hopefully we can remove
this limitation in a future version. I'm aware of the image editor not
providing a split view since I was looking at that issue recently.
Scott
>
> I guess the overall message is that I like having just 1 place to look
> for things, unless I specifically say otherwise (by opening a new
> window), and I like context for important steps, such as builds.
> Single window mode made that easy.
>
> Thanks,
> Josh
>
> On Nov 5, 2003, at 4:48 PM, Scott Tooker wrote:
>
>> The problem with some of the requests that I see for a "return to
>> single window" is that they focus on implementation ("bring back the
>> tabs!") instead of focusing on the underlying workflow issues (too
>> many windows popup, limited screen real estate, having to shuffle
>> across many windows to get status).
>>
>> I think it's fair to say that there are no current plans to bring
>> back the slideout tabs. That said, we are definitely interested in
>> tackling the underlying workflow issues and work well for both single
>> and multi-window users (which actually contains several different
>> sub-configurations).
>>
>> To give these sort of requests more weight and detail, step back and
>> think a little bit about how the workflow is being mangled or how it
>> could be better.
>>
>> Note: this advice really isn't specific to single window requests.
>> It's actually a good idea when filing any substantial enhancement
>> request. It just happens that I see this a lot with requests to
>> "bring back the tabs".
>>
>> Scott
>>
>
> ---
> Josh Anon
> Studio Tools, Pixar Animation Studios
> email@hidden
> _______________________________________________
> xcode-users mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/xcode-users
> Do not post admin requests to the list. They will be ignored.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.