Re: Best practice query: Entry field "user's done editing" handling?

["A. Walton" <awalton gnome org>]

On Mon, Dec 23, 2013 at 8:02 AM, Chris Angelico <rosuav gmail com> wrote:

> On Mon, Dec 23, 2013 at 11:25 PM, Tristan Van Berkom
> <tristan upstairslabs com> wrote:
> > We don't want to be chasing down scenarios where this could possibly
> > break, so the best thing we can do is commit everything immediately
> > (you could have an asynchronous layer in your data model which handles
> > this, if performance or flash wear is an issue).
> >
> > I strongly advise against usage of "focus out" events for committing
> > data...
>
> Hmm. Trouble with committing immediately is two-fold: firstly, it
> involves network traffic (this has to keep all remote users in sync),
> and secondly, some of the fields have reformatters and sanitizers. The
> server has to be able to guarantee that the Permissions field is a
> blank-delimited list of account names, for instance, and it can't do
> that if the user's half way through typing one. I'm currently using
> focus-out because it does most of what I want; if the user always
> types something and then finishes by tabbing out, it's easy and safe.
>
> I was mainly hoping for something that's UI-blessed as an official and
> normal way to do this kind of field validation, but if there's nothing
> official, next best is to find out what other applications do and
> imitate that. Ultimately, I want to make sure my program does what
> other people expect of it.

GNOME and by extension GTK+ applications with settings are expected to have
either one of two things:
* Instant apply settings. These happen "as soon as" you change them. (For
some value of "as soon as" such as "shortly after", or "asynchronously as
soon as", as appropriate.)
* An "Apply" button on the settings window. These are less common, but in
some cases it still makes sense to have it.

If you're not doing either of those, you're doing it wrong. (See
https://developer.gnome.org/hig-book/3.2/windows-utility.html.en).

Frankly I don't see what's wrong with making it instant apply from the
description. Connect to the GtkEditable::changed signal, throw in a short
timeout that gets reset any time someone changes the field. If they have
stopped changing the field for more than some amount of time, say half a
second, then "commit the change" - do whatever you have to do with it
(validate it, send it to a server, write it to a file, etc.)

(As an aside, for instant-apply entry widgets, it would be really good if
we had a consistent way of showing validity. Personally I'd play around
with using the "libsexy" behavior of changing one of the GtkEntry icons to
indicate the entry was invalid, but you could also play with the CSS and
make the background red or fire a signal so you could tell another widget
like a label that there's an error. It'd be even nicer if Gtk+ had this as
a widget so I could just create a GtkSettingsEntry and wire it up
appropriately and all Gtk+ applications could be the same, but that's
certainly too much to ask. If there's anything that's certain in life it's
that developers love consistent behavior, but hate adding code to enforce
it. Perhaps someone could kick it over to the HIG guys to argue about.)

-A. Walton



> ChrisA
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list