Hi Allan,
I wanted to answer earlier, just didnt get to it.
I 've seen that you checked in some stuff for the big GUI independence
hack, good. Let's see that I can scrap some time to help with this now.
First, you were correct, that I hadn't read all about the LyXfunc discussion
in the mailing list archive. Now with your explanations though I think I've got
a rough idea how things are supposed to be.
> I agree 100%, this is a step by step process. I'll try to summarize what the
> necessary steps are her emostly for my own understanding.
> 1. Take a popup, e.g. paragraphs, find the code in the exisiting code
> base that creates, updates and deletes this dialog and create a
> form_paragraphs.[Ch] pair of files, then move the existing code.
> Compile and see whether is all still works.
Or something that might be easier:
cp lyx/src/frontends/xforms/form_paragraph.[Ch]
As you are removing the old implementation merge in any changes
and tidy it all up.
There are quite some changes so we'll see how much this actually works, but yes
you are in principle right of course.
s/Dialog/LyXDialogBase/ or s/Dialog/DialogBase/
There are no create or destroy signals. If a dialog hasn't been shown
before it will be created just-in-time. Similarly, the hide could be
used to delete[] the dialog. In any case, the destructor should clean up
anything that may have been created.
See other thread on this. I think we may need a ModalDialogBase for the modal
dialogs but that can be decided as we go.
Grep is your friend but so is any other cross-referencer.
Isnt there an etags goal in the makefiles?
[...]
All it needs is the addition of the appropriate entries. This is mainly
the common bits of code that can accept or return data and perform some
action with it. Getting the current paragraphs parameters is one
possibility.
LyXFunc is the API. Anyone writing a script can access anything that
LyXFunc has to offer. So its essential that we ensure that both the
scripts and the GUI/TUI frontend and the LyX internals can all use it and
that it has a sensible, clean collection of functions.
Ok, I'll have to look closer into this. I dont understand how this will be
usable for scripting yet but I cant imagine how passing strings is the most
convenient method for interaction to the GUI frontend, all these conversion from
and too integers floats etc... Well as I said I may understand this better when
I actually see it.
> So with this three steps one dialog is encapsulated. The slots can be
> called from the menu or by means of the cursor moving to a new
> paragraph.
or by keyboard shortcut, or minibuffer command or even a LyXServer request
from some exterenal program/script and for some popups there is also the
likelihood of calls from inside the LyX core or other lyxfuncs.
They all call a LyXFunc. The LyXFunc consists of:
case LFUN_LAYOUT_PARAGRAPH:
owner->getPopups.showParagraph();
break;
(taken straight from the lyx/src/lyxfunc.C:1081-1083)
well, yes, except that you'll have to call a slot of the appropriate DialogBase
class, yet you havent passed any parameters to the dialog, I guess I havent
understood yet. The dialogs will have to explicitely access data from the kernel
on their own.
Reread the paragraph and example above. We have at least six different
ways of getting stuff to happen in LyX. At least three are likely to
want answers or to push data into the system (kernel, ui and lyxserver).
On the GUI side it's not a push (and shouldnt be) it is the GUI polling info
from the kernel, yes, when writing back it could be a push...
more OT in private email.
Thanks
Roland
