Re: Xcode usability (was Re: Where did the GDB drawer go?)
Re: Xcode usability (was Re: Where did the GDB drawer go?)
- Subject: Re: Xcode usability (was Re: Where did the GDB drawer go?)
- From: Dietmar Planitzer <email@hidden>
- Date: Sun, 8 Aug 2004 11:42:56 +0200
On Aug 7, 2004, at 6:04 PM, Thomas Lachand-Robert wrote:
Le 7 ao{t 04, ` 12:03, Dietmar Planitzer a icrit :
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.
I generally agree with your message, but not on this point, since it
IS user configurable: see Preferences -> Debugger -> Auto-clear...
(BTW there is a typo here).
Thanks for the hint. Sadly, this setting doesn't exist in the 1.5 beta
version. Now I wonder whether it only applies to the gdb console, given
the fact that its located in the debugging section, or to all logs...
Also you can get the behavior of PB with respect to errors by setting
your preferences as follows (on Building):
Build Panel : open / never, close /never
Errors & Warnings smartgroup : open on errors or warnings.
No. The way that the error & warning smart group business works is
quite different from how the PB 2.0 build tab worked and most
importantly, the Xcode solution is significantly more inefficient to
use.
I've just taken one of my projects and removed a semicolon from a
header file. Then I've enabled the errors & warnings smart group so
that it would automatically open on either errors or warnings. Finally,
I hit cmd-B and got the following user experience:
1) The compiler generated 3819 warnings and 34 errors. This relatively
high numbers caused the Xcode UI to freeze for at least 5 seconds on my
dual G4. This is exactly 4.99 seconds longer than I'm willing to
tolerate, 'cause in my view there isn't any reason why collecting
around 4000 warnings and errors should take any longer than 10 ms on a
modern computer.
2) The errors & warnings group does not list the error messages itself
- rather it only lists the files which contain errors. Thus, I'm forced
to manually click on each file to find out what the problem is. This
behavior is also completely unexpected for a group that calls itself
"Errors and Warnings", where _naturally_ you would expect that it
honors its name and shows the actual errors and warnings.
3) After I've clicked on a file I get an additional pane above my
editor which contains, finally, the stuff that actually interests me.
Namely the error messages. Now I have to click yet again to move to the
actual place where the error is in order to fix it.
4) As far as I can tell, there is no way to show the build log in the
errors & warnings pane as it was the case with PB 2.0's build tab.
Thus, if a certain error requires me to check out the build log I'm
forced to bring up the build window which requires extra work.
5) The error pane has a highly annoying feature: it displays tooltips
for the error messages. The really annoying part about this is that the
tooltip just repeats the same text as the error message !?
6) Because of all the error & warning icons displayed to the left of my
editor, the code editor slows down so that inserting a CR takes
noticeably more time than normally. Also, its distracting. Call me
old-fashioned but all that yellow and red stuff in the gutter is
constantly attracting my eyes - moving them away from the actual code.
Well, come to think of it, the problem isn't me the real problem is
that you're trained from real world (consider driving a car) to always
watch out for attention signs...
7) Once I've fixed all my errors I must close the errors & warnings
pane by clicking into the Editor icon in the toolbar. Well, actually
you have to drag the splitter in order to close it if either you don't
have the Editor icon in your toolbar or if you've closed the toolbar
altogether.
Well, actually after wasting many minutes I found the `Toggle Embedded
Editor' menu item in the View menu which can close the errors &
warnings pane.
8) Yet another click is necessary to close the errors & warnings smart
group.
So if we compare the number of clicks which where necessary in PB 2.0
in order to fix a problem with the number of clicks / drags necessary
in XCode, then we notice that the PB 2.0 solution was more efficient.
More efficient because:
a) PB 2.0 automatically showed you the actually relevant stuff without
requiring any extra clicks or scrolling: the errors & warnings.
b) Selecting a problem required a single click because PB did not waste
time & space for an irrelevant abstraction level: the file.
When I get errors or warnings I want to fix them now - in which files
those errors are, I couldn't care less.
Another problem with the Xcode errors & warning group is that it is
part of the Groups & Files pane so that you may be forced to spend time
on scrolling to it. Consider for example a project with many source
files visible in the Groups & Files pane. Its very likely in such a
case that the errors & warnings group, just like the target and
executable groups, get pushed out of the visible window area. In the
case of PB 2.0, the targets, bookmarks and executables where all just
one single click away - no matter how many files you had visible in the
Groups & Files tab.
No, honestly, if it would be a viable option then I would switch back
to the PB 2.1 UI in a single hard-beat. But sadly, its not a viable
option.
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.