John I've answered your original post at the end.
On Tue, 22 Feb 2000, Roland Krause wrote:
> After that, someone will probably have to make a real concept for
> LyXFunc, i.e. events from the document view, menu, toolbar, and GUI
> initialization as well as other things that I dont understand yet.
Menu and toolbar abstractions exist in the archived lyx repository. There
is still more work to do though.
> Try to check out the rae-2 branch and look in frontends. There are
> DialogBase.[Ch] and Dialogs.[Ch] pair of files. Alan put the header
> files in frontends/include. Personally I think that is not necessary
> since this is C++ and the header are part of the implementation and
> should be with the implementation.
The two header files are shared across multiple implementations. This
revised scheme allows each frontend to use whatever names they like for
their classes and files -- hopefully ones more in keeping with the
platform/toolkit they are using.
> Anyway. I started moving the Paragraph stuff so pick something else.
John, if you want to get up to speed you might like to get the archived
lyx repository where a lot of the gui-indep work was previously done.
Compare the details in the gui-indep doc with what was happening in that
source code. Concentrate on src/frontends/xforms once you recognize the
pattern take a look at the rae branch and see how the new scheme works.
They are very similar but the new scheme is a lot cleaner.
cvs co lyx
cvs co -r rae -d rae_lyx_devel lyx-devel
> On Tue, 22 Feb 2000, John Levon wrote:
> > It seems the devel web page is sort of out of date...
It's just that we archived all the previous work and are doing it all
again in a more stable environment -- the last development series crashed
so often we decided it'd be quicker to start again. The gui-indep dialogs
didn't cause any of the crashes though :)
I haven't gotten around to updating the gui-indep doc. However most of
the discussion in it is still relevent.
> > What work is currently being done on GUI independence ? I understand
> > major changes to the core code have made this easier, but the frontends
> > directory is empty and the lyx-devel module on CVS doesn't seem to have
> > any abstraction from xforms (sorry, I hate xforms) ...
cvs co -r rae -d rae_lyx_devel lyx-devel
> > Has this got beyond the high-level stuff in Asger's (out of date ?) paper
> > on devel web page ?
Yes. About 75% of the dialogs had been cleared out in the archived lyx
repository. As I said above we are now looking at improving on that
design and then (possibly|hopefully) back-porting the older work or
redoing it all from scratch.
The discussion about why we are doing it is still relevent and some of
details are still true. However the method of communicating from the
frontends (GUI, TUI, LyXServer or even CLI) will be different this time
around. We're also using libsigc++ instead of now defunct gtk--
signal/slot system.
> > I would definitely be interested in helping out with this as it's the only
> > thing I don't like about LyX :)
Your assistance would be greatly appreciated. If you've any questions or
comments I'd be glad to hear them. (I might be a bit slow in answering
though).
> > Oh and another thing : you are using ghostscript for the figure insets,
> > yes ? Well how difficult would it be to embed gs output for the whole
> > document inside a LyXView ? That would be v. nice as you could just
> > add "Preview mode" which can be updated in much the same way as it is
> > currently, except there's no clutter with separate windows ...
It could be done but I don't know that anyone is excited enough to take on
the job (except perhaps you). Besides gv offers several extra
capabilities we don't (like one-click zoom). I'm not in favour but that
doesn't mean you shouldn't try.
> > sorry if all this is FAQ but the devel web page is a little sketchy :)
Hopefully it'll be updated before the work is completed ;-)
Allan. (ARRae)
