>>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> So I must update every dynamic menu/toolbar item on every
John> update(). OK, I suppose that's not too bad. But what is it
John> you're actually informing the frontend of ? It seems that the
John> current examples are just about buffer switches/opens/closes.
John> Why not call them bufferOpened(), etc. ? Why the vague
John> "update()" ?
It might be: "the cursor moved, maybe you should update the checkboxes
for font settings" or anything. In fact it is called when LyX waits
for input, so maybe nothing intresting happened, but I believe the
computational cost is small. Now, I do not think that we should add
checks and signals all over the kernel code to cover all possibilities.
John> How would your method cope with a number of different toolbars
John> for different things ? Do you call update() on each one ? Why
John> not just let the frontend decide what needs updating - why not
John> just tell it what changed ?
What I envision is enhancing the toolbar code to have several named
toolbars, like current menus. Then add methods show/hide for named
toolbars. The toolbars would have generic names like "math",
"tabular", etc. A dumb implementation like xforms could chose to
ignore these calls. Better ones would do the right thing.
John> it still makes for ugly parsing code whilst reading the menus
John> in. maybe it would still be ugly, perhaps you're right here ...
What parsing code? Where?
John> But the frontend doesn't deal in functions. It deals in GUI
John> objects, which may have the ability to Dispatch() when operated.
John> How can the kernel code possibility cater for the differences
John> between the xforms and the KDE frontend, when say, a maths area
John> is entered by the cursor ?
What action do you have in mind besides poping a toolbar?
John> if need be we can have different default.ui files if you still
John> think the kernel code should be the master of the frontends in
John> the manner you describe
I thin kthe menu/toolbar frontends should be as dumb as possible and
should not have too much LyX-related trickery. If you have a nice idea
about what your frontend could do which is not covered by the
interface, then it seems reasonable to implement this feature in GUI-I
fashion so that other implemtations can do it too. I believe that
menu/toolbar stuff is simple enough for that to be possible.
John> Of course, and that's the killer problem in your scheme - you
John> can't know about the differences between the frontends in the
John> kernel code ! You may be able to alter Edit->Table, but you
John> forgot the Table dialog, and the table toolbar - hold on,
John> they're not in this GUI - etc.
The kernel calls methods to enable/disable them, and the frontend is
free to ignore them.
John> I don't see how you could do this in a nice way, without
John> essentially implementing my suggested scheme :
John> Signal0<void> enteredTableArea;
toolbar->show("tabular");
>> _except_ for the TOC case, which deserves a special treatment with
>> some signals. This is another reason why I want to remove the refs
>> stuff, which is the other special case.
John> but they are not the only special cases: essentially everything
John> is a special case.
Could you elaborate? I agree that the xforms code is ugly. But this is
mostly because there is no reasonable menubar/toolbar objects in
xforms. I believe that writing a frontend for KDE equivalent to the
xforms one will be trivial. The real problem is probably in the extra
functionality you want. Could list the kind of nice things you want to do?
I understand that, as a frontend writer, you feel that you will be
restrained in what you can do because there is a common architecture
you are bound to. However, I really think that it is possible to build
such an architecture which will be good enough to allow all this
customization to be done by the _user_. And to me, allowing the user
to decide what his interface will do is much better than allowing the
implementor to play nice tricks (as long as we can provide enough
customisability in GUI-I fashion).
Actually, there are things that I do not really know how to handle in
toolbars:
- combox: currently, there is only one possible combox, the layout
combox. Will we need more of them, and which ones?
- math toolbar: the math panel provides bmtables. How is that
implemented in KLyX? I do not know how to descibe this in a
reasonable way.
Also, in menus, there is the problem of updating intelligently the
TOC (because it could cost time to do it too often). However this
problem would also arise if you had complete control on the menus. A
solution has to be devised, maybe with signals.
Finally, my main problem is that I do not have time to work on this
right now, so if I cannot convince you to work from the current
scheme, I'll have to give up :(
JMarc
