On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> 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 ;-)
:)
> It's a Qt2 port, it doesn't require KDE2. Most distributions have Qt2, even
> if they are based on KDE1.
True, but then you lose the KDE2 added bonuses. I'm sure *you* are aware
of that :)
I'm not averse to a pure-Qt port, but personally I'm not interested in
it ...
> I don't believe you can use any of the code for KDE 1.1. It's simply too
> different.
OK, I will bow to your far greater knowledge here. I admit I still don't
know what to do about KDE2 ...
> 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?
now I know you must be trolling ... at least pick an analogy that has some
bearing on the situation :)
> 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.
I believe this is mostly due to lack of time of the developers. I know
personally I have very little time to spend on LyX ... and I am just a
serf compared to Allan etc.
> But it's even more effort in terms of development hours than doing two
> forks and let one use Gtk and one Qt.
Yes you are right. It is more effort than two ports. That is obvious. BUT
forking it like this means that they get left behind. Inevitably the
mainstream LyX will end up with nice features that one or both of the
forks don't have. No-one has enough time to sync up constantly like this.
Been there done that with klyx - in the end you moved onto other things,
no-one had time to keep up with lyx mainline...
> In practice, it simply will be a low common denominator. Maybe not the
> lowest, but pretty low.
we will see, in the fullness of time maybe you will be proven right. I
hope not.
> 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.
I'm aware of this. Have you ever tried running a KDE app under gnome or
vice versa with 40Mb of memory ? Maybe you aren't bothered, but I still
care about those users (maybe because I am one). And you exaggerate the
inter-operability between KDE and Gnome. To pick an example, the component
architectures are still not inter-operable AFAIK. You can bring up further
examples much better than I could I am sure. To pretend that a
Qt-targetted program is exactly equivalent to a Gnome-targetted one seems
blatantly untrue to me.
> 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. ...)
It is a trade-off of course, like all design decisions.
> A killer application like LyX is more than enough of a reason to install a
> couple of libraries.
As I've said above, I can live with the Qt2 target. But that doesn't
detract from the advantage of having the choice ...
> 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).
I can't even *comment* on it - I wasn't around. This has bugger all to do
with LyX today (especially as Qt is GPLed now - trolltech really do rock
for doing that :)
> 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.
>
I suspect you are including the previous branch that was abandoned. Once
again, that is something others would have to comment on, I wasn't around.
In general I have found the simple ports from xforms->kde have been fairly
quick. Refinement is a bigger job, that wouldn't changed under your
proposed cut-and-slash port.
> 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.
Who suggested the different ports would "look and feel more or less
exactly the same" ? Not me.
> 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.
>
This is *not* true at all. As I know you know, Mozilla had to implement an
entire xp toolkit solution. We have nothing of the sort - we make use of
exactly what is available. I cannot understand you making this claim when
you must know it is not even remotely true ...
> Believe me or not, I'm thinking in LyX' interest here, not KDE's.
Sorry Matthias for implying otherwise.
> IMO you picked the worst possible choice. By trying to make everybody happy,
> you make nobody happy.
Really you should be arguing with Lars, Allan and crew here ...
> 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?
A seductive argument indeed. Personally I wouldn't have minded it - I use
KDE after all ! But I would feel very sorry for all those who wouldn't
have access to such a great "killerapplikation" as a result (yes, you can
use KDE apps under a Gnome desktop, I know - but in reality the chosen
affiliation makes a big difference to who uses it).
> 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).
OK. It has been very interesting talking with one of my heroes ;)
thanks
john
--
"If one tells the truth, one is sure, sooner or later, to be found out."
- Oscar Wilde
