Friday 17 November 2000 18:06 wrote John Levon:
> On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> > sorry for not sending this email ealier. Mandrake is innocent
>
> OK
>
> > During the KOffice Meeting after the Linux Tag two months ago,
> > [...]
> > Unfortunatly, neither he nor me had the time to finish the things we
> > planned. Too many things happened with KDE and we simply were not able to
> > come back to the LyX code. 7 weeks may sound like a lot to you, but if
> > you have an exciting job in addition, time is just fleeting.
>
> OK, so you forgot to tell us. That seems reasonable if a little slack.
Note that I didn't do anything with this code for months. Just sending a
short note "we wrote something, do something with it or leave it", isn't
sufficient. It was clear to me that I will have to spend some time arguing
with you people at least ;-)
>
> > I'm not sure whether the code is useful to you the way it is, just take
> > it.
>
> I can at least use some of the code for the KDE 1.1 stuff. KDE 2 will come
> later when the majority of people have it on their desktops...
It's a Qt2 port, it doesn't require KDE2. Most distributions have Qt2, even
if they are based on KDE1.
I don't believe you can use any of the code for KDE 1.1. It's simply too
different.
>
> I've already grabbed it.
>
[snip]
>
> So your argument seems to be :
>
> Because the current GUI-I code is limited in some ways, and certainly not
> yet complete (especially in terms of the main window), we should abandon
> it all together and restrict LyX to one toolkit.
Of course. Restricting LyX to one toolkit is not a restriction in terms of
software engineering, but a design decision that leads to more flexibility -
and thus to faster and more innovative software development. What is more
restricted, a computer program that uses either C or Pascal, or one that
tries to support both languages from the same codebase, with the help of
certain macros and some preprocessing?
>
> I don't buy it, sorry. The sensible thing to do is to extend and continue
> to improve the GUI-I separation. I don't believe this will lead to "lowest
> common denominator" implementations.
>
> It is a pity Allan is away at the moment (I think), I'm sure he will have
> some insightful comments here.
John, wake up! See how long you guys have been working on that and see how
far you came until now. Of course what you describe *can* be done. But it's
even more effort in terms of development hours than doing two forks and let
one use Gtk and one Qt. In practice, it simply will be a low common
denominator. Maybe not the lowest, but pretty low.
>
> > a far more advanced LyX integrated in KDE2
>
> You seem to have forgotten that not everybody uses KDE2. And not everyone
> *wants* to use it[1].
Sorry, that's more than lame. KDE is an application development framework.
Nobody has to run the window manager in order to run applications written
with that framework.
With this argument, we still would avoid using toolkits at all (some users
don't want to use XYZ toolkit, so better use Xlib. Ooops, some users don't
want to use X, so better use Curses. Oops, some users have broken termcaps
and cannot use Curses, better use stdout. ...)
A killer application like LyX is more than enough of a reason to install a
couple of libraries.
>
> > Think about your users and what you really want to develop, not about
> > politics.
>
> It seems to be you who is thinking about politics. I fail to see what is
You cannot argue away the fact that three years ago, the Qt port was stopped
due to purely policial reasons (read: Qt was not available under the GNU
GPL).
> wrong with giving users the choice, and I think tying LyX down
> (needlessly) to one particular toolkit implementation is a bad idea. For a
Again: see how much time you guys spent and what the outcome was. Compare
that to the two weeks it requires to make a proper port to a decent C++
framework.
And what's the point in chosing between LyX/Gtk and LyX/Qt if both look and
feel more or less exactly the same? Users don't care about particular
toolkits, they care about applications. As I tried to explain to you, you can
write an application with Qt that looks just like a Gtk+ application. Add
Gnome-compliant icons and you are basically done.
This is not about reducing the choice of the user, this is about giving the
user the choice to use a modern LyX. Today, the user cannot chose anything,
because it simply isn't finished (nor will it be anytime soon).
As I pointed out in my previous mail: Netscape had a very similar
architecture. It was a nightmare. They learned and rewrote everything. Now
they have their own binary calling convention, there own middleware, there
own toolkit, their own programming language for user interfaces and and and.
This is where you are heading with this approach - just that Mozilla.org had
a few more resources. And it still took them a lot of time.
[snip]
> I can very much understand you wanting to evangelise your project (and of
> course your commercial concerns), but I am not sure at all it is the best
> thing for LyX.
I don't have any commercial concerns. But I do have a concerns in using a
decent LyX version in the year 2000.
lyx.org isn't going to deliver that anytime soon with the approach you are
taking. This is sad. It's a very decent code base but it doesn't reach
anywhere the userbase it deserves.
Believe me or not, I'm thinking in LyX' interest here, not KDE's.
Now, if I get a statement from the LyX team that says something like "we are
not interested in providing a decent text processor anytime soon, but we want
to invest our spare time in inventing new ways of programming for different
toolkits and coming up with new abstractions", that's fine with me.
Just tell me that and I stop arguing immediately. I'll visit lyx.org in
spring 2002 then to check out the latest version.
Seriously, in the free software business, you cannot make everybody happy.
There will always be people complaining. For your best sake, you have to make
decisions. Programming language, scope, toolkit, platforms are some of those.
If you guys decided on soley supporting Gtk+, most certainly I would be
pissed. Qt is in many ways simply much better, cross platform and it fits
much better in LyX' C++ world. But for the sake of the LyX project itself,
one has to realize that Gtk+ is at least better than the xforms stuff that's
there now. And you would be able to get a release out in a halfway forseeable
timeframe.
IMO you picked the worst possible choice. By trying to make everybody happy,
you make nobody happy.
Keep in mind: a complete KDE port that replaces all the xforms stuff with
Qt/KDE code can be done in two weeks work if you have at least two people
fulltime. With the abstraction layers in there, it might be more complicated
now than it was with LyX1, but one could simply drop some of those and
replace them with the ones Qt already provides.
This is why I'm so angry about the whole issue. Can you imagine what a
powerful killerapplikation LyX would be today if you had continued working on
the KLyX code base two years ago?
Enough ranting for now. You know my opinion, I know yours. I don't understand
it and I think it's pretty bogus, but I can accept it. In case you change
your mind, I'll be happy to offer Qt and KDE support to a certain agree and
maybe even help a bit with the implementation (like for example porting
Screen to QScrollView).
Have a nice weekend. I'm not subscribed to lyx-devel, so if you want me to
follow parts of the discussion, please cc: the mails to me. Thanks.
Matthias
