Re: XCode usable?
Re: XCode usable?
- Subject: Re: XCode usable?
- From: Scott Tooker <email@hidden>
- Date: Tue, 4 Nov 2003 10:22:22 -0800
On Nov 4, 2003, at 4:19 AM, Dix Lorenz wrote:
> Hi,
>
> so far I don't see the big improvement over PB. I've been using
> (trying to use) it for a week now, hoping it would grow on me, but
> it's getting worse every day.
>
> The 2 biggies in XCode I was looking for was distributed compiling and
> Code Sense.
>
> Distributed compiling sometimes works, then it's awesome. Mostly it
> doesn't and I have no clue why. It seems to hate being stopped and
> machines that go to sleep, regardless if they are used for compiling
> at that moment or not. Right now, if I use DC, it spawns 6 compiles
> (correct: 3 machines with dual procs available), but the other
> machines are idle and my machine is compiling only 1 file. I have no
> idea how to fix that other than restarting machines and don't even
> know if I should restart my machine or the others. So I've switched it
> off until the next release.
Two things to check. First make sure you are using native targets.
Second, I believe the same version of gcc needs to be used on all the
machines.
>
> CodeSense is better, but from time to time it inserts invisible text
> in my code, making compiles fail.
Known bug that is fixed for the next version.
>
> As for the rest of the changes from PB... A few things I positively
> hate, some I am not so sure about.
>
> I definitely hate that all the compiler flags etc. have gone into an
> inspector/Info Panel.
>
> For example I can't have the settings for my build styles next to each
> other to see if I forgot a flag somewhere. It's a lot of switching
> back and forth.
You could do this by bringing up two 'Get Info' windows, one on the
target and one on the project
>
> Search Paths used to be a nice table, where you could actually see
> more than just a few characters of the first path, now it's a one-line
> textfield. I hated it in MSVC and used to point to Mac: Neither CW nor
> PB would ever dare use such an unusable UI. Of course it's a lot
> easier to program, but if you already had the code, why trash it?
We realize we need a much better UI for dealing with lists of strings
and text field where you enter paths. This is something we want to fix
in a future release.
>
> It used to be very easy to add a flag in a build-style, just click on
> the "=" and it turns to "+=". Maybe not obvious, but once you knew
> about it, very easy, efficient and crystal-clear. Now it needs text
> that says I have to use "$(value)". I don't see the progress. Plus, I
> assume it is supposed to be (for example) "$(OTHER_CFLAGS)" and it not
> really obvious, what I should put there for "Other linker flags". Just
> an example, I don't need it right now.
Actually it really is supposed to be just '$(value)'. It represents the
value of the build setting on the "previous level" (i.e. for a build
style, $(value) will point to the build settings value in the target.
We went to this model since we have gotten requests to be able to
prepend or both prepend and append (which the += just couldn't do).
>
> At some places I am just stumped, where a setting comes from. Maybe
> that's because I am not yet used to it, maybe because it is still in
> flux, but I found it very nice in PB to just go to Expert View and see
> and edit all the settings in a pretty raw format. Especially when it
> does some things behind my back which I don't want but can't find a
> way to reverse. I have one target called "libdlclmmcl", which should
> build a lib called "libdlclmmcl.a". I haven't changed anything yet,
> but the lib is called "liblibdlclmmcl.a" and I can't find why it would
> do that. I certainly didn't tell it to and there is no setting I can
> see.
In this particular case there is a bug (fixed) that we were not showing
an entry for PRODUCT_NAME. In general, for the next release we have
tried to make it easier to find settings (in the next version you can
search on the build setting name or gcc flag). The one thing we would
like to see for a future release is an "All Settings" collection, so
that you don't have to muck around in the drawer so often.
>
> In PB it was reasonable to use the project-window for just the tree
> and not having an editor right next to it, basically working as you
> would in CW. In XCode it isn't: I know I can collapse the editor-part,
> but when I have compile-errors, I have to doubleclick the file in the
> projectwindow, scroll until I find a small red "x" and hover with the
> mouse over it to see the tooltip. Or use the buildwindow, but the
> editor there is gone, for no reason I can think of.
You might try cnrtl-cmd-opt-down arrow to go to the next "detail" (in
your case a warning or error) (previous detail uses up arrow with same
modifiers). I think this was working in Xcode 1.0 (if not, it should
work in the next version). We've also added markers in the scroller for
warnings and errors in the next version.
>
> I've also stumbled about most of the bugs others saw, had one project
> corrupted... It is the buggiest release of anything I've yet seen from
> Apple. Luckily the bugs usually don't destroy data, but working with
> XCode is more of a fight than it should be.
>
> So far I'll have to say I am pretty disappointed. Usability is way
> down from PB and I can't attribute that only to me being used to PB or
> CW. It tries to force me into a direction I don't like. The
> iTunes-metaphor is not good for everything and I'd say an IDE is one
> of the last places where it's the best solution.
The new UI really lives or dies on the use of the search field. If you
like the search field and use it, then I think the UI becomes very
powerful. However, if you don't use the search field then you may be
happier just collapsing the project window to just show the group view.
Scott
>
> I guess the bugs will sort themselves out and I will give Apple the
> benefit of the doubt: PB was not to be ported to Panther, so XCode had
> to be released with Panther and you can't delay Panther for developer
> tools that may not be perfect, but usable. So I assume Apple would
> have liked to refine XCode a bit more before releasing, but couldn't.
> But the UI (especially the settings for targets and build styles) will
> probably stay and I don't look forward to using that for the next few
> years. Maybe somebody could tell me why they changed a system that was
> IMHO pretty darn good; usable for novices and usable for experts...
>
> Thanks for reading my rant, I just had to get it off my chest.
>
> Dix
> _______________________________________________
> 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.