>>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> 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.
Yes, but the toolbar uses dispatch anyway.
Allan> Each (gui-indep) popup currently maintains a record of whether
Allan> the popup is modified or not (for de/activating Ok and Apply)
Allan> or if the buffer is readonly (in which case the entire popup
Allan> apart from Cancel is deactivated). This is all controlled
Allan> through the updateBufferDependent signal in Popups which is
Allan> activated on a buffer switch or a change of readonly status.
Allan> I've said from the beginning of the gui-indep work that I think
Allan> we can treat toolbars as another form of popup. So it should
Allan> be just as easy to maintain the readonly handling specific to a
Allan> given toolbar in the toolbar frontend implementation as it is
Allan> for other popups.
Well, I'd rather think of the toolbars like menus: basically
(forgetting combox, etc) they hold a collection of pairs icon/lyxfunc
(or text/lyxfunc for menus). Having a global flag for readonly does
not make sense if the toolbar does not know whether a function is
affected by this flag. Likewise, a 'view PS' lyxfunc should be made
unavailable if there is no ps viewer. Currently, this is done by hand
in the menu code but, if we want a real menu class, this info will
have to be obtained from LyXFunc.
Allan> Lets not force toolbars to be handled
Allan> separately by LyX because there is no need to.
There is a big difference: a popup is hardcoded in LyX, and it has a
good knowledge of what it does (e.g. it can disable some parts which
are not permitted). A toolbar is dynamically filled (at runtime) with
icons/functions, and thus should have a generic mechanism to get its
info.
JMarc
