Re: [Usability] Re: Decision: instant apply window buttons

[Gregory Merchan <merchan phys lsu edu>]

On Mon, Jan 21, 2002 at 08:33:36PM -0500, Havoc Pennington wrote:
> 
> Gregory Merchan <merchan baton phys lsu edu> writes:
>
> > It's only a dialog if you have to somehow OK it.
> > The Mac nomenclature is simply wrong on this count.
> 
> Is there some a priori definition of dialog that I missed?

Others have explained this better than I could right now. If it matters,
read the archives. (iirc, mpt made the most lucid presentation.)


> My question is about practical impact of the type hint.
> 
> i.e. what is the practical difference in behavior that leads you to
> want these things to be NORMAL not DIALOG. What would the WM do with a
> DIALOG that you do not want it to do?

It would not place a close button on the frame of a DIALOG-type window.

A dialog or an alert is supposed to be closed with OK, Cancel, or the like.
A close button on the window frame of such is ambiguous; it could mean either
OK, Cancel or some other closing action. Apparently Windows always places the
frame close button and thus their guidelines recommend responding to it with
an alert like the Save Before Closing alert. We're better off not presenting
that button on dialog frames, thus avoiding ambiguity, and the nuisances
of multiple stacked secondary windows and having to click all the extra
buttons to close them afterwards. Humorously enough, the Windows guidelines
show that that alert will also have a close button on the frame which
consistency would demand popping up another alert for the alert ad nauseam.

(I have seen that some Windows programs make that button insensitive, but
 I don't think it ever becomes sensitive in that case, so once again it
 shouldn't be there.)

I've also seen a bug in some sawfish themes that treats all WM_TRANSIENT_FOR
windows as dialogs, including palettes. The Sawfish themer doesn't help much
in this regard and, iirc, neither do the capplets.

I think there is precedent on X from CDE for treating dialogs this way. I
seem to recall Calum mentioning this as an explicit design choice there.
WindowMaker also treats windows recogonized as dialogs in this way, and I've
not noticed what others do.

> Havoc

Another point, since you've your own window manager. :-)

Because the frame close button should not be present on every window, any
buttons distanced from the edge of the window by it would be shifted over
were the gap closed. Placing it spaced from the edge by other buttons
would seem awkward to perhaps everyone, so it should be placed on a corner
alone. This should also be done to avoid the misclicks that are so common on
Windows which places Maximize next to Close. (I've heard that the resulting
screams tend to raise the noise level in offices.)


Cheers,
Greg Merchan