| |||||||||||
Qt, the GPL, Business and Freedom (OfB)Qt, the GPL, Business and Freedom (OfB)Posted Aug 9, 2005 18:20 UTC (Tue) by ajross (subscriber, #4563)In reply to: Qt, the GPL, Business and Freedom (OfB) by farnz Parent article: Qt, the GPL, Business and Freedom (OfB) And as expected, we're now in full-on flame mode. Just to clear up some of the inevitable misstatements: KDE, as of yet, has implemented neither Arthur nor Cairo, as it is still based on Qt 3.x and therefore Xlib. Qt 4, the first release to include the Arthur technology, just shipped. Gtk+ 2.8, the first release to include a Cairo rendering backend, is suppoed to ship "RSN" (the most recent release date target was about a week ago). To my reading, this would put Arthur and Cairo at roughly the same level of maturity and stability, plus or minus a week or two. It's not at all clear to me that the trolls (not KDE -- AFAIK the decision to develop Arthur was not made by the KDE team at all) made their decision based on stability. It seems more likely that it was based on a perceived feature need in the Qt toolkit and release schedule. So the decision (to fork from the X.org rendering API) seems to have been made on the basis of Trolltech's marketing needs, and not KDE's goals. Add this to the fact that Cairo is a somewhat more capable API (Qt4 lacks arbitrary path-based stroking and filling) and the Trolltech decision seems to me to be counter to the interestes of the KDE project.
(Log in to post comments)
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 18:31 UTC (Tue) by farnz (subscriber, #17727) [Link] Cairo is not the X.org rendering API. That's RENDER (see X.org. Cairo is one API built on top of RENDER, and Arthur is another. Why is it so bad that there's two competing APIs?
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 19:37 UTC (Tue) by ajross (subscriber, #4563) [Link] > Cairo is not the X.org rendering API. That's RENDER
I really should just stop, but the flames keep getting louder than the facts:
Neither Cairo nor RENDER are "official" in any real sense. The render extension is a comparatively low-level X protocol thing designed to expose the underlying graphics hardware's capabilities in a general (Porter-Duff compositing) way.
Cairo is a vector graphics API in the tradition of Postscript and PDF. It happens to have a RENDER extension backend, just as it has an OpenGL backend, or an Xlib one, etc... My saying it was "the" X.org rendering API was unfortunately imprecise, and I guess I should apologise. Nonetheless it seems clear to me that the original intent of the library was for eventual use as the "standard" drawing API for X windows GUI toolkits, just as DisplayPostscript was standard for NeXTStep, or Quartz for OS/X, etc... Please browse through the papers on cairographics.org -- it's really quite interesting and exciting.
Unfortunately (getting back to my point) the Cairo API looks like it is not going to be available to KDE applications. Instead, Trolltech has decided to implement a similar but somewhat inferior API in Qt4. I think this is a bad thing for KDE. It means, among other things, that a unified theme engine with Gtk (something that many people, including especially linux distributors, want badly) is going to be more difficult because the toolkits don't share the same rendering API.
That's all I'm trying to say: KDE is, obviously, constrained by Trolltech's architectural decisions with their Qt product, and these decisions are not always in (what I perceive to be) the best interests of the Linux desktop. The cairo thing is one example. There were others higher up in the thread. I just think that perhaps the KDE team should be looking at this situation more critically than they are, instead of responding to it as a flame from the "gnome" side.
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 21:22 UTC (Tue) by farnz (subscriber, #17727) [Link] And this is where we disagree; I don't see Cairo as the eventual standard for X Window System GUI toolkits, not least because they've not managed to get TrollTech onboard. Indeed, Cairo isn't even mentioned on the X.org pages, while RENDER is, implying that RENDER is "more" of an official X.org standard. Further, both Cairo and Arthur can render using RENDER, just as both GTK+ and Qt can render via other X11 operations. If we'd been having this debate ten years ago, there's a good chance that we'd have been arguing about the future of the standard toolkit for X applications.My feeling is that if it were worth KDE's while using Cairo, someone would have gone and done it; as it is, TrollTech have done their own thing, which KDE might adopt from a simplicity perspective (although the devs are more than competent to decide that they prefer Cairo and thus go and use it separately, just as the KDE devs don't rely on plain Qt themes, but have gone and created KDE themes, or indeed the way some applications now use GStreamer for multimedia). On the API issue, please go and look at the kdelibs module; there's stuff in there that duplicates Qt stuff, but done differently (and probably better from a KDE perspective); Arthur does not imply that KDE will not use Cairo, it just means that Cairo's C++ API has to be enough better than Arthur to be worth the hassle. To take the flame issue: firstly, there have been some major flamewars on both sides of the fence relating to interoperability; the recent ones that I've seen have all been started by someone claiming that one desktop is worse because it's not adopted a technology the other has (Cairo in this case, but I've seen KIOSlaves, DCOP, DBUS, ATK, Pango, KCacheGrind and others used), then trolling whenever people dare to argue. Secondly, precisely because Qt is not controlled by KDE, the KDE team do look at what happens elsewhere; if Cairo is worth adopting over Arthur (if the API is nicer, for example), it'll be implemented in kdelibs. If it's not, that work won't be done. Thirdly, there is a degree of unification between Qt and GTK themes, although all the work on that has been done from the perspective of allowing GNOME apps to look like KDE side (I'm referring to the GTK-Qt theme engine). OK, so it's by no means perfect, and it does mean that only Qt themes can be used (whereas I'd assume you're after a unified theming system such that a theme is desktop-independent), but there is no equivalent going the other way (allowing Qt to use GTK themes).
Qt, the GPL, Business and Freedom (OfB) Posted Aug 10, 2005 4:11 UTC (Wed) by bangert (subscriber, #28342) [Link] > That's all I'm trying to say: KDE is, obviously, constrained by> Trolltech's architectural decisions with their Qt product, and > these decisions are not always in (what I perceive to be) the > best interests of the Linux desktop. so let me ask you: how can an additional technology be a constraint?
|
|||||||||||