> This is, as I understand it, the main problem with WxWin. The code is
> bloated: it's a library/GUI toolkit implemented *on* *top* *of* other
> toolkits, libraries, and GUI's. Nope, sorry, that's a kludge [if I'm
> even correct about their implementation]. OTOH, what LyX is doing is
> saying, "Here's what *I* need in a GUI. If there's a 1-to-1 mapping
> between <favorite toolkit here>, and what I need, great. Use it. If
> not, oh well. You'll have to write that method."
>
> Clean code is far more important. Even if WxWin is "clean," it will
> be tailored to general use. We don't care about general toolkit
> features. We have certain classes that must accomplish specific
> tasks. Why go through calls to WxWin to call Qt or GTK or XForms when
> we can cut out the middleman and call Qt or GTK or XForms directly?
After all, what we are doing is exactly bloat: Instead of one
interface to one possibly strange interface, we are having N interfaces
to N possibly strange interfaces.
I understand the critique that this will cause double work, and agree
with a few modifiers ;-)
Having multiple frontends for the same code base will leave to some kind
of selection mechanism: The least popular frontends will die over
time. (Notice the important difference to the classic Darwian phrasing:
"The best will survive.") So, yes, some code will severly risk to be
wasted work.
I see nothing wrong with this. After all, this is the same criteria
that the rest of LyX works by. We have LinuxDoc SGML export, and this
feature was resting for quite some time, because nobody was really
interested in doing it. This implied that the feature was incomplete
and buggy, and had been for quite some time. It was dying.
Then Jose stepped up and did something about it, and now LinuxDoc is
much better. It's alive again. Because somebody had an interest in
it.
The same thing will happen with the front ends. The popular ones
(in the eyes of the coders) will be the best front ends. The less
popular ones will probably be feature incomplete. Until the
moment where somebody steps up and does it. Or alternatively,
that the code rots completely and dies.
The question is whether we should do something about this or not.
My answer is: No. Anybody is allowed to do a wxWin port if they
feel like it, and can. And if it turns out to be a popular port,
it will stay alive. If not, it will die.
It is only natural that different front ends will have different
feature sets. After all, this is another point in the exercise.
The KLyX front end will support KDE hints. The GTK+ frontend
will understand GNOME hints. Etc.
The main thing we have to ensure is that every feature that is
part of the file format, is supported to some extend by the
front ends. In this regard, the main criteria is that we can
preserve the information when we load and save the file. And
this criteria is enforced by the design we have adopted: The
front ends are file format ignorant. The kernel has the sole
responsibility of handling this, so every front end *will*
support the same file format, regardless of what GUI elements
there are for a given frontend.
-
The extra cost in allowing this kind of selection is that we risk
to do double work that turns out to be wasted. However, I argue that
this will not be a problem. See, Jose is interested in LinuxDoc, and not
so much in LaTeX. If he did not work on LinuxDoc, he would probably
not work on LyX at all.
Similarly, if somebody is interested in a GTK+ port, they will do it.
However, they will probably not do a XForms frontend, because it
is not interesting to them.
Yes, we will have duplicate work. However, different people are doing
this work, and thus, we will hopefully gain more than we will loose.
In particular, I hope there is enough motivation to keep at least
these front ends alive:
XForms, because we already have it.
KLyX, based on Qt, because KDE is big.
GLyX because GNOME is big, and GTK+ is nice.
Curses, because this is a pet-project for at least Lars and I.
OS/2, if SMiyata or others have the time to do a native port.
Windows, because this platform is huge.
Maybe the setup will be different. Anybody is welcome to do a wxWin
port, and with this demonstrate that several of the front ends can
be covered with this alone. In that case, this is cool.
Similarly, one could imagine that the Netscape crossplatform library
at one point will be stable enough to build LyX upon, and this would
be cool too.
However, it could also turn out that the wxWin port is no good, and
then we would be in a bad situation: We would have tailormade LyX
into being wxWin specific (at least to a certain degree), and would
be in the same situation as we are now: Tied to a specific platform
with all the limitations this implies.
The much better approach is to open up LyX: We aim to be truly portable
by introducing an abstraction layer between the kernel and the front
ends. This is extra work, but it will help the project. Not only because
we will have better portability, but also because we will be much more
aware of the semantics of each element in the kernel. This, in turn,
will reduce the number of bugs we have.
> > 2) Portability. LyX should not be X11 only.
>
> On portability: when it comes to a bona-fide Winblows port, you'll
> have headaches. There are all sorts of loopy incompatibilities; I run
> into them at work.
I know (I write Windows software for a living.) But LyX is a relatively
simple application when it comes to the requirements from the GUI. We
need buttons, drop-down lists, scrollbars and a few other common elements.
And these work pretty well in Windows, so I don't anticipate much more
problems that we have had with XForms. (If you compare with Qt or GTK+,
yes, the Win port will be give more headaches, but once again: If it is
interesting enough for somebody with the skills, these guys will have the
headaches, while the rest of the team will be happy. The cost of the
windows cost is beared alone by the ones doing it.)
Greets,
Asger
