>>>>> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> In parenthesis, we should add that this has been accomplished
Asger> by defining a minimum feature set: We cut out the dynamic part
Asger> of the menus that existed previously (i.e. LinuxDoc adaption),
Asger> and focused on a core menu abstraction that would cover the
Asger> basic needs. This was a wise decision giving that we aim for
Asger> GUII.
Nope. We have several things the provide dynamic menus:
- function are greyed out when unavailable (and have the relevant
checkboxes when necessary)
- there is a special type of item called OptItem which will not appear
in the menus when not available (Build Program only appears for
literate programming documents)
- the menus for import/export are generated automatically by the
backend, depending on what is available for a given document.
Asger> But it only demonstrates what Matthias already said: We are
Asger> closer to the lowest common standard, rather than closer to the
Asger> possible standard. For instance, there is no functionality to
Asger> handle dynamic menus, in the sense of menus that adapt to the
Asger> state of the program. For instance, when you work on a DocBook
Asger> document, it should reduce the menus to only the relevant
Asger> options. (Or at least minimally, disable the non-relevant
Asger> ones).
It's been a long time since you last took a look at the menus.
Asger> Also, you do not have the infrastructure to handle changing
Asger> toolbars on the fly.
Having the infrastructure would be easy. The most difficult part is
probably to implement that in the xforms frontend.
I won't comment on MVC, since it's been something I'm very fuzzy
about.
JMarc
