Re: Collections Suggestions
Re: Collections Suggestions
- Subject: Re: Collections Suggestions
- From: Brian Barnes <email@hidden>
- Date: Sat, 8 Nov 2003 22:57:02 -0500
On Nov 8, 2003, at 8:35 PM, Scott Tooker wrote:
On Nov 8, 2003, at 3:23 PM, Brian Barnes wrote:
The "collections", for instance in target/build, are really difficult
to use. For one thing, whatever logic is put into what item makes it
into the "current settings", for a new or imported target, is beyond
me. I would suspect it would be anything with a setting, but, for
instance, "generate debugging symbols" is NOT in the default list
when creating a new target, and is set to ON. It takes a bit of
hunting to find this.
Current settings contains any setting that was set by the user. The
"tricky" part is that even if the user sets the build setting to the
default value we show it there. If you haven't changed any of the
settings in a new target, then the collection would be empty.
I don't know if that's true; I created a blank project, then made a
"carbon library" target, and the current settings was full of options.
As noted, "Generate Debugging Symbols" was ON but not part of that
collection. Any way, something as "dangerous" to be on as debugging
symbols (as it bloats the app) should be there :) Minor complaint, I
guess.
Also, I'm making a lot of new targets, and I'm comparing known
working projects with the new ones to get the settings right (these
known ones were imported from PB). Well, it becomes a hunt and peck
game where I have to work through all the settings to find the one
(and get them to the "current" collection) that I need to create the
correct target. This is way to hard.
Which is why we added the ability to duplicate a target in the next
version.
Across projects? That was my problem, if I could do that it wouldn't
be such a big deal.
My suggestion would be to take all the settings groups and turn them
into separate lists divided by tabs. That way, comparing projects is
easy as the lists are divided and never change. Also, finding a
certain item would be easier as you can drill for it. Or, better
yet, just use a tree.
While a tree maybe possible, using tabs doesn't scale well (especially
if users could create their own settings). In the end, just like the
detail view, the Build tab is set up to use searching to get you
places quickly.
I'll go with tree then! I understand where you guys are going with
this, but sometimes searching isn't the answer, as when you are just
idly going through the list on a new project, setting what strikes you
fancy. I could use XCode for a hundred years and I would never know
the options well enough to remember their names well enough to actually
search for them.
It's the same with the "itunification" of xcode; I think code has a
natural hierarchy (if you maintain it, that is) that isn't well suited
for searching or smart groups. IMHO!
[>] Brian
_______________________________________________
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.