> I'm not sure what we gain with that. The problems which exist in some
> architectures (e.g. how do you update a dynamic menu when it is teared off)
> will continue to exist anyway. If you find a good solution for a
> frontend, I am sure it will work with the current scheme.
The only problem of dynamic menus/toolbars is the way they are supposed to
handle the changes in LyXFunc values. I think that the same problem will
show up much worser in server-client architecture (or client will have to
ask for the complete status update after any change of the document which
may hang your machine/network ...). This problem has been discussed
earlier and it has been demonstrated that it is relatively easy to resolve
this problem using signals that are emitted if some function state/value
changes. I guess that this mechanism has to be implemented anyway to allow
LyX to display dynamic content in any GUI.
[...]
> Concerning toolbars, I have the following scheme in mind:
>
> 1/ give name to toolbars and have several of them (like menus): "main"
> "math" "table". In fact it may be possible to use the same backend for
> toolbar and menus, although I am not sure what the advantage will be.
>
> 2/ In the code, add some showToolbar("math")/hideToolbar("math")
>
> 3/ Let the front end do what it wants with it :)
Actually, the current implementation of menus may be utilized to implement
toolbars. We had a discussion on this topic before and I've even submitted
a screenshot of lyx gnome frontend with the toolbar corresponding to main
menu :).
Marko
