Put all GTK 1.3.x bugs on 2.0.0 milestone

There's some useful discussion of this topic here:

  http://mail.gnome.org/archives/gtk-list/2001-August/msg00224.html

We can conceivably make some progress in 2.2 without breaking binary
compatibility, it depends on what the overall solution looks like.

More discussion here:
  http://mail.gnome.org/archives/gtk-list/2001-December/msg00164.html

Here is what Java has for input validation:
http://java.sun.com/j2se/1.3/docs/guide/swing/InputChanges.html

And here is what Qt has:
http://doc.trolltech.com/3.0/qvalidator.html

Created attachment 6324 [details] [review]
patch to add validation to widgets for gtk+-1.2.10

Another thing we might consider is "templates"
e.g. you have "(    )    -       " in gray in the entry, 
and you can edit the phone number inside there.
Or for an IP address you have the four dots in gray.

Sun's site contains:

"The following example has two text fields, with the first one
expecting the string "pass" to be entered by the user. If that string
is entered in the first text field, then the user can advance to the
second text field either by clicking in it or by pressing TAB.
However, if another string is entered in the first text field, then
the user will be unable to transfer focus to the second text field."

This is hardly good usability. We don't want the user to be notified
when he's finished typing in the code, but as soon as he does
something we don't want. Granted, password checks are special, but I
believe input validation covers syntax issues, not if the information
passed in. IOW, if you are typing in a product code, and it's a
7-digit numeric code, then entry of letters can be blocked (a label
indicating the error would be nice), but it isn't the validator's task
to check if the code actually exists in the system.

And blocking the transfer of focus is quite evil, IMHO.

another post
http://mail.gnome.org/archives/gtk-devel-list/2003-January/msg00019.html

Created attachment 13397 [details]
Proposal and patch to implement validation for GtkEntry,GtkSpinbutton and GtkCombo widgets

The attachment above (id=13397) is a compressed archive file. When you
click
on it, it will be saved as file called showattachment.cgi. 
It should be renamed to : ValidationProposal.tar.bz2

I like the ideas from QtValidator to a) allow to indicate prefixes of
valid values (this information would have to be used inside GtkEntry,
e.g. to prevent entering letters in a digit-only field) and to allow a
"fixup" (this could be used in an error dialog). Another needed
feature is the ability to delay checking of contraints until a group
of related inputs is committed (ie an ok button is pressed). Strict
validation on focus-out is only appropriate if everything is
instant-apply, otherwise it is just annoying to the user.


Comments on the patch:

1) I think it would be nicer to add a validate() virtual function to
GtkWidget instead of poking in the entry internals from gtkwidget.c.
The default implementation would simply return TRUE;

2) I believe you should drop entry_pending_validation and work with 
gtk_window_get_focus() instead.

3) Should use GDK_Tab/GDK_KP_Tab instead of a numerical keyval (the
code currently seems to miss Shift-Tab (for cycling backwards)

I guess we also need something like the ErrorProvider of WinForms
(a trivial little 
widget which will show an error icon with a tooltip describing the error, and hide the 
icon if there is no error)

Created attachment 14215 [details]
More detailed notes on proposal above (attachment (id=13397))

I would like to point out that tying validation exclusively to a focus
event is  incorrect. You are in many cases punishing the user by
allowing him to enter data which you *know* he shouldn't be (since you
have the contents of the widget in every time) typing in and then
saying "oh-oh, you shouldn't have done that".

I agree that for certain cases focus out is the correct event to wait
for, however, the vast majority of cases would have much improved
usability if we caught errors before the focus event - we *should*
worry about every keypress the user produces!

I would like to work on a proposal that involved three things:

- validation tied to insert/delete_text (changed), which would bar the
user from typing, for instance, alfabetical characters in a numeric
field. The error indication would be beeping or flashing a border on
the widget in question, taking into account localization issues.
- validation tied to focus_out, which allowed for post-entry
validation (this has to be done for certain types of data entry, but
it is actually a minority of the cases)
- entry masks. this is an *essential* property for any
commercial-grade toolkit, and every homebrew windows application
written in VB uses this. From personal experience this is something
users appreciate *very* much, and it is very hard to implement without
toolkit support (though it is possible, since I have a prototype
working in Kiwi).

(Unfortunately I am very busy with my MSc thesis until the 21st of
february and my MSc supervisor will kill me if he knows I'm commenting
on bugs instead of working on it, but this is a very important matter
and one I have some experience with)

While I don't strictly argue for implementing all this in GTK+, I do
believe it is a serious enough matter to warrant further
investigation. In other words, if we don't have it in the toolkit,
then a standard set of hooks should be provided, and a validator
framework worked on and documented/distributed accordingly.

If people diverge significantly I'll write up a justification for my
strong position, but I have worked a lot with this sort of issue on a
number of toolkits and I hope I can contribute to a better framework
for GTK+.

Btw, when I say entry masks, I mean the same as Havoc calls 'templates'.

Christian, I mostly agree with you, but I think we should add
dialog-level validation to your list. When there are multiple related
controls on a non-immediate-apply dialog, it makes a lot of sense to
not block navigation, but simply mark invalid entries (e.g. like the
above-mentioned ErrorProvider) and disable the Ok button.

It seems that often providing text that explains the problem 
alongside the entry is a lot nicer than blocking focus transfer or
doing a dialog; then when the user tries to "submit the form" (presses
OK or whatever) you might pop up a dialog calling attention to the 
problematic entry. Or you might make the submit form button 
insensitive, though that kinda sucks until we have tooltips on 
insensitive buttons.

Windows XP also offers the option of a little tooltip/balloon pointing
out what's wrong with the entry, so you wouldn't have to keep 
space in the widget layout to display the error message.

But it should perhaps be somewhat up to the app what it wants to do
(block focus transfer or not, etc.)

Both blocking focus and opening a dialog are very intrusive. The
`conventional' approach is:

- beep
- flash border around widget

They actually work well; the second being less intrusive but slightly
less effective at warning. The `soft' or `modern' way of doing it
would be to have a small floating label indicating precisely what was
wrong, perhaps one shaped as a baloon.

Disabling the OK button should be done if the form validation blocks
confirming the dialog, but we shouldn't force the user to move the
mouse to the button and hope for a tooltip to get the message; it
should be conveniently displayed to him in a decent position.

I'm not sure how GTK+ can aid implementing this beyond offering
complete validated widgets with very special API, or some additional
signals for people to contribute their own custom widgets.

I agree with Christian's ideas, except for the flashing borders thing.
I think having a tooltip/balloon on error when the entry has focus
might be better and more clear.

The dialog-level validation also sounds nice, but it really requires
some thought on how we are going to implement that in a clean, sane
way for gtk+.

Anyway, I would be happy to volunteer to implement most of Christian's
ideas for 2.4. Especially the entry mask stuff for GtkEntry sounds
interesting to me (I dunno why actually ;).

Let me know what you think, and which direction we are going to take here.

So it seems the GtkEntry extensions should be:

 - some way to display an invalid state, balloons/beep/flashing 
   border/whatever
 - some convenient hooks to set_validate_function() so that 
   you can easily write a function that just returns a 
   user-readable explanation of the problem and perhaps an 
   offset into the entry text for where the balloon should point
 - a template feature so you can have a phone number or IP 
   address entry

Then perhaps on the GtkWindow level, a function like 
gtk_window_contains_invalid_data()? which would simplify 
checking all entries (and other widgets too, perhaps) 
when the user tries to close the dialog.

Comment on attachment 6324 [details] [review]
patch to add validation to widgets for gtk+-1.2.10

Obsoleted by newer patch, switch to gtk2.

*** Bug 164805 has been marked as a duplicate of this bug. ***

*** Bug 315988 has been marked as a duplicate of this bug. ***

Look at http://dev.investorsidekick.com/begtkextra/ (C) and
http://view.sourceforge.net/classes.php  (C++)  FieldEntry widget.
From the web page:
"The FieldEntry widget is a standard GtkEntry (...). Validation happens on every
key press and ensures that the content doesn't contain any characters that don't
belong. The entry is designed to not get in your way. Copying and pasting also
just work between entries and other programs on the system." 

Tutorial on Qt's input validation classes:
http://www.digitalfanatics.org/projects/qt_tutorial/chapter10.html

I propose that we would follow the Qt's idea about validator objects.
We could have an abstract class like:

struct _GtkValidatorClass
{
   GtkObjectClass parent_class;

   GValidatorState (*validate) (GValidator *self, const gchar *text, 
                                GError **error);
   gchar * (*fix)              (GValidator *self, const gchar *text);
};

Then the actual implementations, like

* GtkValidatorRequiredField
* GtkValidatorRegEx
* GtkValidatorRange
* GtkValidatorMask

So, the applications could write something like:

  validator = gtk_validator_range_new(1, 100);
  gtk_entry_set_validator(entry, validator); 

  /* Or should we have something like 
     gtk_validatable_set_validator(GTK_VALIDATABLE(entry), validator); */

This approach is heavier than some simple callback function based approach, but
I think it's much cleaner, specially in case of validators that need
private data as well.



When an error is encountered, it needs to be displayed to the user. 
I propose generic interface for this purpose. For example:

struct _GtkErrorProviderIface
{
   GTypeInterface parent;
};

void gtk_error_provider_set_text(GtkErrorProvider *self, const gchar *text);
char *gtk_error_provider_get_text(GtkErrorProvider *self);

void gtk_error_provider_set_icon_name(GtkErrorProvider *self, 
   const gchar *icon_name);
char *gtk_error_provider_get_icon_name(GtkErrorProvider *self);

Interface would require properties "text" and "icon-name". 
The widget implementig this interface could be GtkErrorProviderWidget
that would be visually similar to .Net ErrorProvider component. 
So, an indicator icon is displayed and tooltip is given when mouse 
howers on top of that.

GtkEntry and other widgets could then do something like :

  state = gtk_validator_validate(entry->validator, text, &error);
  
  if (error) {
    gtk_error_provider_set_text(entry->error_provider, error->message);
    g_error_free(error);
  } else
    gtk_error_provider_set_text(entry->error_provider, NULL);

in "changed" handler (or whatever).


I think it would be important to have this GtkErrorProvider to be an 
interface instead of single widget, since different applications 
can have very different needs of how to report errors. 
I can imagine that somebody could embed the error reporting 
feature into some existing component.

*** Bug 446056 has been marked as a duplicate of this bug. ***

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new