> 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.
And the solution is simple: Use an extra lyxfunc. Each button will
have two different lyxfunc attached:
One to call when the action is triggered.
Another to call to check whether the button is active.
Then, the toolbar wil also feature a "refresh" action which will make
sure that every button is up-to-date.
I.e. if you choose to create a toolbar-item-hierarchy, the class could
be like:
class ToolbarItem {
///
ToolbarItem(LString setfunc, LString queryfunc,
LString tooltip, LString shortcutkey);
/// Returns the string to use to invoke the action
LString invoke();
/// Is this button active? (This uses the queryfunc to
/// query the kernel)
bool active();
}
It also makes sense to buoild such a hierarchy of items, because
we can reuse them in the menus: Just introduce a menu-item, and
we have a general facility.
> 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.
I agree.
Greets,
Asger
