Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "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.
I really think that this code has nothing to do in the "backend", imho
it is part of the frontend, if it is directly in the tk code or in the
common frontend code does not concern me as much.
| 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]
Let's imagine a lyx-server-only port. Why should the ToolbarBackend be
present there?
| 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 :)
I have no problems with this or the current code, but I have a feeling
it is in the wrong location.
| 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...)?
No, this is not my concern.
Lgb
