>>>>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>> I agree that this may have drawbacks, but I have not found them
>> yet. Could you be a bit more constructive?
Juergen> Did you see the messages about the problems with the new menu
Juergen> code and other implementations (GNOME)? While in xforms the
Juergen> whole menu strukture is regenerated when you click on a menu
Juergen> this is not done in GNOME. Also it seem really strange to me
Juergen> that the menu is recreated in the Menu-Callback, should this
Juergen> be done in an update call?
I agree that the GUI-I menus should have an update call. However, on
xforms which does not have tearable menus, creating the menus on menu
callback is the simplest thing to do (and the update() call should be
a no-op). This does not mean that other implementation should do the
same!
I do not have time to add myself this update() call now, but this
should be done and is fairly easy.
Juergen> With the above problem this opt menus ONLY work if you really
Juergen> recreate the menu on the fly every time it is selected!
Let's face it: if you want to a tearable menu to change when the
cursor moves you will have to do _something_. What I would try to do
if I were to write the gnome frontend is first to build the menus at
update() time and see whether it causes performance problems. If it is
the case (and it might be), I would create the menus in set(), cache
the status of each lyxfunc used and, at update() time, change the
state of the entries of the existing menu (like for the toolbar) on a
case by case basis. For OptItems, one would have to insert/delete
entries in the existing menu (which should be possible). And with a
bit of double buffering, this should work well enough.
I do not think that this is a problem with the scheme in itself. We
_do_ want the menus to change and the work has to be done anyway.
JMarc
