Lars, I send this to you as I'm not on qt-devel. Can you please forward it to the appropriate mailing list? Thanks. Matthias > ---------- Forwarded Message ---------- > Subject: Re: Mandrake and KDe frontend > Date: 16 Nov 2000 21:17:59 +0100 > From: [EMAIL PROTECTED] (Lars Gullik Bjønnes) > To: John Levon <[EMAIL PROTECTED]> > > John Levon <[EMAIL PROTECTED]> writes: > | Do you know about this ? Mandrake are working on a KDE2 frontend. > | > | Proof : > | > | http://us.mandrakesoft.com/cgi-bin/cvsweb.cgi/klyx2/src/frontends/qt2/ > | > | I'm very unhappy indeed that they haven't even bothered telling me/us. > | e.g. they've implemented FormDocument for KDE ! > | > | thank god it is friday tomorrow > > Actually I was aware of this, but did not plan to raise hell > until I saw that they actually worked on it: "Age 7 weeks" > > I really hope that they will communicate a bit better than first time > the port to kde was done. > > Lgb > --------------------------------------------------- Dear LyXers, sorry for not sending this email ealier. Mandrake is innocent, here's the whole story. During the KOffice Meeting after the Linux Tag two months ago, Kalle had the idea to do another port of LyX to Qt2; this time using the GUI abstraction you guys have been working on for the last years. So he and me looked at the stuff that was there and he spent two days constructing the dialogs with Qt Designer and connecting some of the dialogs to the backend. The plan was for him and me to spend a few more days after the meeting on the code, compile a detailed document with our experience when using the abstraction and to release it to you guys. In fact, I wrote a long email, gave it to Kalle for review, then somehow the meeting was over and the mail was left somewhere on a harddisk of the university of Erlangen - probably deleted by now. 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. I'm not sure whether the code is useful to you the way it is, just take it. If you have a potential maintainer for it, great. So far so good. The other reason why I probably hesitated to send this email was, that I wasn't happy it all with what I saw. To me, the whole GUI abstraction thing looks like a huge effort with very little outcome. 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? Some examples: - 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. - In a Qt application, mathed would never be a dialog window, but a special toolbar instead (like we did it in KLyX).r - 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. I really would love the LyX team to rest a little while and recall, why Qt was rejected in the first place, when Lars started to work on a Qt 1.2 port. Remember that it was the first decision the LyX team did, that wasn't technically motivated. If Lars followed his intuition and continued with the work he started, we now had a far more advanced LyX integrated in KDE2 that was fully under the GPL. It would simply be the standard way to write letters and longer reports on Linux. And what do we have now? A great tool for those scientists that are not scared to death by XForms. Sarcasm aside. Think about all the time you guys spent doing exactly the same what Netscape did before the rewrote everything from scratch. Great things were done in the LyX kernel, but the user interface fall more and more behind the rising standards on Linux. I believe we demonstrated clearly enough with KLyX1 that a complete port to Qt was and still is possible in a few weeks. I want to drop URLs to LyX-files onto my running LyX and it should download the stuff from the web. Every application can do this, why not LyX? So why not take this chance? You guys also want a Gnome version? That's great. But why does this require having a Gtk+ port? These days, Qt supports both the native Gtk+ style and even Gtk pixmap themes. Borland announced a few days ago, that Kylix will also support Gnome as desktop environment and the Gnome Founcation applauded. This support will not be based on Gtk+, but on Qt. OpenOffice will also become a real Gnome application - using Star's inhouse cross-platform toolkit rathern than Gtk+. Toolkit != Desktop. Supporting Gnome as a desktop is a matter of following the GUI styleguide, reading the proper desktop settings, using special icons. Things like window manager hints, DnD protocols, Mimetype handling etc. are already standardized between both desktops. On the Look'n'feel side, the possibilities for common theme definitions are explored. Think about your users and what you really want to develop, not about politics. As a nifty side effect, a Qt port also offers the possibility for a native MS-Windows version (soon also Macintosh). If some of you want to work on that, I'm sure my company can provide you with the necessary number of Qt licenses for MS-Windows. Matthias
