Re: Control-center styles

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Dec 27, 2001 at 07:44:14PM -0500, Jonathan Blandford wrote:
> jacob berkman <jacob ximian com> writes:
> 
> > On Thu, 2001-12-27 at 16:31, Jonathan Blandford wrote:
> > > Gregory Merchan <merchan baton phys lsu edu> writes:
> > > 
> > > > > [ I think this is usability list fodder now. :) Reply-To set 
> > > > > accordingly. ]

Actually, Jeff wrote that bracketed bit, not me. And he was talking
about something else - file selection dialogs.


> > > <snip>
> > > 
> > > Lets keep it in the realm of reality.  Anything you guys are 
> > > talking about has to be considered for 2.2 -- we just don't have
> > > time to experiment. . . .

As I stated earlier in this thread, a top-level widget for instant-apply
 windows is nearly complete. I already presented screenshots of what is
 so far the best way of doing this.


> > >       . . . I think that, if we are going to instant apply, we 
> > > should add [ Help ] [ Close ] for familiarities sake. . . .

This is exactly the reason we must not do this. If you make the windows
look like dialog windows you are going to confuse people because they
will think that they can change settings without affecting the rest of
the environment.


> > >                              . . . Also, if we get rid of
> > > the close button, we have nowhere to put the Help button.
> > 
> > umm, you still have the hbuttonbox.  you just don't add the 
> > close button to it.

Actually, you don't. The GtkDialog widget must not be used for any
instant-apply windows. Instant-apply windows are not dialogs and 
should not hint to the window manager that they are such.


> Yeah, but it looks really goofy to me.  Maybe I'm just wrong here, 
> but a singleton help button just looked weird, and I kept expecting
> it to close the window.

Bingo. It looks bloody awful to have just the Help button down there 
alone. Since we should be providing disclosure triangles for more
advanced settings, the bottom of the window is a bad place for any 
sort of window controls; they would move around too much.


> 
> -Jonathan


(At another point in the thread . . .)
On Thu, Dec 27, 2001 at 05:53:17PM -0800, George wrote:
<snip>
> 
> I actually frequently get confused by progams that have dialogs which
> one must close with the wm close button.  . . .

Any program presenting a dialog that must be closed with the window
manager close button is broken. Dialogs are closed with OK, Cancel, or
a similar button.  A non-broken window manager will take the
WM_TRANSIENT_FOR property or the inclusion of _NET_WM_WINDOW_TYPE_DIALOG
in the _NET_WM_WINDOW_TYPE property to indicate that a Close command
should not be provided. Providing one would confuse users because there
would be more than one way to perform the same action; and which should
that be and how could the user possibly know which closing the window is:
OK or Cancel or some other option?


>                             . . . My personal opinion is that we
> shouldn't depend on the wm for these things, but it could be just me.

(see below, about robustness)


> The other day I logged into my university account and found a ctwm 
> setup with no way to close windows. . . .

Middle-click on the desktop to get a window operations menu. Select from
the menu and then click on the window to which you want to apply the
command. It seems the only thing ctwm gets right is its presentation of
workspaces. (I had to spend a few minutes trying to figure out what each
item, other  than the workspace switcher window, would do.)


>           . . . It feels more robust to me to have the close button
> on the dialog.

Not all of the broken window managers have been implemented. If you try
to design for every possible form of brokenness, you may as well give up
now; you'll never finish. Any masochist who decides to use a brokem 
window manager rather than the defualt window manager deserves what he 
gets; any sadist who installs and sets as default a broken window manger
for the systems he administers should be rallied against with vengence
and will probably also get what he deserves.

If you want robustness, then make the code robust and don't shovel off
programmer responsibilities onto the user. X is an interprocess
communication mechanism and with it you can detect, to a sufficient
extent and within the library code, brokeness in the window manager.
A particular program can cease operation in an incorrect environment,
just as a particular window manager can refuse to show windows not
obeying certain protocols. Better still a program can change its
interface when circumstances demand it. If you try to program around
the ways in which any of this can be faked, then you may as well spend
your life debugging VB viruses.


 Executive Summary
 -----------------
 If instant-apply settings windows are not going to be done correctly,
  it's better to do them not at all.



No top-level window which immediately affects anything else without
an explict OK, Try, Apply, Test, or similar command from the user is
a dialog.

A dialog is called such because it is presented when interaction with
the user is required to complete the command. Were we looking at a play,
we might see this:

User:     Computer, add an entry to the database.

Computer: What is the entry?

User:     It is this and this and this. OK, that is it.

(The Computer adds the entry.)

Computer: It is done, kind sir.

User:     Add another entry to the database.

Computer: What is the entry?

User:     It is this and that and . . . I forgot. I'll do this later.
          Cancel that order.

Computer: Very well sir.


An instant apply settings window is another way of looking at and
manipulating data. If you have a file open in a word processor and
choose to view the properties of the file, by way of either the file
manager or a similar command chosen from the menu shown by the word 
processor, then in both of the windows present (word processor window 
and settings window) you are looking at the same data. The word
processor window shows the data in a composed view, whereby you do
not see markup and paper settings but instead see their effects. The
settings window would probably not show markup either, but would show
paper settings and other such information applicable to the same 
class of data that the file is. Because you are looking at the same
thing in both windows, you should expect actions taken in one window 
to affect the other window. It's almost as if you had issued to emacs
the C-x 5 2 command and changed the font used by one of the frames.

Cheers,
Greg Merchan