On 11 Sep 2000, Jean-Marc Lasgouttes wrote:
> >>>>> "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...
You are right, LyXFunc::getStatus() is not expencive. I've tried to move
cursor through the document and took almost the same amount of time to
reach the end of the document regardless to whether I updated the menus
or not. However, it is interesting to note that CVS version of LyX is
consederably slower than LyX 1.1.5 (compiler options are different?).
> Also, what kind of duplicated code are you thinking about?
Since toolbars and menus are almost the same, I have to implement status
tracking for both of them. For example, toolbar may contain TOC too.
> 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?
No. I can connect using
.connect( bind<int>(slot(this,&Menu...::update),item_index))
In this case, no scan is needed.
> 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...
I think we can come up with a better solution. I'll try to build up the
service which will notify interested elements on the change of the state
of Lists (TOC, LOA, List of the documents, etc.). The update() method of
this service should be called only during an "idle" state of LyX when LyX
is entering this state (where can I insert such kind of idle processing in
LyX?). Such service will help us to remove Refresh button in TOC popup
too.
Marko
