>>>>> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> There are general toolbar actions:
Asger> o Define a toolbar with these buttons. o Display this toolbar.
Asger> o Do not display this toolbar.
Asger> and there is a generic toolbar item action:
Asger> o Modify this button (for font attributes, and paragraph
Asger> environment)
And a way to disable the button when the action is not available.
Asger> On the other hand, the front end has to tell LyX when the
Asger> toolbar is used:
Asger> o This button is pressed.
Asger> This last bit can be solved using signals. However, we can
Asger> also just use the simpler solution: When we define the toolbar,
Asger> we also define which LyXFunc to trigger when the button is
Asger> pressed. I.e. this action question is a property of each
Asger> individual button.
This is what we have now, and I see indeed no reason to change
that. Each button has a pseudoaction attached.
Asger> o An ordinary button o A toggle button for things like font
Asger> attributes o A drop-down list, as for paragraph environments o
Asger> A separator
I am not sure that we need several kind of buttons (ordinary or
toggle). We should rather extend LyXFunc to be able to return the
status of a pseudo action, i.e. disable, toggled on or toggled
off. This info could then be used by the toolbar (and also by a menu
object when we have one).
Asger> So, the overall idea is something like this (I chose to use an
Asger> OO hierarchy. Each front end will derive and implement the
Asger> abstract toolbar class. This decision was decided, because it
Asger> seems to be the simplest solution):
Ah. Here is the answer to my question. It seems to me that this
abstract class stuff will force us to use virtual methods (the
overhead is not that large) and to know which kind of toolbar we need
when instanciating it. Fine.
JMarc
