Re: Gtk feature requests



> 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]