| |||||||||||
Qt, the GPL, Business and Freedom (OfB)Qt, the GPL, Business and Freedom (OfB)Posted Aug 8, 2005 19:53 UTC (Mon) by aleXXX (subscriber, #2742)In reply to: Qt, the GPL, Business and Freedom (OfB) by ajross Parent article: Qt, the GPL, Business and Freedom (OfB)
Hi,
(Log in to post comments)
Qt, the GPL, Business and Freedom (OfB) Posted Aug 8, 2005 20:54 UTC (Mon) by ajross (subscriber, #4563) [Link] To be fair, I tried to be precise: one can develop commercial KDE software, but not with KDE as it is shipped by linux distributions. You need to obtain a separate license from a separate company (Trolltech), which is "odd" from a business perspective. Yes, it is affordable to anyone with a non-trivial revenue stream from their product. And yes, the Trolls certainly have the right to sell a commercial product. Nonetheless, this is definitely a complication for anyone (especially an IT manager unfamiliar with linux) intending to do non-GPL KDE development. And it's one that the Gnome libraries don't share.But the technical/design collisions are actually more troubling to me. Here is the next one: X.org and Qt have picked divergent paths for their vector graphics APIs. Take a look at their websites:
http://cairographics.org/introduction My quick reading (not being an expert on either) tells me that these have maybe 80% duplicated feature sets -- Qt lacks Cairo's postscript-like arbitrary paths for stroking/filling, but has more working backends for proprietary platforms like win32. But they're completely source-code incompatible. This is a problem. It means that useful software (e.g. an SVG interpeter or charting engine) will work with one or the other, never both. And all linux distributions will need to include both. And KDE (which has not moved to Qt 4 yet) will be forced to pick an API. And we'll need to sit through more flamewars about which is better. As far as I can see, Qt's new paint engine exists only because of scheduling/marketing issues. The Trolls could have wrapped Cairo in a Qt-like C++ API, but they chose to write their own instead so that they could get Qt 4.0 out the door on their schedule. That's empatically not a "bad" thing. But it is a problem for KDE, which now seems to be firewalled off from X.org development with Cairo.
Qt, the GPL, Business and Freedom (OfB) Posted Aug 8, 2005 21:56 UTC (Mon) by aseigo (guest, #18394) [Link] > It means that useful software (e.g. an SVG interpeter or charting> engine)will work with one or the other, never both. besides being an oversimplification, why does this matter? if someone writes an SVG engine using Cairo, link to Cairo and you're done. they write it using Arthur, link to Arthur and you're done. and the way Arthur is written, a Cairo back end could certainly emerge once Cairo is mature and interest is there. > which now seems to be firewalled off from X.org development with Cairo. cairo is not the only, or most useful, thing happening around X.org these days. you may be interested to know that Trolltech is actually sponsoring a TON of X.org development these days, from render acceleration to actual X.org drivers. you're making mountains out molehills and making the community out to be far more divided than it is.
Qt, the GPL, Business and Freedom (OfB) Posted Aug 8, 2005 22:23 UTC (Mon) by ajross (subscriber, #4563) [Link] > you're making mountains out molehills and making the community out to be far more divided than it is.
Well, I'm obviously outranked here so I won't argue further. Nonetheless, I'd feel a lot better if your response had been something more along the lines of "Yes, we know Arthur and Cairo codebases represent duplication of a (rather complicated) feature set, we think this is a bad thing, and we're working on a way to merge the APIs". Your response sounds to me more like "Who cares about toolkit-independent rendering APIs anyway? Look at all the other X.org stuff we support."
Qt, the GPL, Business and Freedom (OfB) Posted Aug 8, 2005 23:13 UTC (Mon) by aseigo (guest, #18394) [Link] well, if Cairo did meet the needs, it would be used. but there's the issueof systems that do not have Cairo now and probably never well that need to be addressed. Arthur is not a way to draw to X, it's a way to draw. period. much like how Qt's file i/o classes are not a way to work with files on UNIX, they are a way to work with files. as i noted, at some point there may well be an Arthur backend that targets Cairo. i don't see this being a barrier to working together or code dupe. looking at the current trend of these things, e.g. poplar for pdf, kdom/ksvg/khtml/kjs for webcore, gecko for moz, etc... the shared code happens below the rendering layers anyways.
Qt, the GPL, Business and Freedom (OfB) Posted Aug 8, 2005 23:57 UTC (Mon) by ajross (subscriber, #4563) [Link] > well, if Cairo did meet the needs, it would be used. but there's the issue of systems that do not have Cairo now and probably never well that need to be addressed. Arthur is not a way to draw to X, it's a way to draw. period.
I'd strongly suggest you take another look at Cairo, because that's not really correct. Cairo (just like Arthur) was designed from the beginning to have a pluggable backend architecture. They claim to have backends currently (in various stages of development) for memory buffers, OpenGL, PNG, Postscript, XLib, MacOS/Quartz, and Win32. What other platforms are required to "meet the needs" of the Trolltech crew?
I suspect your answer will not be features but timing -- the Qt 4 release needs to be out now, not on Cairo's schedule. Which is really my point: the trolls' marketing requirements (which have almost nothing to do with KDE -- just check the Qt 4.0 release page, it doesn't even contain the string "KDE" once). have cause what, to my eyes, is a regretful fork in the vector graphics APIs available on the free software desktop.
To someone who uses and develops only on KDE, that's perhaps doesn't seem as big a problem as it does to those of us who use other toolkits and desktops on occasion. The KDE/Gnome fork should be *closing* as time goes on, and they should be sharing *more* of the underlying technology. But the opposite seems to be happening, and it strikes me that the biggest force driving this wedge is Trolltech's Qt licensing.
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 7:42 UTC (Tue) by farnz (subscriber, #17727) [Link] As someone who uses KDE, and has done for years, it looks to be 6 of one and half-a-dozen of the other. Sure, KDE isn't necessarily going to use Cairo, since Arthur fills the same need; on the other hand, both KDE and GNOME are going to use Poppler.However, DCOP massively predates DBUS, and I have yet to hear a justification for the differences between DBUS and DCOP that doesn't boil down to "we wanted something not KDE for an IPC mechanism". It wouldn't have been terribly hard for the GNOME devs who wrote DBUS to have used the same "on-the-wire" data format as DCOP, thus making bridging DCOP to DBUS, or replacing DCOP with DBUS simpler. Further, at the point GNOME was started, there were projects like Harmony, which were aiming to completely reimplement Qt in a fully free fashion; the GNOME devs chose to go their own way, rather than work on KDE. In any case, why should KDE and GNOME share stuff, unless both sides feel it's worthwhile? They're different, compatible desktops, not two different skins for the same thing. Poppler is worth sharing, since the people working on Evince and KPDF agree that it's worth having; maybe a vector backend isn't worth the work of sharing?
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 16:56 UTC (Tue) by bronson (subscriber, #4806) [Link] That's easy. http://www.google.com/search?hl=en&q=dbus+vs.+dcop The idea was not "we wanted something besides KDE." It was "we wanted something that would work well without KDE, Gnome, ANY desktop environmnet, or even X11." Since DCOP is so tightly coupled to X11 IPC, it required a ground-up rewrite anyway.
As far as GTK+ vs. Qt (this is still being discussed??), the Gnome guys had to select a different API because there was serious concern about using Qt's interfaces. What good is Harmony or any clone toolkit if Trolltech still owns the API? He who owns the API owns the system (or at least exclusively steers its development). In addition, API-related lawsuits were a pretty common thing back then.
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 17:45 UTC (Tue) by farnz (subscriber, #17727) [Link] So, let's get this straight: GNOME chooses to do something differently to a released, stable KDE technology, and there's sound reasons to do so (so GNOME is OK). KDE does something differently to an (at time of original development) unstable GNOME technology, and this is an example of refusal to think about cross desktop cooperation?Personally, I think the fuss over cross desktop cooperation is overblown; if it's worth having, someone will do the work needed. If it's not worth having, why fuss about it? The pointing fingers, "you're not being helpful" approach just makes it clear to me (as a KDE user) that I don't want to go near GNOME due to the politics (and I already have KDE apps that cover everything I do). No doubt it has a similar effect on GNOME users (who decide not to touch KDE because of the politics).
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 18:20 UTC (Tue) by ajross (subscriber, #4563) [Link] 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.
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?
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 18:22 UTC (Tue) by bronson (subscriber, #4806) [Link] Each organization made the best decision it could at the time. Trolltech had sound financial and scheduling reasons to develop their own solution. I suggest ignoring the monday-morning quarterbacks... Despite their noise, they are definitely in the minority.
Personally, I use the best apps from each desktop (Gaim, K3B, etc). What does politics have to do with anything?
Qt, the GPL, Business and Freedom (OfB) Posted Aug 9, 2005 18:53 UTC (Tue) by farnz (subscriber, #17727) [Link] The politics is the "monday-morning quarterbacks"; I'm already in a pure KDE comfort zone, but when I put my nose over the border to see if GNOME offers me anything, I see all these "KDE's bad!" posts, without any reasonable justification.Thus, I'm not interested in trying GNOME; I'm happy with KDE, and from that perspective GNOME's cheerleaders are offputting. I'm sure that someone in my position, but on the GNOME side gets a similar view of KDE.
|
|||||||||||