On Thu, 8 Feb 2001, Allan Rae wrote:
> 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...
We can also use dialogs interface for menubar too. The only difference
which I see in current implementation of dialogs VS menubar is that
menubar is user-configurable and dialogs are hard-coded. I guess, we would
like to keep the user settings for toolbars too. If we treat toolbars
and menubars as dialogs then the only parameter which is required to build
these objects is menubar or toolbar name defined in .lyxrc files. This
name can be passed by InsetCommand, if I am not missing something.
[...]
> > 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.
Even better.
> > > 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).
There is another silly example when this signal is needed --- one might
have TOC in the toolbar with chapters showing up as a buttons. I am not
sure who would like to have this feature, but the point is that kernel
has no idea how the lists are presented to the user (dialog, menu,
toolbar, or just written to the serial port). In the case of TOC written
to the serial port we even don't have any "Refresh" button to press or the
frontend will have to take care for processing input from serial console
too.
Marko
