Re: [gtk-list] My experiences with GTK - what I would like changed...

[Elliot Lee <sopwith redhat com>]

On 1 Jun 1998, GTK.Mailinglist.account wrote:

> - - The GTK+ seems to follow a "click-to-focus" strategy even if the
> window manager (and hence all other applications)

(I don't follow that last connection - applications are entirely free to
set the focus on widgets according to toolkit policies, not by what the wm
does. wm focus mode only affects focus among toplevels).

> follow a "focus-follows-mouse" one. This is kinda annoying, because I
> need to click on a button, leave the window again (because otherwise it
> won't acknowledge the focus)

Do you have your wm set in ClickToFocus mode and it is not passing through
the first click?

It's just that I'm not understanding this "leave the window again" part -
I know I can just click on a button and it does the action, whether or not
that window is in focus.

> and then I can use the button. I think this is the biggest flaw of GTK
> "feel-wise". 

Only problem with FocusFollowsMouse is that it forces you to use the mouse
more or less. I prefer to have the keyboard be giving the authoritative
commands, and the mouse filling in when the keyboard doesn't fit the bill.

It would be nice, though, if this were user-settable. I'm not sure how it
would be implemented - perhaps you know a little about this...?

> - - What about giving the programmer the possibility to attach own data
> structures to Widgets ? I'd like a function set like
> 
> void gtk_widget_submit_userdata(Widget* widget, gpointer* data);
> void gtk_widget_delete_userdata(Widget* widget, gint number);
> gpointer* gtk_widget_retrieve_userdata(Widget* widget, gint number);
> 
> This could easily by done by a GList, I guess... and it would make
> object oriented programming even easier.

It's already in there! :) Read gtkobject.h, especially the section about
set_*data and get_*data routines.

> - - The last big thing I have been looking and couldn't find was a
> signal handler where I can have a routine being called when a child
> dies or sends any other signal. I know I could probably do that by
> directly using the systems handlers, but it would be much better to
> only have GTK managing this kind of stuff.

Adding a gtk layer on top of signals wouldn't give any advantage that I
can think of - there really isn't very much to sigaction.

-- Elliot
When I die, I want to die peacefully in my sleep like my grandfather...
	...not yelling and screaming like the people in the back of the
	   plane he was flying.