Re: HIG and Escape

["James K. Lowden" <jklowden schemamania org>]

On Mon, 10 Mar 2003 15:43:01 -0600, Lars Clausen <lrclause cs uiuc edu>
wrote:
> On Mon, 10 Mar 2003, Alan Horkan wrote:
> > On Sun, 9 Mar 2003, Lars Clausen wrote:
> > > Date: Sun, 09 Mar 2003 21:01:01 -0600
> > > From: Lars Clausen <lrclause cs uiuc edu>
> > > On Sun, 9 Mar 2003, James K. Lowden wrote:
> > > > Lars, I see the Preferences dialog is much improved but not
> > Gladified.> > I'll take another shot at it.  Are we bound to a tab
> > dialog, or did we> > decide on a mozilla-like tree-on-the-side
> > treatment, or does anything> > go?
> >
> > I suspect that in time the Preferences will become more complicated
> > and that a treeview will be necessary, may as well plan ahead.

Let me update my last attempt, cf.
www.SchemaMania.org/dia/noodle/dia_preferences.png. (Lars, the .glade file
is there, too.)  Lars observed that it was missing quite a few things even
at the time.  

I don't agree that the GUI needs "room to grow" unless those needs are
immediate and obvious.  The supporting data structures, yes, but if a
dialog needs rearrangement over time, that's OK.  Some options will
disappear, too, over time.  The whole thing evolves as better ideas and
implementations push out worse ones.  

If there are options we think should be added but aren't ready to
implement, we can include them in the dialog as grayed out.  

The disadvantage to tabbed dialogs (or tree views) is they turn into a
video game: the user winds up clicking on every tab, sometimes more than
once, looking for the option.  Quick now, is the default size for a new
diagram window a "diagram default" or a "view default"? 

Of course, it's possible to crowd too many options on a single dialog,
too, making it hard to digest.   Good layout and the rule of seven will
keep you in bounds most of the time.  I have yet to see a dialog bigger
than 640x480 pixels that shouldn't also have been broken up or
consolidated.  

> > [x] check boxes.

That would be standard, not to mention conserving pixels.   

> I think the whole design needs serious looking at.

Quite.  :-)

> I've wondered just how much memory undo steps take.  It could be
> interesting to turn the limit off and see what happens.  Emacs, for
> instance, has infinite undo, and I have it running for months sometimes
> without the undo stack overrunning the system.

It would be nice to measure it and track the high-water mark.  

> > > There was a mail a ways back showing how the entire thing could be
> > fit> in a single window.  That was kinda neat.

        :-)

> > > As for Glade-ifying, doesn't that require that we depend on libglade?
>
> I'm not worried about the performace, I'm worried about the extra
> dependency.  Each extra dependency is a hassle for users.  Why does it
> have this dependency?

The only other GTK2 app I have installed so far is Bluefish.  It has very
nice dialogs and no dependency on libglade.  So, either they have a cool
system for generating nice dialogs sans glade, or libglade is only needed
to run Glade, not glade-generated dialogs.  Either way, there might be a
page there to borrow from.  

--jkl