Re: Gtk feature requests

[Paul Davis <pbd Op Net>]

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

which window is that for? think about it.

>  * 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.)

this would be very valuable. XForms has a nice model, where you can
specify the behaviour on a per-widget basis: report value when
changed, report value when motion pauses (but before mouse release),
report value every N msecs, report value when mouse is
released). adding "value_change_complete" or "value_done" or whatever
would allow widgets to support some or all of these models.

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

you can write this yourself. my DAW application "ardour" has
non-linear logarithmically scaled sliders. i've also written
GTK+ widgets that have distance-log-scaled motion scaling, wherein
mouse motion a long way from the widget
(e.g. click-drag-right-now-drag-up-and-down) causes less change in the
adjustment value than similar motion close to the widget.

>  * It would be nice for TextEntry widgets to have signals which
>    indicate that the widget has received/lost keyboard focus.

focus_in_event
focus_out_event

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

catch enter_notify_event and leave_notify_event and stop the
emission. this will prevent prelighting. i wish there was a way to
turn off prelighting on a global basis, but it appears to contradict
the desire of GTK+'s designers for a consistent GUI experience.

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

you can write this yourself. catch the key_press_event signal and
handle it.

>  * It would be nice if I could use my own select loop with gtk;
>    something like:
>
>	gtkfd = gtk_get_connection_id() ;
>		:
>	select(nfds, &readfds, ...))
>		:
>	if( FD_ISSET(gtkfd, &readfds) )
>	{
>	  while( GtkPeekEvent() )
>	    GtkDispatchEvent() ;
>	}

GTK uses glib, and its inner loop is a bit more complex than
this. What you can do is to add your own fd's to its inner loop. There
have been several posts here in the last month about this, and many in
the archives, as well as information in the tutorial and reference
docs. see gtk_input_add() and its more generic cousins g_source_add().

in the current "pending release" version of glib, the inner loop has
been restructured to allow some decomposition into something like you
describe, but i don't think it was with the idea of moving the outer
while() into your code. glib's handling of what it terms "sources" is
much more generic than select() would necessarily allow for (though
under a POSIX system, select() is more or less all we have, since
other types of signalling systems like semaphores can't be waited for
with select).

--p