On Mon, Dec 23, 2013 at 8:02 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, Dec 23, 2013 at 11:25 PM, Tristan Van Berkom > <tris...@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 > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
