>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I have been thinking of moving _all_ toolbar/menu stuff into the
Lars> GUI and have _no_ backend support. This will allow the Tk to use
Lars> whatever method/scheme it sees at the best for its implementaion
Lars> of toolbars and menus.
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.
What are the limitations that you see with the current setting? Is it
just that you don't like it? [I agree it should use signals instead of
the current ugly pimpl]
I do not think the scheme limits what implementations can do.
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 :)
Is the problem just that you want to be able to edit/store menus and
toolbar using the native tools of the toolkit? Are we sure that these
tools are expressive enough to handle our needs (export lists,
enabled/disabled items according to what lyxfunc says...)?
JMarc
