Matthias Ettrich's talk on Universal Components at LinuxForum (also given at LinuxTag) is finally now online. You can view the slides
as you watch in Real Video format (part
1, part
2) or listen in ogg
format. Matthias covers everything from basic concepts of
components to CORBA, COM, Universal Objects, and UCOM
in Qt3.
Particularly notable is the coverage of Universal
Objects, which is apparently a concept that originated from a Borland/Kylix developer, and
the
promise of future component interoperability between the likes of
Qt, KDE, Kylix, Phoenix Basic, Python, GTK+ and what not.
Intrigued, I thought I'd take a closer look at QCom. Unfortunately, qcom.h
itself seems pretty evil (it may help if you come from COM-land), so
it is advisable to also consult the write-up which is fairly nice and concise. Personally, I find it somewhat surprising that one would have to deal with seemingly low-level details such as UUIDs and the such; one wonders what other options are available.
Finally, another useful thing you may learn from this presentation
is whether and when to pronounce Qt as "queue-tea" or "cute". (Hint: it depends on random intricate QuanTum fluctuations in ice
cubes.)
Comments
Since IIRC KDE 3 will be based on Qt 3 and if this UCOM will be part of KDE 3, what can we expect from KParts ? Will it be converted to use UCOM or just as it is ?
People are re-inventing 20 year old technology, badly.
Go away if you have nothing to say except pointless one-line trolls. Otherwise do a better job of explaining your opinion.
This is very nice work and deserves more than your one line put-down.
This looks like the beginning of an increasing "trollification" of KDE.
As both a windows and Linux developer I always detested Microsofts COM model. Although it looked good on paper it ended as complicated and error prone way of doing large scale development. Now I am starting to see stuff I don't like enter Linux. I could always ignore it but I always liked KDE. I wish QT would just do a widget set but as a commercial company they obviously need to put as much functionality into QT as they can. Functionality that might be better placed within KDE maybe.
KParts seemed nice but I guess like increasingly other parts of KDE everybody will just go along with the Troll functionality. They seems to be wrapping up more and more stuff that happend within the KDE community effort. Not to mention stuff that exists within the POSIX sphere. HTTP support, Regular expression stuff, Database stuff.
KDE will end up as nothing more than a thin layer on QT if its not careful.
Is there any examples of QT going along with any KDE ideas? Everything I can think of seems to be KDE changing direction to encompass latest changes in QT.
Of course people will argue that the "Trolls" are a nice bunch of guys and so they are for now, but what if they decide to license QT under more onerous conditons a couple of years from now one KDE/QT is mainstream and developers can no longer just pick and choose but are locked in like we currently are with Microsoft?
>> KDE will end up as nothing more than a thin layer on QT if its not careful.
And how is this a bad thing? Because...
>> what if they decide to license QT under more onerous conditons a couple of years from now
Then KDE stays with the GPL version and develops based off of that. 3.0 will be GPL. If an alien shoots the trolls with a brain ray, and 3.1 is only released commercially, 3.0 will still be (and always will be) available under GPL, and a fork will occur. Since that will really destroy a large chunk of Trolltech's position in the developer community (not just FS and OS developers), it's a very unlikely move. And it won't affect KDE anyway.
Incidently, I disagree with you about putting things like database abstraction into the toolkit; in modern programming, such things are pretty much necessary, and if done right (I'm not a fan of ODBC), it makes the code much more flexable and powerful.
>> As both a windows and Linux developer I always detested Microsofts COM model.
Now that I will agree with. I've been stuck doing "pay the bills" programming, and have only played around with KDE (tossing out patches to authors, mostly), but dcop seemed to head in a direction I really liked. Some things (like namespace handling) needed to be cleaned up a bit, IMO, but Signal/Slots, KParts, dcop, views and kio slaves seem to really work well together in real world situations. I'd like to see something like KParts and dcop without a GUI so that server and embedded processes can be connected to remotely and controlled via native KDE app connectivity, plus a full relational database included by default into KDE (something like MySQL - small, fast and relatively (for a desktop backend) powerful), but that's just me daydreaming about the perfect environment.
--
Evan
KDE as a thin layer on top of QT would be bad. Its bad because I would like KDE to be not so dependant on one company and for KDE to have a broad base of developers working on it from around the world. And for those developers to pursue their own direction independant of Trolltech.
There is some similarity to Trolltech position now and Microsofts in the 80s/early 90s. Shawn Gordon in his recent Slashdot Interview mentioned he was taking a more "QT centric" approach with his Kompany. This is much like the feeling among Windows developers of the last few years to eshew some third party software today because Microsoft was going to "officially" implement some functionality later and there was no point building your code around something today when you "knew" you would end up using the the Microsoft stuff a bit later.
For the moment the having the Free software community on board is important to Trolltech. They won't for the moment do anything to hurt that. However if commercial development takes off on KDE/QT Trolltechs priorities will change. They will use QT to drag KDE where they want to go, not necessarily where the Open source community wants to go.
I am not so sure the KDE community would branch of from QT like you mentioned above. Technically they could but as core KDE architects work for Trolltech it would be difficult even if dissatisfaction was fairly high. Once KDE was a a defacto desktop then the "official" TrollTech sanctioned branch of KDE would be the one distributed with the major linux distributions and any branch could be sidelined. I think commercial apps will weigh in importantly later on in KDEs life and the GPL guarantees will come to naught and this is when Trolltech will take charge of KDE. The more functionality they can suck from KDE into QT, means they can then charge for it under their dual licensing scheme. I think the GPL will work against free software ideals in this case.
They don't "suck from KDE into Qt". All code in Qt is property of Trolltech. They are not stealing KDE code.
The scenario you lay out is ludicrous. Trolltech will not be able to "drag KDE around". If they stop releasing the free Qt, then the KDE team would fork the latest Qt GPL version. This would destroy commercial development on KDE (which, in-turn, would cut into Trolltech license sales) for 1 year, after which KDE will LGPL their forked Qt. This would make commercial development cost nothing. If, by then, KDE has become the standard unix desktop, then Trolltech would have just signed their death.
Now, if you're suggesting that Trolltech would do something silly like fork KDE, let me tell you it would never work. I don't care how many members of KDE work for Trolltech. The news would make Slashdot headlines and in less than a week the original KDE team would be reformed and marching merrily along, with full support from the open source community.
Just curious, sorry if it sound trollish.
If TrollTech was to use KDE code would they be able use dual licence, or would they only be able to use it in the GPLd version of QT? If thats the case it will continue to be a one way merge, and there will not be using the full potential of Free Software.
Has there been any open discussion about what will happen with the KDE/Qt overlapping technologies such as Kpart. Will it be killed of as KSQL was?
Trolltech could not reuse GPLed code from KDE and integrate it into a non-GPLed product. In order to be able to do so they would need permission from the authors of the original code. This will not happen and the idea that Trolltech is taking over KDE makes little sense.
Ok, before reading this, you better understand I'm not siding with anyone's opinion -- just reporting what I believe is going on in other's minds. (A crazy thing to do to start with)
----
He actually makes a few important points:
1) All commercial development of KDE apps goes thru TrollTech. This means that any sort of possible revenue is TrollTech's. Bad or good? Not sure, but I sure don't like that. In one way, it improves the possibility that GPL'ed versions of commercial products will be created, if only for the freedom of bypassing the middleman (TrollTech). In another way, it also makes sure that TrollTech gets to state the rules for any sort of KDE commercial developments. No matter how honest (and they are) and good willing (and they are -- 'KDE Free Qt Foundation') they are, I don't like that, and never will.
2) Functionality has been going from KDE to Qt. KAction -> QAction, kio-slaves to qt network protocols, KParts -> UCOM. Once again, KDE serves as a nice testbed for TrollTech's additions to Qt. I don't mean to say that TrollTech's purposefully trying to use KDE as a testbed, but saying that Qt didn't improve due to KDE's usage of it, and KDE's boldness of design would be a blatant lie.
This is bad for KDE, if only from a technical point: Code duplication. Efforts that would be better put into improving what is already there.
From a 'marketing' point-de-vue, it's bad. Real bad. KDE's stuff is simply not good enough, TrollTech had to make better versions. I'm pretty sure there's gonna be an awful lot of confusion about UCOM vs KParts for KDE3 third party applications. Quote me on that.
It also creates the very real possibility that people will create cross-platform applications (which is not a bad thing, by any means) at the detrimental of KDE integration (KParts vs UCOM again) which at the very least, _sounds_ bad for KDE.
> They don't "suck from KDE into Qt". All code in Qt is property of Trolltech. They are not stealing KDE code.
You honestly believe that code is all that matter? Does design quality and algorithmic value mean nothing to you?
Yes, sharing should be encouraged at all cost. Yes LGPL is better than GPL in ALL SITUATIONS (which is my main problem with TrollTech, currently), as far as the movement is concerned. That doesn't mean that people selling code and _ideas_ they took from freely available sources should be encouraged.
----
I think TrollTech was a blessing for KDE, is still a blessing, but, honestly, has all the potential to become a curse. In a world, especially in the computer-related business, where the vast majority of corporations care nothing about their users/customers and everything about their pockets, that people become paranoid about most things TrollTech do is a good thing. Too many old wounds that took too long to dress.
----
The real issue here is the division between the idealistic part of the OSS movement (we shall all share code, knowledge, live as equals, etc.) and the pragmatic part (as long as we have something good working and going... ). The idealistic part believes that TrollTech is abusing (even without wanting to) KDE to feed its Qt product, that they already have too much freedom with basic stuff underlying KDE, and that anything they do that's not directly and unambiguously improving KDE is bad.
When I said suck I didn't mean "steal". I meant the appearance of functionality that was in KDE is being reimplemented in QT. So a migration of functionality occurs from KDE to QT.
I never said they would "stop" releasing a free version. My point is more subtle. They could take control of KDE while all the time releasing new and free versions of QT that slowly recreate the base functionality that KDE provides.The mistake is to believe that the free software community will always be as important to QT and KDE as it is now. Yes we will always have a GPLed KDE and QT. It just that commercial development built on top of KDE/QT may start calling the shots about its direction and that may not always mean a desktop that is what we want.
There are two possible forks if either party is disatisfied: Either Trolltech can fork KDE or KDE team fork QT. Let me address both and how their really is only one outcome with Trolltech in charge.
If and its a big if KDE team really did fork of the last version of QT how long would that branch of the forked QT underpinning KDE last. Trolltech would still be able to ask commercial developers to pay up to develop for the KDE teams fork of QT. They could set a very unfavourable rate for the KDE teams fork of QT all the while giving favourable rates to developers who go with with their offically sanctioned QT. Once commercial development on top of KDE is of equal importance to open source stuff, it will be what large corporates choose as their version of QT that will determine which fork will win. Since they would have to pay for the KDEs fork of QT and for the Trolltech version, they would choose the "official" QT. Hence it will be the version of KDE built on top of the "official" QT that wins.
As for the other away around you are right, Trolltech never would do some thing silly like fork KDE. They won't have to. They will practically be in charge of it anyway. Its largely matter of perception of whose is forking from who, and who is the official maintainer.
I am thinking out aloud. If someone starting making dark predictions in the 1980s about how a small bitplayer called Microsoft would slowly leverage its position with its DOS OS , to supplanting competing GUIs on top of DOS, to building the core applications, and now to providing a media content and services, it would have been seen as a "ludicrous" what if scenario. Even more so since Microsoft was then seen as the "good guy" compared to the IBM of the time.
The similarities are striking. Microsoft initially allowed all sorts of software to live on top of its OS, however it gradually ate up into that ecosystem of third party software from its position of strength of owning the underlying APIs. Almost identical in fact to what QT is starting to do with KDE right now.
I believe Trolltech is in that Microsoft 1980s phase right now and even they may not realize the possible future extent that their current position gives them. Can I buy shares in Trolltech now? (I am serious!)
The one thing you seem to miss is the KDE QT Free Foundation. If TrollTech ever makes QT proprietary, the last open version would become LGPL'ed, IIRC.
I do see your other concerns, but if companies want their software to fit into the leading desktop environment, they must use the "official" KDE way of doing things and not the QT-way...
It does bring me to a question though. Does anyone know if the KDE Project is actually planning to drop KParts or KIO? I've never heard that anywhere besides here.
Finally, I might note that TT really doesn't have total control of commercial software. Think about it: I could release an "engine" of a program that is proprietary, and then simply GPL the wrapper-GUI. The GUI would be virtually useless without the "engine," but the engine wouldn't come under the terms of the GPL because it wouldn't be linked to QT. Maybe not the cleanest way of doing things, but it would allow GUI portablity, and some other cool stuff.
-Tim
Tim,
I am aware of the KDE/QT free foundation. I think it might be a BSD type license its released under if that was to happen.
However they need never make QT proprietry to gradually take control of KDE. They just need to gradually recreate functionality in QT that was once part of KDE and make sure KDE tracks the latest version of QT. In that way functionality originally part of KDE libs end up in QT (Note, I am not saying KDE code ends up in QT). Once similar functional efforts by the KDE community efforts are aborted, the functionality is for use under the dual licenses of QT where they can charge commercial developers for it.
KDE functionality that was once provided for free for both open source and commercial developers ends up being charged for within QT, for commercial developers anyway, and KDE direction is then indirectly influenced by commercial concerns rather than KDE community interests.
QT interests are to be platform independant. A noble goal but the main platform after Unix that TrollTech is interested in is Windows. How likely that QTs goals will always in be same as KDE. Does KDE really care about running under Windows.
>KDE as a thin layer on top of QT would be bad. Its bad because I would like KDE to be not so dependant on one company and for KDE to have a broad base of developers working on it from around the world. And for those developers to pursue their own direction independant of Trolltech.
--
So you like to work for the sake of the work? The more (basic) code which is in QT the less work KDE developers have to create/correct/verify and they can take the time to develop something different/fancy, and there is enough to develop.
To get specific: have a look at the almost off topic dicussion on kde-devel about the necessity of hyphenation/justification support for a DTP application. Everybody of course thinks it would be nice if QT would provide this, since one would have to study a lot ( font handling, grammar, layout techniques ) just to start this, and there is almost nobody willing to make this effort.
And here you get specific:
>I think commercial apps will weigh in importantly later on in KDEs life and the GPL guarantees will come to naught and this is when Trolltech will take charge of KDE. The more functionality they can suck from KDE into QT, means they can then charge for it under their dual licensing scheme. I think the GPL will work against free software ideals in this case.
You are actually worrying about commercial/closed source (ccs) apps. Now, I hope, KDE will not need this and will be able to provide a free replacement for all standard and some non standard apps.
But the developers of ccs have to pay Trolltech independently of the amount of "KDE-functionality" which is in QT, if they want to develop for KDE or with QT. The alternative would be to start a new project with a LGPLd library, but why would you want to do that? why shouldnt ccs pay a trolltech tax - who carees?
There are currently many free replacements for QT, even in other lanuages - the competition is high and Trolltech will never be able to charge an unreasonable price for their toolkit.
Anyway: "Once KDE was a a defacto desktop" is far, far away. Currently its important to make it the best alternative desktop there is and every programmers effort is necessary to achieve this. This includes of course Trolltechs programmers
Yes, I do worry about Commercial apps in KDE, but not in the way you are implying. I worry that that commercial apps have the power to influence KDE via its link to QT.
I don't care that corporates they have to pay money to Trolltech. I worry that the money TrollTech receives for QT will change QT in ways that are unfavourable to KDE, and KDE will just have to go along with the changes.
I think QCOM is an example of this. A messy Windows technology being ported over to QT because Trolltech think big corporates want this sort of "enterprise" functionality. Microsoft has come up with some decent stuff in their time. COM is one of them though. From a C++ developers perspective its difficult and clumsy.
Hard to say when or if KDE becomes a defacto desktop but my belief is it might be sooner rather than later and not a long way off like you think. However once that happens the same lock in effect occurs that we have now with windows and the fact that there is other free toolkits will become irrelevant.
'A messy Windows technology being ported over to QT'
Your an Idiot, that is all I have to say.
And what do the main KDE developers think of that?
Those who developed KParts, are they happy with this evolution of QT?
I'd like to hear them express their thoughts as I don't have the technical skill to judge the matter.
The KDE developers have understood what Qt is from the start. This evolution of Qt is nothing surprising to them, I dare say. It is the people who think that Qt is a widget library who are surprised. Qt has always been more than a widget library.
If KDE has superior technology, then KDE will not be forced to switch to inferior technology. KDE developers do what is best for KDE, so maybe it is time for people to quit being so alarmist.
Actually I think you are rewriting history here. KDE developers initially treated QT as nothing more than a particularly good widget library. Its only in the last year or two that it seems to have dramatically increased its ambitions, with KDE taking on board much of its functionality.
What are QTs limits then? Does it have no limits?
Will its limits be too wrap up all OS functionality?
If KDE has superior technology it won't be forced to switch? Has history alway borne this out in the past?
KDE developers do best for KDE? Depends, What if they also work with Trolltech, will their not be conflicts of interest.
I think some hard questions are being brushed aside with a cheery don't worry. It was the lack of foresight with Microsofts strong position in the 1980s that I am stuck being a Windows developer now.
Have you ever heard of QString? What about QUrl? Or QFile? The list goes on. What does this have to do with widgets? They have been used in KDE for as long as I remember.
You show me where KDE has abandoned existing superior technology to Qt. You're the one who wants to make a point. :)
The KDE community is a much larger project than Trolltech or a few Trolltech employees. Big decisions are made by logical group decisions, not coersion. You should give the developers more credit than that. :)
Its a bit like saying Microsoft Internet Explorer is superior technolgy. It is, but only because its starved other companies of resources to develop competing browsers by being "free" so its the only one left standing.
Similarly 3 years from now, QCOM, I have no doubt will be hailed as "superior" technology if indeed KParts is killed now. But who knows how good KParts could become if it was left within the KDE community.
QString, QUrl , QFile, Are they the best examples of QT aspirations to be "greater" than a widget set? ;-) Seriously, I understand a toolkit may spread out into other areas. I just wonder about how much it will or should encroach into KDE? And how willing the KDE community would be willing to stand up against something in QT that is undesirable?
My point is how much should be done by QT and how much by the KDE community. There surely reaches a point where if the KDE community want to pass up on implementing certain functionality you got to question how interested they are really in developing a desktop that they are in control of.
I like Qt as a widget library, because of (at last for me) clear design and easy learning. But I'm in doubt about implementing non widget things. Library should do one thing good, than many things averagely. QCom can be separate library for people, who like it and KDE remains on kparts, which works well.
I would like to know, why Qt provides and KDE uses QString, when string is in the standard c++ libraries, why Qt implements container templates, when STL do the same thing... are QString, QList, etc. inspirated by MFC's CString, CList, etc.?
The QT library is older than the STL. Not all compilers which QT wanted to support could handle the templates in the STL. QString provides unicode support and implicit sharing, which the std string doesnt provide
You may want to read sections 21.2 and following
of the C++ standard:
"The header defines a basic string
class and its traits that can handle all
char-like (clause 21) template arguments..."
But AFAIK you are right in that the standard does
not require reference counted implementations (see
21.3, verse 6).
Ingolf
First I want to say, I agree that Qt should be split into several smaller libs (qtutils, qtui, qtextensions or something like this).
Well, the reason why to use QString instead of string is simple, all other Qt classes take QString as argument (e.g. the text for QLabels), additionally all Qt classes are documented *very* good and online, compare this to the STL docs you can find on the net.
And last thing, kparts will probably not be killed with KDE 3/Qt 3, since KDE 3 will mainly be a port to the binary incompatible Qt3 including fixes which could not be done until now due to the BC freeze.
bye
Alex
Well, if KDE will end up as nothing more than a thin layer on QT, then more developers have more time to develop applications. Wouldn't that be good ?
KDE as thin layer on top of QT? Is that really good. Lets take it to the extreme. Its so thin that in fact QT and KDE are almost one and the same.
So now "KDE developers" can concentrate on the applications like you said. Great, but following that logic why not let Trolltech do the applications as well. Saves "KDE developers" even more time!
Following that line of thought to its conclusion we end up as KDE consumers not developers. Is that the ultimate desirable outcome.
Sure, lots of things make sense in QT, and lots of thing won't, but Trolltech as a commercial company obviously won't want to limit themselves to just a purveyor of widgets. They will add things to QT whether or not it makes sense for KDE.
In my opinion, coming from the Windows world COM is a unholy mess of a technology that seems to be coming soon to a KDE desktop near you. Will KParts disappear in favour of QCOM. I hope not. the QT / KDE programming model was so clean and now it looks like getting a lot of Windows type complications. I think this might be the first real test for the QT and KDE relationship.
Your extreme logic is flawed in that it already extreme from the get go. You should know that Qt has always been and will be more than GUI widgets.
Qt is an application framework that needs to be portable. Qt contains technology towards that portability goal. KDE uses what it needs but is not limited or controlled by Qt.
KParts will not disappear unless it is a decision by the KDE developers. KDE developers will do what is best for KDE. This is not any first real test of the Qt/KDE relationship by any stretch. :-)
KDE developers will always do what is best for KDE?
What about if they also work for Trolltech?
Then they are at the same time KDE developers and TT developers. And if they ever get into a conflict of interest, we will know what they prefer to be.
However, this silly little jealusy scenario you are flaunting is no conflict of interest.
I, for one thing, am glad of using whatever TT chooses to create.
Just as since the beginning of KDE, we were always happy to use whatever someone else was developing that was usable.
Life is only this long, and if someone wants to create a XML parser, we will use it so we don have to know how to write a damn XML parser.
If Qt grows until it does a bazillion things well, GREAT. We will do another bazillion things on top of it, or half a bazillion, or whatever.
In the end, you get more bang for none of your bucks. What exactly is wrong with it?
I, for one thing, am glad of using whatever MS chooses to create.
See the point.
No, I don't see the point.
TT produces GPLed code. KDE uses this GPLed code. If TT decides to re-do something that KDE has already done, then it will either be worse then KDE's stuff (and it goes down the drain) or better then KDE's stuff (and KDE's stuff dies, and there's a small period of switching over).
What the hell does this have to do with M$?
I'm afraid that TT will not drop its code because KDE's one is better. It is possible only in one direction.
When Microsoft released its Windows, all application developers were happy - do you remember this - "we have a standard platform at last". But Microsoft didn't stopped it became to develop applications. There is an third party application running on Microsoft system, and a Microsoft application running on Microsoft system - and Microsoft wins even if its application is much worse. The question is only when TT will finish QT and start to develop applications.
What with API's - did you see MFC ? It is horrible, but the most popular - do you think that developers have choosen it because there was nothing better ?
Well, there's a big difference between TT and Microsoft:
Microsoft produces an OS, and it's most popular office suite, and it's most popular web browser, and controls all of it. This will change in a few years, I am certain, but right now, the desktop market is cornered by M$, and for most userland (not serverland or developerland) software, it's their way or the highway.
Troll Tech produces an Open Source library, that does GUI stuff, and many other functions. It does things similar to several other libraries, both commercial and Open Source. Note the reference to *alternatives*. Yes, TT is doing things that have already been done, but unlike with M$, it isn't forced on anyone. If they produce crap software, well, then they lose, and KDE developers fork the QT tree (or perhaps switch to some other library/libraries) and TT loses. But if their software is better then what's out there, then TT wins, KDE wins, and even the people who liked (for example) DCOP win (because they wouldn't switch if they didn't like it, and thus we go back to the first scenario)
TT doesn't have to drop any code that it doesn't want to, but if they do something that hurts KDE, and don't stop, then they've just lost a whole load of developers, beta testers, and customers (because who would pay for the commercial version of a library that's different from the one that everyone else is using?)
Thus, TT produce bad code, TT dies. TT produce good code, everyone wins, especially KDE developers, KDE users, and TT.
>It is horrible, but the most popular - do you think that developers have choosen it because there was nothing better?
Who am I to explain the strange behavior of many Windows developers? :-)
>The question is only when TT will finish QT and start to develop applications.
They already have, and look what's happened! QT Designer is a (imho) good piece of software, and several people are using it. It's even being used in KDevelop, iirc. On the other hand, QT Linguist is really not as good as KBabel, and just about everyone I've seen is using KBabel, not QT Linguist.
QT and KDE are now well and truely married for better or worse and the normal open source protection of forking won't work because of the dual license.
KDE developers will not be able to fork QT and have both opensource and commercial development exist on top of KDE. Trolltech could put more onerous licensing conditions on top of the KDE split of QT for any commerical developers who chose it. One may argue that they don't care about commerical developers but if there is a Troll tech supported KDE with its official version of QT or a KDE community split of QT the main distributions will probaby run with the TT one as both versions are GPLed and will argue that the TT version is just as good. If commercial development on top of KDE becomes a large scale activity on par with the volume of open source apps then it will be the version of KDE that can support both Comercial and Opensource development will win. Trolltech probably have a better chance of forking and supporting KDE then KDE have of forking QT.
Its well past the point where KDE can just drop QT. QT has reached a size where a reverse engineering of it or building a new KDE on top of a different toolkit would be a 2 year minimum undertaking. In the current environment that would effectively kill KDE.
KDE is married to Trolltechs QT and will live or die with Trolltechs version of QT.
You are completely missing the point I think. KDE is not designed for commercial companies to write programs for. It is an open source desktop environment and always will be. What you seem to want is an LGPL QT. Well, it ain't gonna happen, and in RMS' view it shouldn't. See his "Why not LGPL" article on the GNU web page.
I understand that KDE is not designed for commerical companies but it is built on QT which is. The reality is that if Linux/KDE becomes successful then commerical developement will appear on top of KDE whether it was designed for it or not. Trolltech as a the gatekeeper to commercial companies developing on KDE will have then an interest in making sure KDE develops in a way favourable to QT and Trolltech and not necessarily the way the open source community would like.
A LGPL QT would get KDE out of many problems I think. Certainly core KDE developers believe in the LGPL as well or why would so many KDE libs be under the LGPL.
I would love to know if Stallman really believes that the dual GPL licensed QT really works in KDEs advantage. I don't think he does but he has dug himself in a hole with his statements about the LGPL so he could hardly say otherwise. Still his statements a year back had a coolness to them about the GPLing of QT that I can't quite place my finger on.
You are right though. A LGPL version of QT will never come from Trolltech as it would blow a big hole in their business model.
The best thing would be for Red Hat / Mandrake / or SUSE to buy out Trolltech and LGPL the stuff so that the Trolls don't end up becoming the Microsoft of Linux. I think by the time the big distributers notice this problem Trolltech might become a very expensive company to buy as everybody else will be suddenly noticing the strength of Trolltech positions as well. Of course if they did buy Trolltech with the knowledge that it was in a very powerful position then they would be tempted to keep on the dual licensing as a revenue stream. I guess we are stuck! I would love to buy shares in Trolltech but its privately held?
It doesn't have to be reverse engineered! QT is GPLd for pete's sakes, it's forkable
I explained in other postings why I think KDE would never fork QT no matter what direction QT goes in, good or bad. I am not willing to repeat here again.
Interesting you mention XML parser. I am no XML expert but why use the TT one. Why not use the one of the other XML parser tools out there. Do we really want KDE be just be based on QT or should KDE draw from the best of the vast richness of opensource projects out there?
KWord was retrofitted to use the QT3 rich text edit control. There well might be a good argument to have done this, I am not familiar enough with this area to say if this was a good idea but it does give pause for thought.
What about KSpread based on some future Spreadshead/table control or worse a future Konqueror based on a future QHtml widget instead of KHtml? Does the KDE community keep saying "great now we can concentrate on doing something else because Trolltech have decided to support this functionaility in QT". If the KDE developers really want a commercial company to support all this extra functionality for them maybe we should question how much KDE community is really interested in having a desktop they control.
In fact TT are interested in the desktop environment and producing the whole shebang on top of that environement for the embedded market with QT/Embedded and QT/Palmtop. A future TT might very well be interested in going the full distance with its own desktop environment. In which case KDE was a merely a useful bootstrapping environment to mature QT to the point of it being a replacment.
TrollTech have been pretty good guys so far. I just don't think KDE has the protection or the mind set at the moment so defend itself against a Trolltech that might be very different in a couple of years. When Trolltech starts recruiting MBAs and Business Analysts and Marketing people who have no appreciation of open source or QTs history and will just see QT involvement in KDE as a means to an end.
Although everybody is very defensive of TT and QT and seem to have a unreasoning faith in the protection of the GPL and the KDE/QT foundation ask youselves this question, if Microsoft bought Trolltech out, would you have no worries. Can you truely answer yes to that? I know I can't.
KDE uses both the xml parser in Qt and the parser from libxml. libxml is nice because it supports a an xslt layer (libxslt) and supports external entities, which is e.g. important for docbook->html conversion. Qt's parser is nice because its unicode support integrates well with QString and it has a nice dom-based api. So this is indeed an example how KDE "draws the best from the vast richness of opensource projects".
As for KWord, I have no idea what you are trying to say. Should KWord continue to use the old buggy code instead of stable and maintained code just out of spite for Trolltech? Why? Does it carry the Ebola virus or what?
Also, the statement about the "KDE community" is nonsense. There is no central authority which controls which programs users use and which programs developers write. Users will use whatever fits their needs best, regardless who writes it. Developers use those tools which fit their needs best. When I want to parse xml files, I naturally use QDom unless there is a good reason not to do so, because it is just the most convenient way to access dom trees. Who are you to tell me that I must use a different parser? If you are going to write a parser that is as easy to use as QDom and has more features/is faster/whatever, fine, it will be used by developers. But expecting people to use inferior code just in order to avoid Trolltech is plain ridiculous.
Don't get furious and whip yourself up into up an anger for something I am not saying. I am not saying you should not use QT parser. I am not setting myself up as an authority on what developers should be using. I am saying I am noticing an accelerating migration of functionality from KDE to QT and am speculating on what happens if this continues.
My point is it will nearly always make more sense to use QT funtionality instead of stuff outside QT. It will also nearly always be easier. And that may not be always a good thing in my point of view.
KDE could be Trolltechs big jackpot in the future if commerical apps start appear on any scale on KDE. Trolltech will always want to make things as easy as possible for KDE to use QT. And that could be double edged sword for KDE.
Funnily enough this is just like in Windows. It always made more sense to use the Microsoft technology instead of third party software. Because they had more flexibilty in tying new functionalty into old it was always more "convienent" to use the Windows stuff instead.
If you remember Borland OWL C++ libraries from a few years ago and its competition with MFC. There was always the feeling that MFC was better because Micosoft owned the Win32 API and thus MFC would fit in better into the Microsoft model and track future changes more closely.
The example you mention, that you like using the Qt parser because it better integrates with QString. That sounds like a past echo to me and future warning of QTs dominance over KDE.
No KWord should not use buggy code and I guess it better to use stable code in QT then have buggy code outside of QT but it begs the question of why nobody is really that interested in creating a non buggy foundation outside QT. I am not and I guess neither are you.
KDE community is a good term. You don't need a central authority to give a a label to KDE users and developers. Type "community" into KDEs search engine on www.kde.org and look at the many hits. Obviously KDE developers do view themselves as a community You say there is no central authority which controls which programs users use and write but I guess Trolltech is starting to come close in some ways.
I guess until Trolltech start producing applications that start eating into KDE apps will the bell really drop amongst KDE/Trolltech evangelists and for now I just look like a mad GNOME troll myself. :-)
PS I am no fan of GNOME. I love KDE, I like QT. and I think Trolltech have been model citizens to date, but my points still stand unchallenged IMO.
--
No KWord should not use buggy code and I guess it better to use stable code in QT then have buggy code outside of QT but it begs the question of why nobody is really that interested in creating a non buggy foundation outside QT. I am not and I guess neither are you.
--
Then you are guessing wrong. KDE has always been about creating something that *works*. It has never been KDE's goal to reinvent stuff just for the fun of it, when a component is already available, maintained and free.
--
You say there is no central authority which controls which programs users use and write but I guess Trolltech is starting to come close in some ways.
--
Then you guessing wrong again. It seems that it is trendy these days to make conspiracy theories about companies controlling projects or whatever. We have seen this with "RedHat is controlling Linux", "Ximian is controlling GNOME" and "IBM is controlling Apache". What these claims all have in common that they completely ignore how free software development works. When RedHat chose to boycott KDE, within weeks a new company (Mandrake) appeared and sold a RedHat plus KDE; very soon RedHat had to realize that would massively lose market share if they continued their boycott and had to bow down to their users. In a similar way, when the Open Group decided not to distribute X11 under a free license anymore, they had to take back their decision very quickly because it turned out that both users and developers would have simply ignored their X11 implementation.
It's always the same pattern. In a market with competition no company make decisions against their users. That's why Trolltech could never afford to massively increase their prices, as some people like to claim. If they demand an inappropriate amount of money or use inacceptable license conditions, developers will use a different toolkit, and they will go out of business, period. Obviously, they have massive competition in the form of Java (which has a lot of hype, advertizing and many companies behind it) which is even cheaper. They also have competition in the form of gtk and Tk which are completely free, and nevertheless they sell Qt. Why? Because customers think it is a good and well-supported product which follows their needs. This implies that it adds functionality whereever needed or whereever it is not provided by 3rd party tools. Database support a standard feature of tools like Delphi and Visual Basic, so of course it is good when Qt (and specifically the Qt designer) supports it. Also, networking support is a feature that has been demanded by developers. The xml parser is even used in Qt designer itself, so of course it is good to have it available also for other applications that utilize the qt library. The way Qt is developed is a sign that it follows the demands of its users, not a sign of the opposite. On the contrary, it would be a bad sign for the future of Qt if it can't offer the features of competing toolkits like Delphi.
>>I, for one thing, am glad of using whatever TT chooses to create.
Lets make that the rallying cheer of KDE. Hurrah for TrollTech. What ever you agree to bestow on us we will happily except.
>>If Qt grows until it does a bazillion things well, GREAT. We will do another bazillion things on top of it, or half a bazillion, or whatever.
Microsoft also does a "bazillion" things so as to save third party developers the annoying little "chore" of having to write boring things like applications and what not. The idea of a open source community desktop is that they would do it themselves.
Do the KDE community want to develop their own desktop or do they just want to eventually outsource the work to Trolltech?
If someone prefers to do two bazillion things instead of taking advantage of the bazillion TT has given us, he has every right to do so too.
Freedom cuts both ways: you are free not to use it. I am free to use them.
And at least there is a rational argument for the use of TT code: it is licensed freely for us to use it, and it is maintained, and, in many cases, it is pretty good.
Now, if the only reason not to use that freely licensed, maintained, pretty good code is "TT will make more things that we can use", excuse me if it doesn make me want to run and implement a competing codebase.
There were many rational reasons for going with Microsoft 10 years ago. As many third party developers found out to their cost, those "rational" reasons where not a long term rational decision but only bought themselves a short term advantage while giving Microsoft the long term advantage.
And so is the gains KDE makes from QT.
So, basically, you are scared, so we should do what you say.
Yes, very rational, that.
Grow up and look around: just about EVERY successful software company is successful on windows. Pretty much none is successful outside of windows.
Why? Because windows does provide useful stuff to the application programmer. Deny it if you will, but pretty much any programmer will know you are wrong ;-)
A nice thing about KDE is that it provides me (as a programmer) a whole bunch of stuff that makes my life more pleasant, and does that without requiring me to agree to funky licenses [1]
If Qt would provide me everything KDE provides, with as good or better code, in the same conditions, I would say, let's take Qt immediately, and make KDE something else, something new, something cool, something useful.
Because, after all, that is why KDE got started, was it not? Because there was no cool, useful desktop software for unix. And KDE provided it.
Now, if Qt provides that and KDE gets "marginalized" into high-end applications, no big deal, just more interesting and fun things to hack.
And if Qt does not, and KDE provides the whole shebang as now, no big deal, more varied things to hack.
In any case, no big deal. And if someone prefers to ignore Qt and reimplement stuff, last I heard some people founded a whole desktop project just for that, and they seem to be happy doing it.
Just don't get all chicken little on us and ask US to run because the sky is gonna fall.
[1] Except the Funky Software Foundation's GPL, of course.
>>Grow up and look around: just about EVERY successful software company is successful on windows. Pretty much none is successful outside of windows. <<
Windows is > 90 percent of the market. Almost by definition most current successful software companies will have been successful on windows. Isn't this what is called a tautology?
The list of once successful companies on windows who found their functionailty absorbed into windows is a long and well documented one.
>Just don't get all chicken little on us and ask US to run because the sky is gonna fall. <
You are starting to babble.
A tatutology, among other things, is true[1]. You may say whatever you want, but if my argument is backed by a tautology, I am pretty confident on its correctness.
I may babble, but at least I babble with flair.
[1] Despite what you may have heard, tautologies are good. E=mc² is a tautology, once you know that, well, E=mc².
Roberto,
I notice you are one of the voting members of the Free Qt foundation board? That worries me. I would rather see a more cool detached viewpoint towards Trolltech involvement in KDE rather than always automatically running to their defence.
You may indeed disagree with me but as you are a voting member I would expect to take a more protective role towards KDE and a more suspicous role ( even if its not currently warranted ) towards Trolltech.
I am a Windows software developer who is currently only a KDE user. However I would like to develop to the KDE/QT APIs but I have this nagging worry that Trolltech can become to Linux/KDE what Microsoft became to PC developers even with the protections of the GPL and foundation. Am I just swapping the devil I know for a future one that I don't?