>>>>> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I knew you wouldn't do this, so I have to bring out some
Asger> heavier ammo: The menus and toolbars. These, you are beginning
Asger> to tackle, but you haven't quite yet.
The current communication model is broken, but the infrastructure is
in place.
Asger> - You want your framework to be flexible enough to have fully
Asger> dynamic menus and toolbars that are configurable at runtime
Menus and toolbars are read at startup already. It would be better to
change them on the fly, but this should be doable.
Asger> - You want to handle tooltips
We have an infrastructure for that in LyXFunc, and xforms uses that.
Asger> - You want to handle icons
You mean icons for menus? The frontend is free to query for an icon
corresponding to the action and display it.
Asger> - You want the menus and toolbars to come and go according to
Asger> different events, such as entering a math inset or a table
The menus already change when there is no document, and some entries
disappear when they are not relevant.
Asger> - You have to handle special menus, such as the live TOC, the
Asger> documents and recently used files items, and so on
This is handled by the backend, except for TOC and Refs. Refs is
planned to go away, and I think TOC can be done at the backend level.
Asger> - You want to handle keyboard short-cuts. (You have had a big
Asger> discussion on how this should work, but it's hard even to agree
Asger> on how it should work.)
What do you mean?
Asger> The canvas is without doubt the most complex GUI component in
Asger> LyX. It is highly dynamic, has complicated communication both
Asger> ways, and it has to be *damned* fast. And did I mention that it
Asger> has to be stateless, because obviously we want sevearal views
Asger> in different frames?
It would probably make sense to implement a canvas in each frontend
and have that be the heart of the application, which calls the other
parts.
JMarc
