Re: Constrained text entry

[Damon Chaplin <damon ximian com>]

On Thu, 2001-08-09 at 00:02, Jeff Henrikson wrote:

> The problem is very simple and common: I want to have a constrained
GtkEntry widget, suppose one which only holds a floating point
> double.  So obviously you just catch the signal that lets the value change, and if it parses in your favorite ascii->number
> function, you are all set.  If it doesn't, you need to set the entry box back to what it was before so the user can see that it
> didn't work.

I do think this is an important usability issue, and I hope it
does get addressed if we ever have a usability style guide.

I couldn't see it covered in the FAQ, by the way - that only seems to
cover conversion/validation of characters while typing, which is a
slightly different issue (unless I missed this question).

(An important side-note: I don't think GtkCombo should use the Enter
key for popping up the list. I think Enter should mean 'validate and
accept this field and move on to the next one', as it usually does
in Windows.)


The problem gets even more complicated if you are developing a new
widget. A while back I wrote the EDateEdit widget for Evolution.
It allows you to enter dates and times, and has popups where you can
select dates & times as well.

It took me ages to figure out how the widget should behave when
invalid data was entered, and I'm still unsure if I did the right thing.
What should a widget like EDateEdit return if the date currently entered
is invalid? (Currently it returns the last valid date/time entered, but
also has an e_date_edit_date_is_valid() function which tells you if the
date currently entered is invalid.) Should the widget itself handle
showing an error dialog and grabbing focus back? (Probably not, as it
doesn't know which type of the situations you listed it is in.) 


> What is the correct behavior?  It's a bit tricky.  I can think of at least three distinct cases.
> 
> 	1) nonmodal entry on a toplevel window
> 		Example: the zoom percent box in the toolbar of MS Office 97
> 	2) entry in modal dialog box
> 		Example: "column width" command in MS Excel 97
> 	3) nonmodal entry in app with multiple top level windows
> 		Example: the prototype tool that I was developing before.  It
> 		had an OpenInventor browsing window (based on Motif), and GTK
> 		control panel that had number entries for tweaking parameters
> 		of the graphic.
> 
> 1) Any text is allowed to be typed so long as the application's focus remains in the entry and the system focus remains on the
> application.  If the user clicks/tabs away, switches apps or virtual desktops, the program must reclaim the focus, set the entry
> back to its original string, and place the focus on the fully selected string (not with a caret at an insertion point- just as if I
> freshly tabbed into this box so that I can overtype it if I choose).
> 
> This is the behavior of Office 97, and IMHO the "right thing" (or at least a very sensible default) irrespective of platform or
> application.

I agree with most of this. Though I'm not sure it should claim the focus
back from another application, if that is what you meant.

Either show an application-modal dialog, or just revert the text, select
it all, and set the application's focus back to it. So when the user
switches back to the application they can sort it out.

I'm also unsure about reverting the text. That can be annoying, as
someone else mentioned. Maybe the dialog should have a 'Revert'-type
option.


> 2) Suppose the dialog has an "OK" and a "Cancel" button.  Unless this is a complex dialog box requiring interrelationships between
> multiple numbers to be satisfied, the entry should allow any text until pressing "OK" or "Cancel".  (If you do have aforementioned
> relationships, behavior might be better designed as in 1). )  If the user clicks "OK", the text is parsed.  On any failure, a modal
> message box tells the user that a certain entry is malformed and leaves the dialog up.  Focus reverts to the entry which violated
> the test.  If multiple violations occur, only one need be mentioned and everything will work out.  If the user clicks "Cancel",
> then all entries must be discarded and no parsing should take place.  On the next appearance of the dialog box, the values should
> be reset.
> 
> This is the behavior of the "column width" command in MS Excel 97.

As you later said, this one is easy to deal with - when 'OK' or 'Apply'
is clicked you check all fields for validity and show a modal dialog
if they aren't.

 
> 3)  This is the same as 1) only you have to also catch focus switches between different toplevel windows of the same application,
> even if they are made with different toolkits or whatever.  This may or may not be for free depending on the way you are catching
> your X events/GTK signals/whatever.  On the other hand, even incorporating together the event loops of GTK and Motif/Inventor was a
> real pain, so I can imagine there being some bad interaction here that would prevent ever getting the behavior right.

You'd still get the 'focus_out' event so it should be very similar to
(1), I think (as long as you don't try to grab the global focus back to
it).

Damon