[Glade-devel] Glade Menu Editor for Glade3

[e98cuenc free fr (e98cuenc free fr)]

Hi!

These are very good news, Archit

Selon Archit Baweja <bighead users sourceforge net>:

> Hi
>
> Paolo Borelli <pborelli katamail com> writes:
> > > If you two are done fixing you last major patches, I could consider
> glade-3
> > > 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
> > changes.
>
> Yes but I would like to branch at a stage when the rest of the code is
> stable.
> Like I said, I don't want to bump into bugs (atleast not eh trivial ones),
> on
> 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)
>
> Yup

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
> glade_widget_class_new_from_node).

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

or

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.

Cheers,