Re: GtkBuilder status



Johan Dahlin wrote:

[snip]
There should be only one obvious way of doing a specific task.
GtkUIManager is the currently the obvious way of creating menus and
toolbars


Here you go, python programmer in action :)

Seriously speaking, GtkUIManager is not and may not be perfect. The
single fact that it doesn't know that
an action may need data in addition to callback may make it very hard to
use. While it's stupid to use
glade-built menus in an application which does require merging ui, it's
just overkill to use GtkUIManager
in simple applications that have more than one window: I want a callback
to be executed with the toplevel
window as an argument, and I can do it in glade; but to do it in
GtkUIManager I have to break my head
or arms or write custom GtkAction subclass, or use g_object_set_data,,
all in *code*, not in glade. And then,
there is GtkToggleAction, GtkRadioAction, I need to create the actions
themselves, all just because I can't
make a simple menu in glade. It doesn't sound right.

It'll be fairly easy to add support for this in the signal tag,
so you can specify the data argument. It would require two attributes
one for the data and one for the type, then you'd do:

<signal name="activated" handler="quit_cb" data="window1"
       data-type="GObject"/>

void quit_cb (GtkAction *action, GtkWindow *window);
No sir, I don't want that action there! I want
void my_cb (GtkWidget *window). It will be fairly easy
to use connect_swapped, of source.

I never claimed GtkUIManager was perfect. I just said it was the obvious way
of creating menus and toolbars. It might be overkill in smaller
applications, but if they use gtkbuilder they won't even notice.
Well, I personally don't care about what's inside as long as I am not
forced to know that. If everything will work just like as it did before
(namely the "connect this callback to this menu item"), then it's
perfectly fine.

Yevgen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]