Still to read the full thread but skimming a couple I can add these
comments:
On Wed, 7 Feb 2001, Marko Vendelin wrote:
[...]
> > 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.
Or toolbar and dialogs as I keep saying...
> 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.
and only emit the appropriate signal which can be shared between different
implementations of the same thing...
> [...]
> > 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.
You all seem to have missed the fact that tables already have an update
signal for the dialog and that triggers changes in the dialog when the
cursor moves around the cells. A table toolbar is just a different form
of this dialog and so there is no point in adding a toolbar specific
signal when the table dialog one already exists. That's part of the
reason why I keep trying to get you blokes to see that toolbars are just
the same as dialogs. They are built differently [initialisation] but they
look the same to the kernel and can share the same signals.
> > >> _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)?
Why all lists? If a figure inset is changed then an LOF-signal could be
sent and so on.
> > 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.
I still think this should be triggered by the frontend -- sure I know the
tear-off menu arguement and there is probably a need for a specific signal
for that but you should only need to update the TOC when it's accessed.
A torn-off menu however would want to be updated by a signal (since it
would look like the existing TOC dialog).
Allan. (ARRae)
