Re: Collections Suggestions
Re: Collections Suggestions
- Subject: Re: Collections Suggestions
- From: Scott Tooker <email@hidden>
- Date: Sat, 8 Nov 2003 17:35:26 -0800
On Nov 8, 2003, at 3:23 PM, Brian Barnes wrote:
> I suspect the collections interfaces is something loved by the xcode
> developers, so this might be screaming at a brick wall ... but I offer
> my humble opinions and suggestions anyway.
I don't think anyone is especially happy with having to have the
collections drawer open most of the time. We have been discussing ways
to make it unecessary to have it open most of the time. We've also
discussed the ability for users to define their own custom collection
sets.
>
> 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.
>
> 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.
>
> It also makes it that anytime I need to set something specific, it's
> another hunt mission till I find it. Adding a "All" group isn't going
> to do anything but make it even harder to find.
Actually we would like to add an "All Settings" group so that you can
see all the possible settings without having to jump between
collections. In addition, for the next version we have been making the
help text more informative (like adding the actual associated build
setting name or gcc flag so you can search on them). Searching on the
actual setting values may also be added (there are issues about what to
do with boolean settings).
>
> Also, the lists don't sort! This also makes it a bit difficult to use.
A known request that is being looked at for a future version.
>
> 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.
Scott
>
> I hate to complain this much, but as neat as the collection interface
> looks and sounds on paper, when you get to using it (as I noted above)
> it becomes tedious. Also, make the text entry lines wrap!
>
> [>] 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.
[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.