Hi! These are very good news, Archit
Selon Archit Baweja <[EMAIL PROTECTED]>: > Hi > > Paolo Borelli <[EMAIL PROTECTED]> 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, _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
