[Glade-devel] Glade Menu Editor for Glade3


These are very good news, Archit

Selon Archit Baweja <bighead users sourceforge net>:


Paolo Borelli <pborelli katamail com> writes:

If you two are done fixing you last major patches, I could consider
reasonably stable to branch (again, if indeed its needed).

I'm not very familiar with branches, but I think that if you decide to
branch to work on the menu editor you can do it whenever you want: since
it's a self contained piece of code, it should not be affected by other

Yes but I would like to branch at a stage when the rest of the code is
Like I said, I don't want to bump into bugs (atleast not eh trivial ones),
my way to fixing the Menu Editor.

I think that you can keep working on HEAD.  The code seems stable to me, even 
if there is still a bit of clean up to do on glade-widget-class.c (obviously 
the _new_from_name2 was a temporary name...), it should not affect the 
stability of the code.

I don't have the intention to change the catalog format, so I will not 
introduce any incompatibilities that may hurt your work in this point.

All in all, I don't think that it's worth the pain to have a separate branch.

While I'm at it let me write some random thoughts/questions/ideas about
the menu editor:

I was going to send a similar followup email too :D

* It seems to me that in gtk-2.4 the menu widget has been completely
overhowled, with the integration of the menu stuff that was in egg. Does
this affect the menu editor? (I think that when gtk2.4 comes out we
should start supporting its new widgets, and probably at some point
switch completely to 2.4 as a requirement)

IIRC its the toolbar not the menubar. Again I have to confirm this.

There is also a menubar (some points of its implementation are still being 
discussed on gtk-devel right now).  I don't think that it affects too much the 
menu editor, but it will certainly affect how we construct the real menu once 
the user has specified the entries.

* Sometimes ago there was some discussion about changing the way
accelerators for the menu entries work; in particular may be worth
trying to get rid of the key selection dialog and investigate if the
accelerator stuff in libegg fits our needs (you can see it working in
GnomeTerminal keyboard shortcuts editor)


As somebody said, the current IU is like looking back to gnome 1.x, so there 
is definitively room for improvement.  One thing that may be done better is 
just grabbing the accelerator instead of selecting it from a list.

* We must remember that the menu editor is also used for the optionmenu
widget and not only for the menubar. This is probably related to find a
way to specify the "Edit menu" button in the xml file of the widget
class instead of the hack we have now. (Note that this is not strictly
related to the menu editor code itself and may interact/conflict with
Joaquin changes to the catalogs)

I think a simple "can_have_menus" or something simlar xml property would
be all that would be required (and subsquent changes to

At first, I was thinking on having the whole menu editor on glade-gtk, as 
everything that goes beyong the simple "editing by properties" should be on 
glade-gtk, but this special case (the menu editor) is a bit too heavy to put 
it on glade-gtk...

If we'll have a flag to say "that widget class has a menu editor" we either:

1) figure out how to map the whole menu to the specific widget class, and put 
this info on glade-gtk


2) leave the hack that puts the edit menu button on the properties window as 
it is.

There is no point on removing the special case for GtkMenu on glade-editor and 
still having it on glade-menu-editor.


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