> I began moving code around for the toolbar, in order to make a
> tk-independant heder, and then it occured to me that I did not know
> what I was doing :)
>
> So how shoudl I do that? I see several options:
> Any thought appreciated.
To decide this question, we need to see what we want to support, and then
make the design. I'll try to do that right now in the twenty minutes I
have before I have to attend math class.
Conceptually, we need these methods from the back end (extended compared
to what we have already, because we want to support context toolbars, like
a math toolbar when editing math, and we also want to let the toolbar
buttons be pushed/not pushed according to states, cf. the font attributes.
At the same time, we want to generalize the drop-down lists to be useful
with other stuff that the paragraph environment).
There are general toolbar actions:
o Define a toolbar with these buttons.
o Display this toolbar.
o Do not display this toolbar.
and there is a generic toolbar item action:
o Modify this button (for font attributes, and paragraph environment)
On the other hand, the front end has to tell LyX when the toolbar is used:
o This button is pressed.
This last bit can be solved using signals. However, we can also just use
the simpler solution: When we define the toolbar, we also define which
LyXFunc to trigger when the button is pressed. I.e. this action question
is a property of each individual button.
Then the question of how the front ends to interface with the kernel is
solved: Through the LyXFunc of the LyXView associated with the toolbar.
Since the toolbar is composed of different items, we need to define what
items we have, and how each look. As far as I can see, we need four
kinds:
o An ordinary button
o A toggle button for things like font attributes
o A drop-down list, as for paragraph environments
o A separator
The two first have a graphic icon attached.
The drop-down list has a list of string attached (no pun intended).
Each item can possibly be invoked.
So, the overall idea is something like this (I chose to use an OO
hierarchy. Each front end will derive and implement the abstract toolbar
class. This decision was decided, because it seems to be the simplest
solution):
// Abstract class
class toolbar {
public:
toobar(LyXView *);
vector<toolbaritem> items;
}
// Abstract class for the different kinds of items
class toolbaritem {
public:
toolbaritem();
// Will return the string needed to execute this item
// as sent to the lyxfunc.
LString invoke();
LString tooltip();
}
Notice that the toolbaritem class is back end. The front-ends only need
to implement the toolbar class, because the toolbaritem class is generic.
Sorry, I'm out of time, but I hope you get the general idea. Just ask
questions where things are not clear, and I'll try to elaborate.
Greets,
Asger
