Hi!
On 7 Feb 2001, Jean-Marc Lasgouttes wrote:
> >>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
> John> So I must update every dynamic menu/toolbar item on every
> John> update(). OK, I suppose that's not too bad. But what is it
> John> you're actually informing the frontend of ? It seems that the
> John> current examples are just about buffer switches/opens/closes.
> John> Why not call them bufferOpened(), etc. ? Why the vague
> John> "update()" ?
>
> It might be: "the cursor moved, maybe you should update the checkboxes
> for font settings" or anything. In fact it is called when LyX waits
> for input, so maybe nothing intresting happened, but I believe the
> computational cost is small. Now, I do not think that we should add
> checks and signals all over the kernel code to cover all possibilities.
This is the way it is implemented in Gnome frontend. As far as I can
see the overhead is indeed minimal. However, I haven't profiled it...
> John> How would your method cope with a number of different toolbars
> John> for different things ? Do you call update() on each one ? Why
> John> not just let the frontend decide what needs updating - why not
> John> just tell it what changed ?
>
> What I envision is enhancing the toolbar code to have several named
> toolbars, like current menus. Then add methods show/hide for named
> toolbars. The toolbars would have generic names like "math",
> "tabular", etc. A dumb implementation like xforms could chose to
> ignore these calls. Better ones would do the right thing.
Another possibility is to use exactly the same interface for toolbar and
menubar. Then the set of toolbars will be presented by first level
submenus, buttons in the toolbars --- by commands in submenus, and
comboboxen by sub-submenus. Easy and as configurable as menubars
are. Kernel will just call toolbar->update() and menubar->update() and
there will be only one toolbar object to call by the kernel.
[...]
> John> I don't see how you could do this in a nice way, without
> John> essentially implementing my suggested scheme :
>
> John> Signal0<void> enteredTableArea;
>
> toolbar->show("tabular");
do you really want to see flashing toolbars depending on where you are in
the document? I think that usually people fix the toolbars and these
toolbars don't change much. I might be wrong --- there are no toolbars in
my gnu emacs at all.
> >> _except_ for the TOC case, which deserves a special treatment with
> >> some signals. This is another reason why I want to remove the refs
> >> stuff, which is the other special case.
Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?
[...]
> Actually, there are things that I do not really know how to handle in
> toolbars:
>
> - combox: currently, there is only one possible combox, the layout
> combox. Will we need more of them, and which ones?
You might want to have any command in the combox (emphasize, \Large, TOC,
style). This is easy to implement using menu structure.
> Also, in menus, there is the problem of updating intelligently the
> TOC (because it could cost time to do it too often). However this
> problem would also arise if you had complete control on the menus. A
> solution has to be devised, maybe with signals.
Signal would be nice.
Marko
