Re: Constrained text entry

["Eric M. Monsler" <emonsler beamreachnetworks com>]

Jeff,

One UI feature you could use might be to change the font or color of the
text being entered, until the user hits 'Enter' and the string is
parsed, checked, and used.

I don't like choices 1) or 3), because I commonly start to enter text
into an entry, switch to another app or window to check something, and
then switch back, losing my start at changes.  Those behaviors may be
acceptable for trivial entry items, but would be very annoying for
longer entries.  Even a filename entry could be very anooying to have
lost the patially typed path.

In particular, I think that both of those would be tremendously
aggravating for a user if the entry validation took noticeable amounts
of time, much less a full second.

I think that 2) as you described is the best of the three choices. 
Alternately, in place of a separate dialog box, you could have a section
of window for modification, with buttons 'Apply' and 'Revert'.

I agree that this is a problem.  I have a certain combobox in my
application that users have sometimes typed in and failed to hit enter,
leaving the typed value visible but not actually changed.

In places more critical, I display as a label the current value below
the entry.  The label is updated and entry cleared when enter is hit. 
This is a semi-ugly kludge but does work and prevent confusion.

I think I've just convinced myself that the right answer is two
behaviors, depending on whether an 'OK' or 'Apply' button is available. 
Unfortunately, this requires each developer to make reasonable decisions
if the behavior is going to 'feel consistent' across all Gtk/Gnome
applications.

Eric