On Tue, 27 Oct 1998, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
[...]
> 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.
What global flag? Global within the scope of the popup or toolbars
implementation?
If a toolbar is visible it should be attached to the
Popups::updateBufferDependent signal if that's appropriate. Then when
this signal is activated (on buffer switch or readonly-toggle) the
toolbars update() method would call the various query functions
(advocated in a different email) to decide whether a given toolbar button
should be greyed out or not. The toolbar implementation doesn't know
what's affected until it makes the query.
If you want custom toolbars (user-defined ones) then we could have a
vector<ToolBar> in the implementation with one signal in the Popups header
enum CustomTBSelect {PREV, CURRENT, NEXT};
Signal1<CustomTBSelect> showCustomToolbar;
Thus we could have multiple user defined toolbars that are shown one at a
time and the user can flip through them. Or with a slightly different
approach we could let users name their different custom toolbars and offer
a menu choice for which toolbar they want (like AmiPro-3.01 did/does).
All this can still be done through the Popups interface.
> 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.
So update() will be asking the query function if its available and if not
greying it out or, if you prefer, anything not available could be left
out completely.
> 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.
The user defined toolbars might be filled separately but why treat a table
toolbar or a character-attribute toolbar (such as offered in KLyX) as a
special case? These toolbars are essentially replacements for the popups.
Even a dynamically filled toolbar should be able to be handled by Popups
interface as I've tried to describe above. (Oh for a piece of paper, a
pencil and 5 minutes. Then there wouldn't be a problem.)
The Communicator could have a method to retrieve the custom-toolbar
settings (or you could go directly to the toolbar backend) and then the
frontend builds up the toolbar/s from this.
The Popups::showCustomToolbar signal can be activated by a couple of
LyXFunc's (one each for next, previous and current).
I still don't see a need for special case handling of toolbars within LyX
(sure a custom toolbar will be a bit fancier in the frontend than a popup
but it doesn't require special treatment by LyX)
Allan. (ARRae)
