Re: Gtk feature requests

[Edward A Falk <falconer falconer best vwh net>]

> >  * Toolkit should recognize traditional "-g WxH+X+Y" commandline
> >    arguments.
>
> which window is that for? think about it.

First window, or even all top-level windows.  It would still be more
useful than not being able to specify at all.

Face it, most applications start with one initial window.  Throwing
away a useful feature because it's ambiguous (note: ambiguous, not
broken) in the general case is silly.


> >  * It would be nice to add a scale factor option to sliders and
>
> you can write this yourself. ...

Yes, but it's a fair bit of work, the way how is non-obvious (I didn't
even know it was possible until I read your post), and most app
writers won't even think to do it.

In the slider widget I wrote for Xt, input scaling was simply set
through a resource, and by default was automatic for sliders less
than 100 pixels long.

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

Doh!  Didn't think to look at the signals in the super-classes.
Thanks; I have a lot of code to re-write now.


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

I was thinking of the general case.  The prelighting should reflect
the keyboard focus, not the mouse position.  The user *knows* where
the mouse is.


> >  * It would be nice if I could use my own select loop with gtk;
>
> GTK uses glib, and its inner loop is a bit more complex than
> this.

I was afraid of that.  I've been able to use gtk_input_add(), but
in my years of programming experience, I've learned that there
are always cases that the API designer didn't think of.  Someday,
an application will come up that needs to react to events that
are not file input events or signals, and then what?



Anyway, thanks for your comments.

	-ed falk