Re: Gtk feature requests

[Havoc Pennington <hp redhat com>]

falconer falconer best vwh net writes:
> Hi all; I just saw that gtk 2 is coming out soon.  It's probably
> too late for 2.0, but could I get folks to consider the following
> features for a future release?  These comments stem from frustrations
> I encountered while developing under gtk.
> 
> Most of these could be considered bug reports rather than changes
> to the API.

Both features and bug reports should go in bugzilla -
http://bugzilla.gnome.org, otherwise they typically get lost. If you
put the report in bugzilla you also get the nice advantage that you
will be able to monitor patches and discussion relating to the feature
and add your own comments, and you'll be notified when the fix goes
in.

Certainly a number of these comments would be useful in bugzilla.

>   * Toolkit should recognize traditional "-g WxH+X+Y" commandline
>     arguments.

gtk_window_parse_geometry(). Toolkit can't do more than that for you,
as Paul points out.

>   * It would be very handy to be able to somehow specify the
>     width of a TextEntry widget in terms of displayed characters
>     instead of pixels.

gtk_entry_set_width_chars()
 
>   * Scrollbars and scales desperately need a way for callbacks to
>     differentiate a scroll-in-progress from a scroll-completed type
>     event.  I would suggest a "value-done" signal to supplement
>     the "value" event.  (Example: a cad program that takes a long
>     time to rebuild the display.  I want to scroll it without
>     rebuilding while the user manipulates the scroll bar, and then
>     do the rebuild when the user releases the mouse.)

gtk_range_set_update_policy() is the intended feature here, though it
doesn't handle the case you mention.

>   * It would be nice to add a scale factor option to sliders and
>     scrollbars so that a large mouse motion results in a small
>     change in slider position (very useful feature when dealing
>     with very small sliders.  See
> 
> 	http://www.efalk.org/Widgets/#slider
> 
>     for an example of one I wrote for the X intrinsics many years
>     ago.

Wouldn't it make more sense for the slider to autocompute the scale
factor depending on its size and range and step increment?

>   * It would be nice for TextEntry widgets to have signals which
>     indicate that the widget has received/lost keyboard focus.
>     This is especially important when losing focus, as this is
>     a good time for the application to validate and/or reformat
>     the input.

There are focus_in_event and focus_out_event signals that do this as
Paul pointed out.

>   * It would be nice to have an option for TextEntry widgets to
>     select their contents when gaining focus (although this could
>     be done manually given a focus-received signal.)

GtkEntry does this by default now - now the usual request is to have
an option to disable it. ;-) We may have made it a user option, I
don't remember.

>   * I found the toolkit's habit of highlighting the widget under the
>     cursor rather than highlighting the widget with keyboard focus
>     to be confusing.

I don't think it's "rather than", there are two separate kinds of
indication - focus outline and prelight.

This is in some sense entirely a function of the theme (a theme can
disable or modify how either thing is displayed).

>   * It would be a nice feature to add "focus follows mouse" to the
>     keyboard focus mechanism.  That is, moving the mouse from widget
>     to widget would change the focus without needing to click on
>     the new widget.  The tab keys would still change the focus as
>     before.  (I implemented this in my XawM toolkit, see
>     http://www.efalk.org/Widgets/#xawm)

Hrm, I think you'll find little enthusiasm for that... no modern
toolkit does this.

>   * Buttons should provide visual feedback when activated from keyboard
>     (i.e. button-pressed on key down, button-released on key up.)

GTK 2 has this feature.

>   * It would be nice to be able to expand/collapse tree widgets with
>     the +/- keys.

I believe GtkTreeView in GTK 2 has this feature. If not it has some
other keybinding for it.

>   * It would be nice if I could use my own select loop with gtk;
>     something like:
>

GLib 2 is set up to allow integration with other main loops, though
again Paul is right - it's a bit more complex than you were
hoping. ;-) GTK has more "event sources" than just the X event queue.
 
Havoc