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.
 
> 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...

I've already grabbed it.

> At first, we were quite dissapointed that the abstraction still was far from 
> being complete. But even if you got it finished one day in the future, the 
> result will be 4 different versions (XForms, Qt, KDE, Gtk) that all basically 
> are the same. So what's the point in porting then, if you cannot follow the 
> respective standards of the target platform? Or phrased differentely: What's 
> the point in providing a Qt port, if the abstraction doesn't make it possible 
> for me to use certain Qt features that could make the port significantly 
> better than the other ones?

If the abstraction restricts a frontend, then the abstraction needs
re-working. This seems very obvious to me, to the extent that the above
sounds like a troll ...
 
> - In KDE2, we use complex configuration dialogs with an icon list on the left 
> rather than a set of dialogs. I attached a small screenshot to illustrate 
> that.

and there's no good reason at all that the LyX config can't be done this
way. If the abstraction proves troublesome, it will be re-worked. Of
course you are the expert, so if you believe this is impossible, I would
be interested to know why.
 
> - In a Qt application, mathed would never be a dialog window, but a special 
> toolbar instead (like we did it in KLyX).

I intend to do exactly the same. If the abstraction isn't flexible enough,
it will be made so. A nice maths toolbar is the #1 missing feature from
LyX today, bar none.

> - In KDE2, users can rearrange the menu structure of an application with a 
> standarized dialog.
> - Qt has a very nifty scrollview abstraction that doesn't need double 
> buffering and thus can safe resources and even provide more speed compared to 
> the LyX implementation.
> - Qt3 will come with a neat docking architecture. Exploring its possibilities 
> for the design of a text processor GUI is an interesting task.
> 
> The LyX GUI abstraction doesn't allow me to do any of these things. It's a 
> classic least-common-denominator approach. I even have to treat Qt like a C 
> toolkit because that's what the abstraction expects.
> 
> It would be quite a big improvement, if only the drawing area was abstracted 
> and the ports could provide their own main window implementations, including 
> toolbars, menubars and docking windows. This would make it at least possible 
> to provide ports that follow the platform specific style guides more closely.

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.

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.

> 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].

> 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
wrong with giving users the choice, and I think tying LyX down
(needlessly) to one particular toolkit implementation is a bad idea. For a
start, the fact we have three frontends has helped considerably in
thinking about the interface. What is there is nowhere near perfect, but
several good ideas have come about (e.g. Marko's action area) that are a
direct result of what Lars calls "frontend competition".

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.

regards,
john

[1] I suppose I should point out I have always used KDE and KDE2 ...

-- 
"If one tells the truth, one is sure, sooner or later, to be found out."
        - Oscar Wilde


Reply via email to