>>>>> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:

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> Rather than the pseudo-action, I propose that we simply use the
Asger> command.  This will make the stuff for the drop-down list
Asger> simpler.

What do you have in mind for the drop-down list? Calling a LyXfunc
with the current string as argument? We could also pass a number, I
don't know what's best.

Asger> We don't need several kinds of buttons in the sense that a
Asger> toggle- button is a general version of an ordinary button.
Asger> However, by having a separate class for toggle-buttons, the
Asger> logic for this stuff is separated to exist in only this class.
Asger> And then, all toggle-button will be defined with two strings
Asger> that denote the name of a lyx funcs: One to invoke the action
Asger> to set the flag, and another to read the setting.

All buttons should have a way to read settings: we want to gray out
some icons when the document is read-only, for example.

Asger> Similarly for the drop-list: This will get a string that
Asger> contains the name of the lyx-func to invoke when the user
Asger> selects some element from the list, and then two vectors of
Asger> strings, of the same length.  The first string contains the
Asger> names to use in the GUI, and the second contains the strings to
Asger> use as the parameter when the lyx-func is invoked.

It seems that passing an index in the list is simpler. The rest can be
handled by the kernel.

Asger> The reason I wanted to design a small toolbar-item hierarchy,
Asger> was to make this abstract virtual class as small as possible.
Asger> But do as you like.  We can always judge whether we need to do
Asger> more later.

OK, I'm not sure when I will do it though, as my paersonal todo list
is a bit overcrowded currently...

JMarc

Reply via email to