Re: LyX (was: My impression of .8)

[Paul Seelig <pseelig mail uni-mainz de>]

jam@sorman.se writes:

[ GNOME version of LyX ]
> Anyone with some more current information?
> 
I'll simply forward these two messages from the lyx-devel mailing list
to show what the general notion seems to be.  In any case it would be
nice if interested parties would subscribe to lyx-devel and start a
fruitful dialog with the core developers by providing actual code.
They simply can't do it all on their own and welcome everyone willing
to seriously contribute.

The first one:

-------- snip -------------
|From: Jean-Marc.Lasgouttes@inria.fr (Jean-Marc Lasgouttes)
|Subject: Re: toolkit agnosticism
|Message-ID: <199902121015.LAA21714@fantomas.inria.fr>
|Date: 12 Feb 99 10:15:13 GMT
|References: <XFMail.990211124412.rokrau@pocus.wustl.edu>
|Reply-To: Jean-Marc.Lasgouttes@inria.fr
[ header slightly edited for brevity ]
|
|>>>>> "Roland" == Roland Krause <rokrau@pocus.wustl.edu> writes:
|
|Roland> All Wxwin ports are native, so speed is not an issue, afaict.
|Roland> Code bloat is something you will get anyway, either it's your
|Roland> own code that is becoming bloatet, which means the maintenance
|Roland> problem is on you, or it is the toolkit code thats bloatet,
|Roland> then the problem is on the toolkit developers.  
|
|Another point is that what KDE and/or Gnome need is not a Qt/Gtk
|application, but a full blown K/G application. And they want to be
|able to use whichever nifty widget their library provides. I'm not
|sure WxWindows provides that.
|
|However, the core LyX developpers will probably not do all these
|ports. This means that the choice of toolkit will also depend from the
|people willing to do it.
|
|And last, there a re plan for a curses frontend. I doubt that
|wxwindows provides this one.
|
|JMarc
-------- snip -------------

The second one:

-------- snip -------------
|From: alstrup@diku.dk (Asger K. Alstrup Nielsen)
|Subject: Re: toolkit agnosticism
|Message-ID: <199902151036.LAA04316@tyr.diku.dk>
|Date: 15 Feb 99 10:36:15 GMT
|References: <19990214194825.A1384@idsi.net>
[ header slightly edited for brevity ]
|
|> 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
-------- snip -------------