Xcode usability (was Re: Where did the GDB drawer go?)
Xcode usability (was Re: Where did the GDB drawer go?)
- Subject: Xcode usability (was Re: Where did the GDB drawer go?)
- From: Dietmar Planitzer <email@hidden>
- Date: Sat, 7 Aug 2004 12:03:16 +0200
On Aug 7, 2004, at 4:18 AM, Keith Ray wrote:
I'd rather have a resizable pane than a drawer.
Yeah, give me a pane or a drawer - I don't care. The important point
for me is that I don't want to have to spend extra time for finding an
optimal position for a standalone console window and on resizing and
activating (!) it. Probably the most annoying aspect about the
standalone console window is that you now have to explicitly click into
it in order to activate it everytime you want to type some command in
gdb. Its an either or thing. Either the gdb window has the user focus
or the console, but its not possible to have both active at the same
time as it is in a single window model.
The real problem for me is that Xcode claims on one side that it would
support a single window mode, but on the other side it tries very hard
to force multiple windows down my throat. Now with 1.5 a single window
mode effectively no longer exists because of the way how the build and
find panels work.
Actually I think that the PB 2.0 UI got the single window mode exactly
right. Its single window mode really allowed you to do everything in
just one single window: editing code, fixing build problems, debugging,
doing project wide search & replace, project management, configuring
build and executable options - everything could be done in just one
single window.
The big advantage of PB 2.0 over Xcode was that it showed the
information you needed at exactly the time when you needed it and it
was very easy - just a single click - to get rid of the stuff you no
longer cared about. This was possible because of the sliding tab views.
I know that some people didn't like them because of the sliding
animation, but this problem could have been easily fixed by offering a
preferences setting to turn the animation on / off.
Just a single example to make the difference in efficiency of use
between PB 2.0 single window mode and Xcode obvious:
When I was ready to build a project in PB I hit cmd-B. The compiler
started its business and _only_ when it found some error or warning
would PB _automatically_ open the build tab. I could then click on an
error message and PB opened the offending file in the main editor just
below the build tab. I clicked into the editor and fixed the problem.
Now, when I either had fixed all problems or no longer cared about the
errors I could easily close the build tab with one single click.
The same in Xcode, especially version 1.5, requires more work and is
less intuitive.
I again hit cmd-B. When the compiler finds a problem, the only thing
that happens is that Xcode updates a status message in the upper right
corner and that it starts to display those red triangles and yellow
circles. Naturally, the error and warning markers only appear if the
file you've currently open in the editor contains an error or warning.
If it doesn't, then you're left guessing where the problem might be.
If I want to see all errors of all files in the project, then I have to
explicitly click on the status message in the upper right corner (which
doesn't look like a clickable entity). I now get a second window where
I try to click an error message. However, now with 1.5 nothing happens
and you are forced to drag the splitter in order to reveal yet another
code editor. Naturally, this likely implies that you also have to spend
time making the window larger and reposition it. It also looks like
that there is a physical law that states that the file history list of
the editor you're currently working with never contains the file you
want to edit (especially true for the embedded editor in the gdb
window).
Another thing that I've noticed about those error and warning markers
is that they can drastically slow down the code editor especially if
you have a large file with more than 50 errors or warnings (don't ask
:). Worse, you can't even get rid of them easily: If you close the
file, because i.e. you hit cmd-B accidently and you didn't actually
want to compile your project, then they'll reappear as soon as you
reopen the file, naively thinking that closing and re-opening the file
would be enough to get rid of them. You really have to take the drastic
measure of closing and reopening the whole project - in PB 2.0 it was
as easy as clicking on the tab of the build tab view. Not to mention
that the existence of error messages in PB 2.0 didn't have any impact
on the performance of your code editor, even if you had hundreds of
them.
Yet another disadvantage of those error / warning makers is that you
must click on each one explicitly in order to find out what the problem
is and you have to know where to look for that message, 'cause it
doesn't appear where you clicked. Further, if an error marker appears
on a line with a break point, then its easy to overlook the error
marker altogether because its nearly completely covered up by the break
point icon.
I know that not everyone likes single window mode. As far as I can tell
from my own experience and talking with other developers there are two
big user groups: one which wants to have everything in one window and
who makes this single window as large as possible, and one which wants
to have everything in its own window. Now, in PB 2.0 one was able to
configure the GUI either way and the app really respected your wish.
Xcode 1.5 on the other side neither offers a real single window nor a
real multi window mode - its somewhere between. But thats exactly what
makes it so annoying. Further, it looks like that more and more UI
changes are made just for the sake of change without really thinking
through the resulting effect for the user and the usability of the
software in general.
I.e. logs are no longer automatically cleared when you start a
debugging session or your executable. I can see when it can make sense
to have such behavior - but it should be user configurable and the
clear log menu item ought to really have a keyboard equivalent.
Or, someone has removed my beloved "Add Framework..." menu item from
the project menu which means that I have to spend extra time for
navigating the file system. For example, consider the situation where I
want to add a system framework, and 5 seconds latter a source file from
my home directory. In earlier days I could use "Add Framework..." and
"Add File...", the former remembered the path
/System/Library/Frameworks; the latter the path to my sources.
Finally, the menu bar comes with more and more menus which has the
negative side-effect that Xcode pushes more and more menu extras from
the menu bar on my iBook. Its especially annoying that it throws out
the battery status indicator so that I'm now forced to either find a
new place for it, or that I have to switch to the Finder everytime i
want to read the current battery status.
In closing, I want to say that I really applaud the effort that the
Xcode team has put into implementing the native build system, the
debugger, indexing, etc. But when it comes to the GUI, then I honestly
think that it was a fundamental mistake to throw out the PB 2.0 UI and
start from scratch.
I think it would have been better to improve on the PB 2.0.
Regards,
Dietmar Planitzer
_______________________________________________
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.