Constrained text entry

["Jeff Henrikson" <jehenrik yahoo com>]

I sent a complaint to gtk-list a couple of weeks ago, and haven't gotten any substantial answers.  Below is the issue summarized
currently, and here is a link to follow back if wanted:

http://mail.gnome.org/archives/gtk-list/2001-September/msg00149.html

Basically, I don't find it obvious how one is supposed to create a GtkEntry with a constraint.  I think this is causing people to
write apps with bad usability.  The simplest example of the thing I mean by constraint is a number in the entry, but abstractly any
C function which tests validity could be a constraint.  Floating point numeric constraint is solved the wrong way for example, in
the GIMP's File|New box, and in the GTK faq.  The duct tape solution there is to just prohibit letters (perhaps besides e, unless
there is an e already) from being put into the box.  Equivalently, they parse on every keystroke and reject any failures by
reverting the contents.  This is bad general policy, since it only works for numbers and some other simple things.  If say you had
a formula in the box that required matched parenthesees, this approach would totally fail because of the micro editing checks.

In my current state of mind, the "right" API to expose is the one used for closing an application: have a signal whose return value
indicates whether a valid change has been made to the contents.  This is not done.  The only semi-relevant signals available from a
GtkEditable are "activate", "changed" and "focus-out-event" from GtkWidget, none of which do useful things with their return value
or otherwise provide an easy passable implementation.  "focus-out-event" is the closest but no cigar.  Just to demonstrate what I
am talking about, I wrote an concrete example of what I would like, and wasn't even able to get it right the hard way!  There seems
to be a bug in the focus grab functions.  See the aforementioned long diatribe for complete code and bitching, here again for your
clicking pleasure:

http://mail.gnome.org/archives/gtk-list/2001-September/msg00149.html

Reading the gtk-list archive, people seem to see this problem often (hence the faq entry, go figure), and yet I haven't seen a
single GTK app that does this right.  Apparently applications everywhere are growing a subtle usability SNAFU for no good reason.
I brought it up over usability gnome and gtk-list and some people agreed with me.

A new signal in GtkEditable would solve the problem so far as I can see.  Call it "macro-changed" or "check-validity" or something
like that, with ability to reject by return value.  Every developer figuring this out will normally look under the signals for
GtkEditable, and if the right behavior is attached to a particular signal, then we would get consistent good usability for cheap.
Otherwise app developers are going to continue to duct tape, and their errors will go uncorrected until their bits go to rot
somewhere after nobody continues to use them.

Some details would be needed to complete the description of this behavior, for example, on an invalid entry does the control revert
contents or just reclaim focus?  If it keeps reclaiming focus, how does the user abandon changes to get out of the box?  (esc key?)
There is probably more than one "good" behavior which could hopefully be distinguished by the behavior of the signal handler.  Just
a few examples of the possibilities would be necessary.

The details would need to be polished on usability gnome org 

My requests:

1) explain why my code example at the twice cited URL does not grab focus correctly.  (the version I tested this against was
somewhat old- 1.2.7 on MS win32)

2) tell me when any such changes might show up in a release, given that I manifest the behavior I am talking about in (standalone)
code.  What if I patch GTK myself?

Given this, I will bring it up again on usability gnome and see if there are diverging opinions on what exactly is necessary.


Jeff Henrikson