Asger Alstrup Nielsen wrote:
>
> Allan mistakenly mailed this to me only.
> I reproduce his interesting mail here (trimmed a few quotations).
Thanks Asger.
[really big snip]
> 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.
I do.
The answer is so simple we missed it!
You provided the answer in your reply and didn't realise it!
As you point out "use the XForms code as a slave".
We already have a Popups.h to handle gui independence.
What we need is the same sort of thing but for each partial port.
What we can do is have a second header file that is only used by the
KDE port (say KDEpopups.h) which is the equivalent of Popups.h but
hides the XForms stuff from the KDE port. KDEpopups.C will be in
the xforms directory -- this looks confusing but its called KDEpopups
because it the xforms popups used by the KDE port, we'd have a QTpopups
for the Qt port and so on.
The idea is that KDEpopups might start out with all the xforms
dialogs and as kde dialogs are implemented the xforms dialogs are
removed from KDEpopups. So over time KDEpopups gets smaller and
smaller until we eventually remove it. KDEpopups could also arguably
be used to access the xforms LyXView implementation to get all the
dialogs ported and then worry about the LyXView later.
Now when we "./configure --with-kde" the Makefiles in frontends/xforms
and frontends/kde must be set up so that the Popups.C in kde is used
and the appropriate files from xforms are compiled and linked. The
kde/Popups.C will use a KDEpopups instance to access the xforms popups.
The simplest way to do this is to use a separate target in the
Makefiles. We could assign target "all: kde" in the makefiles when
compiling "with-kde" and have separate SUBSYS_o_SOURCES lists.
Others will probably have a better idea of what to do here.
A problem shared is a problem solved (not quite yet but close),
Allan. (ARRae)
