Re: Gtk feature requests
- From: Edward A Falk <falconer falconer best vwh net>
- Cc: gtk-list gnome org
- Subject: Re: Gtk feature requests
- Date: Mon, 25 Feb 2002 21:07:07 +0000 (GMT)
> Both features and bug reports should go in bugzilla -
Thanks, didn't know about bugzilla.
> 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().
Thanx; missed that one in the docs.  Better than nothing.
> >   * 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()
Also thanx.  This one not my copy of the docs.  I need to get an
updated set.  Or was this new with gtk 2?
Wait, never mind.  I see it's new with gtk 2.  Excellent.
> >   * Scrollbars and scales desperately need a way for callbacks to
> >     differentiate a scroll-in-progress from a scroll-completed type
>
> gtk_range_set_update_policy() is the intended feature here, though it
> doesn't handle the case you mention.
Right.  I know how to specify events under each policy, but there's
no way to collect *both* kinds of events and differentiate them.  I've
already written two different CAD applications that need to know
the difference.
> >   * 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
>
> Wouldn't it make more sense for the slider to autocompute the scale
> factor depending on its size and range and step increment?
The slider I wrote does exactly that by default.  If AutoScale is true,
then scaling is set appropriate to the size of the slider.  Otherwise,
the application may manually set a scale factor.
> >   * It would be a nice feature to add "focus follows mouse" to the
>
> Hrm, I think you'll find little enthusiasm for that... no modern
> toolkit does this.
I know.  I was re-writing the old Xaw toolkit to support keyboard
traversal, and I had to face the issue that some users would object
to changing the paradigm.  So I added a user-setable flag to choose
the focus model.  Then I realized that the two models aren't
incompatible and set the default behavior to use both.  It really
works quite well.
	-ed falk
[
Date Prev][
Date Next]   [
Thread Prev][
Thread Next]   
[
Thread Index]
[
Date Index]
[
Author Index]