Re: changing properties dialogue

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

On 19 Oct 2002 20:17:30 -0500, Lars Clausen <lrclause cs uiuc edu> wrote:
> On Sat, 19 Oct 2002, James K. Lowden wrote:
> > <Tab> navigates, <Esc> cancels, <Enter> proceeds.  On ancient Mayan
> > keyboards, they even called it <Send>.  
>
> So that means that we should have Enter close the properties dialog?  I
> can't think of any cases where there is any required data entry.

This thread started on Wednesday wrt the ER shape properties.  For the
record, I'm looking at 
        $ dia --version
        Gnome dia 0.88.1

so I hope my commentary is relevant.  

To answer your question, Yes.  "OK" should be the default button, and
<Enter> should activate it.  If she changes the property and then changes
her mind, <Esc> will do nicely (and works).  If she likes what she sees
(whether or not she changed anything) <Enter> will send it home and
dismiss the dialog.  What could be better?  

That dialog has no need for "Apply", either.  What is it, like, 3rd base
or something?  Something she touches on her way home?  

I know, the idea is, pick a new color, press "Apply", look it over, and so
on.  But why?  Why not apply the color when returning from the color
selection dialog?  That would be feedback.  Of course, that would mean
"Cancel" would have to undo the change, which is more work for the
programmer.  But it would be nice for the user.  

I went back to Alan's original scenario, changing the name of the shape. 
One might say, well, he can type in the name and press <Enter> (invoking
"Apply") and then <Esc> to Dismiss.  Convoluted, but mousefree.  But. 
Pressing <Enter> doesn't invoke "Apply".  :(

On that topic.  Many years ago, I used IDE.  Not "an IDE", the IDE, a case
tool vendor of a product called "Software Through Pictures".  What do you
know?  It's still around:

http://www.aonix.com/content/products.html#stp

At the time, I think it ran on OpenLook.  This program had many cool
features, but the best one was what they called, "Typing on the surface". 
If you wanted to change the name of the object, you clicked on it (once,
not twice) and ... started typing.  Viola, the gizmo on the screen became
editable in place, "I" bar and all.  When you were done, click somewhere
else.  

*That* would be a feature.  Can we do that?  

Around the same time, there was a shlocky but much cheaper product
available on Windows (um, 3.0 I think) by the name of Popkin.  I evaluated
them both, tried to implement the same model on both.  On price, Popkin
had a big advantage.  But on utility, on sheer elegance and
thoughtfulness, the IDE product was better by far.  Next to it, Popkin's
offering was clunky at every turn.  Not that that's anything to be ashamed
of.  In 15 years, I've never seen better.  

References.  

Havoc makes tangental reference to the editbox-eats-<Enter> behavior and
how to deal with it.  Apparently it's a GTK (1?) misfeature.  See the
bottom of:  

http://developer.gnome.org/doc/GGAD/z101.html

Location of buttons, their purposes, and choice of default button are
discussed in the Gnome HIG:

http://developer.gnome.org/projects/gup/hig/1.0/windows.html#explicit-apply-figure

I think we should adhere to the HIG unless we have strong reason not to. 
Gnome seems to consistently place the "good" button in the lower right,
but they state it explicity in only one place that I found:

http://developer.gnome.org/projects/gup/hig/1.0/windows.html#alerts-information

Look for "affirmative".  

HTH.

--jkl

P.S.  On my RH 7.3 system, btw, the ER dialog has odd memory.  The default
button is the last one pressed.  If you press "Cancel", that is the
default the next time you open it.  This might be related to what happens
if I press <Esc>: it dismisses the dialog but I can't reinvoke it, and
soon after Dia crashes. :(