Project Inspector bugs / enhancement requests (many)

Project Inspector bugs / enhancement requests (many)

Post by Kurt Bigle » Sat, 01 Nov 2003 14:52:08

rustrations with the Project Inspector are an ongoing theme for me.

First of all, I have never, in all these years, used the "Attributes" tab.
Yet the inspector always defaults to the attributes tab.

I *always* want the targets tab. One possibility if you *must* group these
tabs into a single inspector is to provide 2 separate buttons (in the
project window toolbar) for opening the inspector, each defaulting to a
different tab. (Apologies if this actually exists via customization that I
have not bothered to learn about.)

I would really rather see separate Attributes and Targets inspectors.

I have a fundamental complaint about the appearance of the Project
Inspector. This observation applies to the OS 9 hosted environment, which
is where I usually am using it, which perhaps means this is an obsolete
concern unless the same issue exists under OS X, which I can't remember.
The problem is really a problem I have with the dimming of non-frontmost
non-modal dialogs, but if the OS does it wrong the application needs to
override it somehow, or chose a different approach when it gets in the way.
The amount of dimming is so extreme that it makes it hard to read the
information in the dialog (no my display is not badly calibrated). The
inspector when it is actually used to *inspect* as opposed to modify is
*never* frontmost, and therefore the information you are trying to read is
always dimmed out! What a useless user-interface idea!

Dimming aside, when the inspector is used for modifying it would be much
more useful if the inspector could *float* so that it would not require
extra clicks when going between the inspector and the project window in
which different items are being selected for modification via the inspector.
Making it float would also eliminate the dimming issue, if indeed it is
still an issue under OS X. But chances are the dimming was lost by the
wayside when Apple decided they must make the Mac look more like Windows,
with consequent loss of all time-honored Mac user-interface sensibilities
(including the few bad ideas that made it into OS 9). (End of backhanded
flame against Apple.)

Also I have plenty of problems with how the Targets tab works, and the
related (but separate) target selector which is brought up when new items
are added to a project. Regarding the Add Files target selector: it
defaults to all Targets checked. It would be great if these were Check All
and Uncheck All buttons present. Even better if there were check all x86,
check all ppc, etc, but I realize this may seem to get out of hand. The
ability to define target sets and utilize them here might alleviate this, or
maybe there are other obvious ideas floating around waiting to be realized.
Finally this selector could perhaps be eliminated in favor of simply
selecting all the new items and bringing up the Targets inspector. The
varioius check/uncheck buttons would be useful in the Targets inspector

A subtlety is that certain targets (such as whatever you call them -
compount targets or "group" targets - targets with the linker set to None
which just contain aliases to other targets) are allowed to be checked even
though the check does not "take" when Save is clicked. If the check-all
default is retained for the Add Files target selector, then these targets
should default to *unchecked* and dimmed. Likewise they should be unchecked
and dimmed in the Targets inspector.

A real pr

Project Inspector bugs / enhancement requests (many)

Post by David Phil » Sun, 02 Nov 2003 14:55:58

In article <BBC73887.DB75% XXXX@XXXXX.COM >,

Floating windows always *** me up by their inconsistent response to
<Command>-W. The topmost window should close when you do a
<Command>-W, not the next one down.

That is what <Option>-click already does. Now if Apple hadn't canned
balloon help, a help balloon would be a great place to remind you of
this short cut.


Project Inspector bugs / enhancement requests (many)

Post by Kurt Bigle » Wed, 12 Nov 2003 15:47:10

in article XXXX@XXXXX.COM , David Phillip
Oster at XXXX@XXXXX.COM wrote on 10/31/03 9:55 PM:

Going off on a user-interface design tangent here...

Well floating could perhaps be a user-selectable option. It addresses a
certain problem that's all. Non-floating is a real problem as far as I'm
concerned. Floating is another problem. I know that command-W does not
close a floating window, but there are occasions when I forget this too.

I associate the command-W with the close box, so perhaps a different
appearance or placement of the close box would be a way to make floating
windows more user friendly? Or perhaps the process of pressing command-W
should animate the close box, and releasing command before the W would be
like sliding the mouse off before releasing? Sounds very obscure I know,
but I'm always tempted to try these things to find out what the actual
experience is like. It might lead to some other idea which actually would
be workable.

Yes, I have seen such features elsewhere too, and thought it very strange
interface design. It does not make sense that clicking on one thing acts on
another beside it at the same level, based on a modifier key. So now it
looks like this is becoming a real standard and I will have to get used to