Re: GtkBuilder status

Johan Dahlin wrote:

o My real concern is about supporting menus and toolbars built by
   - Is the motivation here only a "time-to-market" thing ?
   - If so, do you have any plan or stratagy to take baby-steps and
eventually get
     all the ui building code into the IBuildable ?
   From what I've seen, the IBuildable architechture provides exactly
what is needed to
   generate menus and toolbars directly, and more powerfully than the
   (does UIManager allow you to set properties on every object in its
heirarchy individually ?
   ... can you refer to an object in the UIManager from the rest of the
glade file ? for a
   random example: Say I want the mnemonic widget on a label somewhere
in the UI to be
   a GtkToolItem).
   Ofcourse I'm not saying that UIManager is bad, its provided some
convenient apis to build
   complex menus and get all that GtkAction stuff in order, but now
that we are introducing a
   complete builder into gtk+, it should be time for UIManager to die.
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.

If you have any problems with GtkUIManager itself, start a dialog about
that, but it's a separate discussion unrelated to this.
It's, err, wrong to claim that another piece of soft is perfect, and make this piece of soft "perfect assuming that's perfect", and say "is that's not perfect, complain about it, but this piece of soft will still assume that piece of soft is perfect".
Are we living in ideal world yet?


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