Re: Settings windows and dialogs

[Havoc Pennington <hp redhat com>]

Hi,

Guys, I think we need to go back to the drawing board on this
one. It's simply too hard to get right without API support, and we
will not have API support in the GNOME 2.0 timeframe.  So I think we
need a different recommendation for now and file this one under "what
the new GnomePropertyDialog widget should be like."
 
> The following keys will be bound for all settings windows, modulo user
> changes. Note that any window manager key-binding would naturally override
> these, as do bindings particular to text widgets. Escape is not included
> because the proper top-level binding of that is to Cancel, which undoes
> changes.
> 
> Closing keys:
>   Alt+F4
>   Ctrl+F4
>   Ctrl+W
>   Ctrl+Q

We can add these to GtkDialog, but GtkDialog can't be used to
implement your proposal because a GtkDialog requires buttons. We can't
autobind them for GtkWindow. So every app would need to hardcode these
for every dialog. Not feasible or a good idea from a maintenance
standpoint.

(Aside: I think the Escape concern might be more theoretical than anything
else - if a user thinks Escape is cancel they won't press it, and if
they think it's "close dialog" they'll expect it to work - I think
there's at least some user expectation that Escape works. At least I
know we have gotten bug reports before where they wanted it to work.
So just making it work seems to me to reduce frustration.)

> Internal window menu:
> (to be implemented as a pop-up here and including a Close command)
>   F10
>   Alt-released (when supported elsewhere by the toolkit)

Too hard/unmaintainable to implement on a per-app basis, requires a
dedicated widget. No way every app should contain this code.

>   (Undo/Redo will probably have to wait until 2.2 or later.)

No kidding. ;-)
 
>   Buttons will be placed in and apply to individual pages. This is
>   intentionally different from the behavior of multi-page dialogs as
>   often seen on Windows because there are not buttons like the
>   OK/Apply/Cancel triplet seen there and because changes should not
>   be made invisibly. This also permits pages without defaults to
>   appear without a restore button, rather than with one dimmed for
>   no apparent reason.

Where do they go on the page, how are they packed, etc.? 
There's no way this will be consistent without a dedicated widget.

> Lastly, for settings which cannot be instantly applied, dialogs will use
> Try, Cancel, and OK.
> 
>   Try    : Applies settings and does not close.
>   Cancel : Resets the dialog (undoing Try) and closes.
>   OK     : Applies settings and closes.
> 

Here you suddently want a GtkDialog so its buttons are consistent with
dialogs, but your other requirements preclude using a GtkDialog
subclass for the dedicated widget. So you can't just add buttons...


In addition to the application-specific code I've already described,
app-specific code would be needed to duplicate all GtkDialog
functionality including setting the window type hint,
gtk_dialog_run(), etc. etc.


Short answer, if we don't use a fairly no-frills GtkDialog we have a
big inconsistent mess of stuff with all apps doing something
different, and GtkDialog wants to have at least one button.

My favorite suggestion is to make that button a Done button, and talk
the release team and Owen into adding GTK_STOCK_DONE so it has a nice
icon.


It's better to just KISS for now than to make a big rat's nest of
inconsistent cut-and-paste.  We can move to a new GnomePropertyDialog
in 2.2 reasonably easily. But given our tight schedule I think it
would be better to have the prop dialog UI suggestion involve _less_
code for people to screw up.

I know deciding this on practical grounds is anticlimactic, but it's
the right thing to do at this stage, IMHO. 

Havoc