On Mon, 26 Oct 1998, Carl Ollivier-Gooch wrote:
> As one who worked on the read-only buffer protection for 0.12, I have a
> warning: We should be careful about using commands directly from the
> toolbar. Currently, read-only buffer protection is provided centrally by
> Dispatch.
Each (gui-indep) popup currently maintains a record of whether the popup
is modified or not (for de/activating Ok and Apply) or if the buffer is
readonly (in which case the entire popup apart from Cancel is
deactivated). This is all controlled through the updateBufferDependent
signal in Popups which is activated on a buffer switch or a change of
readonly status.
I've said from the beginning of the gui-indep work that I think we can
treat toolbars as another form of popup. So it should be just as easy to
maintain the readonly handling specific to a given toolbar in the toolbar
frontend implementation as it is for other popups.
Also Asger's desire to have the character toolbar updated on a
per-character basis (so the bold/italic/noun etc buttons are updated as
the cursor moves through text) is best handled this way since it is
consistent with the existing handling of the table popup for example.
(Popups::updateTableCell or something like that)
> Calling functions directly from the toolbar would force us to
> distribute this protection to every function that can possibly be
> attached to a button. Depending on exactly how the kernel turns out,
> this might be easy or very, very painful.
This is one way (the hard way IMO). If instead we use the method above we
get a much simpler situation. If the buffer is readonly we'll already
have disabled the toolbar buttons so there won't be any dispatching.
++++++
The above comments don't preclude the use of Asger's suggested
toolbaritem's it instead specifies how the kernel sees toolbars (it
doesn't it just sees a popup (an alternate implementation of a popup)) and
how readonly buffers are handled (the same way the equivalent dialog would
have).
Remember, most toolbars are simply a dialog that uses pixmap buttons and
tooltips instead of buttons with the tooltip as the label. They are just
a popup in a different format so they should be handled like a popup.
That will give help ensure LyX stays independent of the GUI frontends
which may or may not use toolbars at all or only implement a few. There
is no reason why a given implementation couldn't support both a toolbar
and popup for the same thing (eg. table toolbar and popup) through the
one interface. Lets not force toolbars to be handled separately by LyX
because there is no need to.
Allan. (ARRae)
