Re: RFC: new features

[Tristan Van Berkom <tvb gnome org>]

On Thu, Jan 12, 2012 at 7:23 PM, Alexander Larsson <alexl redhat com> wrote:
> On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote:
>
>> VALIDATION
>> Many developers in the web world have become accustom to "validating"
>> the contents of forms before submitting them. While we would often argue
>> against allowing invalid input in the first place, that can often
>> confuse users. In this case, allowing the input and providing an
>> accurate reason why the input is invalid yields better results. I'm not
>> sure what a good API here would look like, but it needs to be flexible
>> enough to work with built-in and custom widgets.
>
> There is some level of validation in the gtk+ printing dialog. The
> printer configuration files (PPD files) can specify certain combination
> of enabled features as "incompatible" (i.e. can't do full duplex while
> stapling or whatnot). Whenever something is invalid we show a label
> somewhere explaining the problem and then each problematic settings
> widget gets a warning icon.
>
> This is imho a pretty nice way to handle validation. You're not unable
> to input invalid input (which can be confusing), but you get instant
> feedback on when and what is invalid.

This is a very good point, it would be great to incorporate some basic
validation mechanisms in GTK+, in many cases form style validation
is possible, i.e. one can fire up a dialog and hit the "Apply" or "Commit"
button at which time entry validation can take place, but in some cases
that's just really annoying (i.e. who needs to waste time with the extra
step of firing up a dialog and hitting a "Commit" button). While configuration
dialogs definitely fall into the first category, many editor applications
such as user interface designers or image manipulation programs have
property editors available at all times. In these cases validation should
always happen synchronously.

I think the warning icon with tooltip is a good idea, I've also considered
changing an entry's background color to be red while invalid input is
entered (of course this requires that the theme define what is a proper
"error" color...)

One classical error we should keep in mind is that entry validation
at focus-out time is just not stable, in many cases for instance you
get a situation where:
  a.) User selects object
  b.) As a consequence, current values are set in the editor widget
  c.) User enters invalid input
  d.) User selects another object
  e.) New values are entered into the editor frame
  f.) Finally, after old input is potentially lost, the focus-out event is
      finally delivered and validation is no longer possible or logical

This is a common problem in multiple platforms and toolkits, it would
be great IMO to have some backing support from the toolkit to help
developers to get it right the first time.

Cheers,
           -Tristan

>
>> MENU BUTTON
>> A GtkButton that shows a menu when clicked (and handles positioning,
>> etc). Some would just use a combobox, but I find them pretty different.
>> You'll find this sort of "menu button" in various VMware products on
>> Linux. (I know the fullscreen toolbar used to have it at least).
>
> Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to
> do but would be nice to have in a single place. Also, it needs some help
> from the theme to look good, like adwaita does here:
> http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705
>
>> WIDGET STACK
>> Like a notebook with no tabs or decoration. You "push" and "pop" widgets
>> on and off the stack. This is the navigational structure often found on
>> iOS. The reason I think abstracting it might make sense is more about
>> animating between widgets once Gtk starts landing animation (post
>> clutter integration obviously). It would be great if this nicely
>> integrated with a "navigation bar" type widget. Here[3] is a video of
>> some crappy animation code I wrote to do this.
>
> Not only does it help with animation, but its also nice in terms of size
> allocation. Often you want a set of widgets that can temporarily change
> into another set (for instance during editing) without causing a UI
> reflow. Having a widget stack like this helps with this size allocation
> handling.
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list