[Glade-devel] Glade Menu Editor for Glade3
- From: e98cuenc free fr (e98cuenc free fr)
- Subject: [Glade-devel] Glade Menu Editor for Glade3
- Date: Mon, 25 Aug 2003 14:28:37 +0200
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,
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]