Allan mistakenly mailed this to me only.
I reproduce his interesting mail here (trimmed a few quotations).
My comments are below
----------
> From: Allan Rae <[EMAIL PROTECTED]>
> To: Asger Alstrup Nielsen <[EMAIL PROTECTED]>
> Subject: Re: CVS update: lyx/src/frontends/qt
> Date: 22. oktober 1998 06:22
>
> On Wed, 21 Oct 1998, Asger Alstrup Nielsen wrote:
>
> > I suppose it's just a question of linking to both toolkits? Then, it
> > should simply be a matter of specifying the correct order to the
linker.
> > Also, the "GUI_runtime" function should probably dispatch messages to
both
> > toolkits.
>
> Well yes and no.
>
> Multitoolkits can be done this way easily. But I was concerned about
what
> happens if someone wants to open a popup that hasn't been ported to that
> toolkit yet but has been ported for XForms. I think now that I was
> probably a little too worried because I had been wanting to have all
> popups all the time irrespective of how far a given port had progressed.
>
> Instead we should just have a stub popup that says something like:
>
> "Not ported to BlahBlah Toolkit yet :-("
>
> Given this, the parallel toolkit thing is quite simply a matter of
> maintaining the respective Makefile.am's to reflect which dialogs have
> been ported for each and ensuring the stub popup above is used for all
> those not ported yet.
>
> Hmmm... while writing this email I've run around a circles and come to a
> simple realisation.
>
> Each new port *must* start by porting the LyXView (and its associated
> components). ^^^^^^
>
> Then the new port will be able to be used and developed independent of
the
> xforms stuff. Initially no dialogs will work (stub popup as described
> above) and eventually all the popups will be implemented. This is the
> opposite to how I was going to do the KDE port but it makes more sense
> this way. It also means we can't start new ports until the XForms
> independence is complete.
>
> The Qt/XForms stuff I had before let xforms handle nearly everything and
> only the bare minimum required to get Qt dialogs displayed was done for
> the GUI_init equivalent. If we start each new port with the LyXView and
> no dialogs we don't need mutlitoolkit support. However, if we really
want
> to have all dialogs available at all stages of a new port we again run
> into the difficulties described in the ramble at the end of this email.
>
> > Ahh, I'm sorry, but it's probably more like 10 dialogs. The good news
is
> > that it used to be like 25 dialogs, but after the painter-job, we've
come
> > a long way.
>
> I was trying to be optimistic and thereby lull someone into thinking
they
> might attempt it. It seems Lars fell into my trap ;-)
>
> > We still need to transform all messages into signals, and
> > clean up the last bits.
>
> Which messages? the stuff with painter? to support the workarea?
>
>
> ****** the following is a ramble that eventually led me to the gui port
> ****** realisation I've included it because I didn't want to just dump
> ****** it and because it contains a few ideas/problems that still might
> ****** be useful or worth considering. Note that it is assuming we're
> ****** wanting to have all dialogs all the time.
>
> The trouble will come when porting to new toolkits once all the xforms
> stuff is shifted. This is the "luxury" I mentioned. Once shifted this
> simple plan above won't work. Instead we need to somehow control which
> dialog implementation is linked in based on the configure options (eg.
> --with-kde). So if only 4 dialogs are done for kde and all (including
> LyXView) are done for xforms we need to force the 4 kde popups to
replace
> the 4 equivalents from xforms. How do we do this?
>
> Remember this is getting even trickier because the kde implementations
are
> actually in a different subdirectory. That's why I suggested the
"develop
> in xforms and commit in kde" strategy. In fact this might be the
simplest
> way to support new ports since we have Popups.C in each ports
> subdirectory. Of course the new port wouldn't be very usable and would
> require that all ports used the same names for their header files and
> classes.
>
> The gui independence scheme works brilliantly once a port is done but
its
> a bitch doing a new port. I don't really see anyway around that unless
> JMarc or someone else can come up with a brilliant scheme using the
> Makefiles to control which implementation is used based on a configure
> option.
>
> ****end of ramble****
>
> Allan (ARRae).
----
I understand the problem, and have considered it myself. However, the
benefit of doing a multi-toolkit port are worth it, IMO. This approach
allows us to do this stuff in an incremental manner, and this have a
working LyX.
I haven't given this idea much thought, but instead of having the stubs,
what if the Qt port simply pretended that all the XForms dialogs were
Qt-dialogs? I.e. let the Qt port use the XForms code as a slave?
Ok, that is the general idea. How to realize this? I don't know right
now.
Regarding the signals for the LyXView (and more importantly for the
work-area) I mentioned: We need to encapsulate keypressed, mouse-clicks
and motions in the work-area to something GUI independent.
Greets,
Asger
