Re: [Usability] Re: Settings windows and dialogs

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Jan 16, 2002 at 01:41:13AM -0500, Havoc Pennington wrote:
> 
> 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."

Which is why I spent the weekend prior to mailing writing one. 

http://www.phys.lsu.edu/students/merchan/GNOME/CGSettings-Book-and-Page.tar.gz

(The "CG" part is meant to be changed; CoGnomen, CG, etc. are what I'm
using for experimental work to avoid clashes.)


<snip>
> 
> > 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...

One of the reasons I've been insistent about not calling instant-apply
windows dialogs is that the GtkDialog widget is completely innappropriate
for such a thing. A sane window manager will remove the close button from
a GtkDialog's frame because the dialog contains within it an immediately
visible way to close the window and having two obvious methods would be
confusing. (Does the window frame close button Cancel or OK? How would
the user know?)

Settings which cannot be instantly applied should use the GtkDialog widget
with Try/Cancel/OK. The instant-apply settings should use another one.


> 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.

We're better off holding back instant-apply until it can be done correctly.
Early errors in GUI's tend to get locked in.


> 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

The code is already there. It just needs to be put in and namespaced
appropriately.


Cheers,
Greg Merchan