>>>>> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
Marko> The problem is whether menus and toolbars should have their own
Marko> means to track the state of LyX actions or there should be some
Marko> general way to inform about the change of the status to all
Marko> interested parties. At present, we have to check the status of
Marko> each lyxfunc used in the menus and toolbars during update. I
Marko> think that this leads to duplicated code and to unnecessary CPU
Marko> load.
Do you have evidence that the calls to LyXFunc::getStatus() have a
high cost? I think that having checks all over LyX code (Oh, we just
changed the font! let's tell the menu about that) would have a high
readability cost on the kernel code. Of course, if a profiler shows
that getStatus is very expensive...
Also, what kind of duplicated code are you thinking about? My first
idea when designing this code was to have an abstract interface for
the different frontends (with add() calls and things like that), but
Asger somehow convinced me that with some GUI toolkits it is not
possible to add an entries to a menu one by one (now I believe he was
just drunk, but the code is written).
Marko> Every time when some state is
Marko> changed this machine will notify all GUI elements (menu,
Marko> toolbar, status bar, programs connected through lyxserver)
Anyway, you will have to scan the menu to see what element is
interested in bold setting, won't you?
Marko> distributing a signal to all interested parties with exact
Marko> description of the change (for example, title of section 3.1 is
Marko> changed).
I guess you are interested in this one for the TOC menu. I admit that
having the TOC menu in a tearable menu (and unfortunately many people
will want to do that) will be a big problems (exactly for the same
reason why the TOC popup does not refresh automatically). What I'd do
for now is have an "update" entry on top of TOC menu entries, like for
the TOC popup. It is a bit ugly, but it should work...
JMarc
