Matthias Ettrich On Universal Components

Monday, 6 August 2001 | Numanee

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:

How will this effect KParts in KDE 3 ? - Ariya Hidayat - 2001-08-06

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 ?

depressing - Mike - 2001-08-06

People are re-inventing 20 year old technology, badly.

go away troll - ac - 2001-08-06

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.

Re: go away troll - David O'Connell - 2001-08-06

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?

Re: go away troll - Evan "JabberWokky" E. - 2001-08-06

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

Re: go away troll - David O'Connell - 2001-08-06

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.

Won't ever happen - Justin - 2001-08-06

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.

Re: Won't ever happen - Fredrik Corneliusson - 2001-08-06

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?

Re: Won't ever happen - jj - 2001-08-06

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.

Re: Won't ever happen - Christian Lavoie - 2001-08-06

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.

Re: Won't ever happen - David O'Connell - 2001-08-06

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!)

Re: Won't ever happen - Timothy R. Butler - 2001-08-06

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

Re: Won't ever happen - David O'Connell - 2001-08-06

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.

Re: go away troll - ac - 2001-08-06

>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

Re: go away troll - David O'Connell - 2001-08-06

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.

Re: go away troll - Kujo - 2001-08-08

'A messy Windows technology being ported over to QT' Your an Idiot, that is all I have to say.

Re: go away troll - rb - 2001-08-06

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.

what is qt? - KDE User - 2001-08-06

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.

Re: what is qt? - David O'Connell - 2001-08-06

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.

QString - KDE User - 2001-08-06

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

Re: QString - David O'Connell - 2001-08-06

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.

Re: QString - Tomas Blaha - 2001-08-06

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

Re: QString - ac - 2001-08-07

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

Re: QString - Ingolf Steinbach - 2001-08-07

You may want to read sections 21.2 and following of the C++ standard: "The header <string> 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

Re: QString - aleXXX - 2001-08-14

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

Re: go away troll - Ariya Hidayat - 2001-08-06

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 ?

Re: go away troll - David O'Connell - 2001-08-06

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.

extreme logic - KDE User - 2001-08-06

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

Re: extreme logic - David O'Connell - 2001-08-06

KDE developers will always do what is best for KDE? What about if they also work for Trolltech?

Re: extreme logic - Roberto Alsina - 2001-08-06

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?

Re: extreme logic - Fredrik Corneliusson - 2001-08-06

I, for one thing, am glad of using whatever MS chooses to create. See the point.

Re: extreme logic - Carbon - 2001-08-07

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$?

Re: extreme logic - Krame - 2001-08-07

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 ?

Re: extreme logic - Carbon - 2001-08-07

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.

Re: extreme logic - David O'Connell - 2001-08-07

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.

Re: extreme logic - ac - 2001-08-07

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.

Re: extreme logic - David O Connell - 2001-08-07

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?

Re: extreme logic - Carbon - 2001-08-07

It doesn't have to be reverse engineered! QT is GPLd for pete's sakes, it's forkable

Re: extreme logic - David O'Connell - 2001-08-08

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.

Re: extreme logic - David O'Connell - 2001-08-07

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.

Re: extreme logic - Bernd Gehrmann - 2001-08-07

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.

Re: extreme logic - David O'Connell - 2001-08-07

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.

Re: extreme logic - Bernd Gehrmann - 2001-08-07

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

Re: extreme logic - David O'Connell - 2001-08-07

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

Re: extreme logic - Roberto Alsina - 2001-08-07

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.

Re: extreme logic - David O'Connell - 2001-08-08

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.

Re: extreme logic - Roberto Alsina - 2001-08-08

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.

Re: extreme logic - David O'Connell - 2001-08-08

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

Re: extreme logic - Roberto Alsina - 2001-08-08

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

Re: extreme logic - David O'Connell - 2001-08-13

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?

Re: go away troll - Roberto Alsina - 2001-08-06

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< If someone is doing an app, and he sees a similar but better app done by someone else, he has three paths: a) He just keeps doing his app and he is happy. Maybe someday his app will be the better one. b) He helps the guys doing the other app. c) He forgets about his app and starts doing something else. In all three cases, the net result is better apps for the app-using public. Now, if you see something wrong with that, I do not. Whether the one writing the "new better app" is TT, MS, AOL or Ximian. I suggest that, in the absence of any damage, the action is not damaging.

Re: go away troll - Krame - 2001-08-07

Yes, there were such discussions in a few past days, but they lead to nothing. TrollTech can do with KDE whatever they want - just writting qpanel and qwin and we have QDE, which obsoletes KDE, I don't know what for - but we can do nothing about it, so we can only wait and see if it happens. If we will be happier - I don't know, we'll see. And it is not matter of which API is better - they are mostly the same, but the matter is that they would be slightly different. And I'm afraid that TrollTech will not drop their code because KDE's one is better. It is possible only in a one way. Remember that some people which post comments are in fact TrollTech employees, so they care about their salaries rather than success of KDE. This will differ if QT became a standard GUI, and TrollTech will start to write apps of its own.

Re: go away troll - Ander - 2001-08-08

Just out of curiosity, who are the KDE developers who work for Trolltech?

Re: go away troll - Waldo Bastian - 2001-08-11

Out of the top of my head: Matthias Ettrich (kwin, KDE founder) Harri Porten (kjs) Don Sanders (kmail) Lars Knoll (khtml) Reginald Stadlbauer (kword/kpresenter) Martin Jones (khtml/kscreensavers) Sorry if I missed anyone. Cheers, Waldo

Re: go away troll - Roberto Alsina - 2001-08-08

"they care about their salaries rather than the success of KDE". Ok, the only correct answer to this sort of thing is, of course: Who is this "they" you are talking about, specifically? I mean, name names, dude. After you name names, explain where do you see the conflict of interest, and you must be rather convincing about it, too. That you can just drop by and say that people that has spent an ungodly part of their time on KDE care about a paycheck more than about the project, in a vacuum, without details, to the point of damaging the project, is simply bullshit talk.

Re: go away troll - ichimunki - 2001-08-14

BFD! It's all GPL'ed anyway. The only people who could POSSIBLY be hurt by any of this are the lamers who want to charge big money for proprietary software written on top of a previously non-existent library without having to give anything back for the creative effort of writing the library. What's the difference if TT includes more and more functionality in the library as long as it makes sense to do so? This doesn't affect the GPL nature of the library. If TT was re-implementing an existing, well-worn library I might see the value of LGPL'ing it (as others in this thread seem to desire so badly), but as it stands they are breaking new ground. This is not the GNU project writing a free C compiler and C library. In that particular case the LGPL allows people to use existing source code under a variety of licenses with the new compiler and libraries (had the GNU libraries been GPL only, people would have stuck with their proprietary compilers). In this case, there was no existing code using Qt or KDE. Anyone developing proprietary code on top of Qt should be expected to pay for a license! As for the rest of us Free Software zealots and KDE lovers, we're all fine because both Qt and KDE are GPL. And as a KDE lover, I'm glad to see the TT people (what with the significant overlap with the KDE team) make a buck off the licensing for proprietary developers. This ensures that they will be able to continue dual-licensing their software, while also managing to eat.

Re: go away troll - David O'Connell - 2001-08-14

Maybe the KDE league could start asking for copyright for all contributions to KDE, or try and ask for the copyright of existing code to itself, much in the way of the FSF. Unlike the FSF, then KDE could dual license its codebase as well and be self funding. Why should Trolltech effectively be the tollgate for KDE commercial development and also be leveraging of the success of KDE? Is no one on this list in the least bit concerned that Trolltech (nice guys that they currently are) are still a commercial company funded by venture capital. That the GPL as protection against commercial forces is still an unproven mechanism. With a self funded KDE, the code base can then develop such that functionality appears at the right level rather than the acceleration of functionality from KDE to QT that we are starting to see. The comments of Roberto Alsina especially, really should give people pause for thought. He is a voting KDE representative on the KDE/QT foundation and yet some of his comments on this forum are not in my opinion well balanced. Are people really thinking about the day when KDE is a big success and the potential pressures from that might exist then, be very different from today.

Re: go away troll - Roberto Alsina - 2001-08-19

"Unlike the FSF, then KDE could dual license its codebase as well and be self funding. Why should Trolltech effectively be the tollgate for KDE commercial development and also be leveraging of the success of KDE?" What exactly is this "KDE" you are speaking about? It sounds like a company, which is not the "KDE" I am familiar with, at all. Perhaps you can explain what you mean by making a volunteer project self-funding? "The comments of Roberto Alsina especially, really should give people pause for thought. He is a voting KDE representative on the KDE/QT foundation and yet some of his comments on this forum are not in my opinion well balanced. " Not well balanced? What exactly am I not balancing, in your opinion? Are you just suggesting I may be up for some unspecified wrongdoing? Perhaps you mean I can be bought with Oslo gold or somesuch? It seems like I should be offended by your comment, really. I am not quite sure, though, because the meaning is too muddy. If you are accusing me of something, say it clearly so I know if I should: a) Sue you for slander, libel, or whatever. b) Laugh at you in general. c) Laugh at the writings of a paranoid. d) Explain you that suggesting someone you know nothing about is doing something wrong is a quick way to get your nose bleeding, if you happen to do it in a bar, and is therefore a very bad habit to get.

Re: go away troll - David O'Connell - 2001-08-20

Roberto, You managed to post your reply on the wrong thread. If you want an example of unbalanced view of QT, remember this quote you made. >>I, for one thing, am glad of using whatever TT chooses to create. Is this really a quote from some one who will make the right choices for KDE if Trolltech ever start abusing their position? I am serious. You represent KDE, you would need to moderate the tone of your posts. Why the following rant? >>a) Sue you for slander, libel, or whatever. >> b) Laugh at you in general. >> c) Laugh at the writings of a paranoid. >> d) Explain you that suggesting someone you know nothing about is doing something wrong is a quick way to get your nose bleeding, if you happen to do it in a bar, and is therefore a very bad habit to get. Comments like that make me doubt how effective you would be if there ever really was conflict between KDE and Trolltech.The role requires someone who could keep an even tempered attitude. I find it remarkably difficult to find information on how members were chosen to represent KDE to Trolltech. If people where unhappy with you, how would they go about choosing a safer set of hands? No doubt Trolltech would be delighted with you as a representative but what if KDE people weren't always. Are voting members positions regularly reviewed? Who gets to vote. Who defines the core KDE team?

Re: go away troll - Roberto Alsina - 2001-08-21

If you want an example of unbalanced view of QT, remember this quote you made. >>I, for one thing, am glad of using whatever TT chooses to create. What exactly is unbalanced about it? Be clear. If you say I am unbalanced, you must say what exactly are the things you say I am not balancing. So far, you only mention one: Qt, and in a nebulous way. I simply have no idea of what balance you are suggesting I should aim for, much less how am I not achieving it. Comments like that make me doubt how effective you would be if there ever really was conflict between KDE and Trolltech.The role requires someone who could keep an even tempered attitude. My dedication to KDE is not something you gonna find many people doubting. At least not people who know me even slightly. But hey, if you do, cool, I don't give a rat's ass about your opinion, so, apply rule b) above. I find it remarkably difficult to find information on how members were chosen to represent KDE to Trolltech. I do not represent KDE to Troll Tech. I represent KDE in the KDE FreeQt foundation, which is a very different position. The representatives were chosen by KDE e.V. If people where unhappy with you, how would they go about choosing a safer set of hands? If the members of KDE e.V were unhappy about me, they just choose someone else whenever that happens. No doubt Trolltech would be delighted with you as a representative So far, my only act as a voting member of KDE FreeQt foundation was to sign approval of a Qt license change. There were no other decisions to be made, and no other votes were asked for, and none of the conditions where the statutes imply a vote should be called to change Qt's license happened. Perhaps you have an inflated expectation of my duties. Who defines the core KDE team? I don't.

Re: go away troll - David O'Connell - 2001-08-21

I would not expect you to be "glad at whatever Trolltech chooses to create". You may indeed be happy with what they have currently created but the comment implies you will be happy with any future changes whatever they release. That is an unbalanced comment. It does not need further clarification unless you are deliberately choosing to be obtuse. How do I find out more about the KDE e.V. What is it. How does one join. Is it a closed. How do I find out the list of members. Do you need to be a developer? Is there any overlap with Trolltech employees. The KDE web site is remarkably uninformative about this side of KDE. Also any postion where people decide only to call a vote when they feel like it is not fair. An elected position should be regualary reviewed. >>I do not represent KDE to Troll Tech. >>I represent KDE in the KDE FreeQt foundation, >>which is a very different position. I suspect your are being deliberately pendantic at this stage. Why not explain what the differences really boil down to? Or more to the point make explicit what you think your position involves or may involve at some future point? >But hey, if you do, cool, I don't give a rat's ass >about your opinion I suspect you do or this wouldn't have gone on so long.

Re: go away troll - Roberto Alsina - 2001-08-21

> I would not expect you to be "glad at whatever > Trolltech chooses to create". If you gonna quote me, quote me. That is not a quote. I said I was glad to *use* whatever they chose to create, and there is a very good reason for that: they are being kind enough to make me a gift. I will use the gift, and I will not do it grudgingly, but gladly. > How do I find out more about the KDE e.V. Asking. > What is it. It is a non-profit organization radicated in Germany, formed by KDE developers to handle legal issues regarding KDE (donations, trademarks, and such). > How does one join. I have no idea of what the legal steps to join are, really. > Is it a closed. Sorry, missing adjective. > How do I find out the list of members. I suspect that is in the public record, since it is a legally constituted entity. I don't know the list. > Do you need to be a developer? I would guess so. Of course doc writers, artists and others involved in KDE may join as well. But I am not 100% sure about anything, and am guessing. And really, being a member doesn't mean anything much. > Is there any overlap with Trolltech employees. Yes. > The KDE web site is remarkably uninformative > about this side of KDE. It is a remarkably unimportant side of KDE, too. > Also any postion where people decide only to > call a vote when they feel like it is not > fair. An elected position should be regualary ç > reviewed. IIRC, the KDE FreeQt foundation statutes give a period for each official, but I am not bothering to read them. > Why not explain what the differences [between > being in the KFQ foundation and representing > KDE to TT] really boil down to? I simply vote when a decision by the foundation is required, which mostly is just regarding license changes in Qt, and not much else. I would guess that a KDE representative to TT would handle more general questions regarding direction of Qt, KDE, and the relationship between both organizations. All areas I do nothing about. > Or more to the point make explicit what you > think your position involves or may involve at > some future point? It involves being one of the custodians keeping Qt at least as free as it is now. It is in the foundation statutes. As a member of the foundation, my goals are exactly the statutes of said foundation. Anything else would be unethical. For example, I suppose I could connive with the other KDE representative and force TT to BSD Qt. However, doing that when the events the foundation was created to prevent have not occured would be unethical. > I suspect you do [give a rat's ass about my > opinion] or this wouldn't have gone on so long. I give a rat's ass about you misleading someone into paranoia. So, it is not your opinion, but the effects of your opinion.

Re: go away troll - david o connell - 2001-08-22

Two final questions of you I would be interested in knowing and I'll wrap up. Do you mind at all if some day the KDE developer community is no more except maybe in name and Trolltech produces the whole desktop and associated applications under the current dual licensing? Do you think that Trolltech should be the one and only tollgate to commercial developers wanting to come to KDE?

Re: go away troll - Roberto Alsina - 2001-08-22

> Do you mind at all if some day the KDE > developer community is no more except maybe in > name and Trolltech produces the whole desktop > and associated applications under the current > dual licensing? Stupid question, but I will try to answer. If 9 guys in Troll Tech can produce KDE, then I will not only be pleased, I will be astonished. Just imagine what the other few hundreds could produce! On the other hand, if Troll Tech hires everyone that works in KDE now and pays them to keep doing it, I will not only be pleased, I will be elated. If you have other scenarios in mind, please share, but these don't seem realistic to me. > Do you think that Trolltech should be the one > and only tollgate to commercial developers > wanting to come to KDE? I think they have right to be a tollgate. After all, they produced code on which KDE is based, and these commercial developers would use it under a non-free license, to produce a non-free product. I think others may have right to be tollgates too, of course. If TheKompany produced a wondrous library that they sell, they are a tollgate, too. In fact, I fail to see how TT could even aspire to be the only tollgate, since anyone can become one, if they have the product to sell. Again, this scenario seems just a meaningless fantasy.

Re: go away troll - Roberto Alsina - 2001-08-21

> You managed to post your reply on the wrong > thread. Just checked. I did not.

Re: go away troll - David O'Connell - 2001-08-21

I agree, you posted in the correct thread. So you have read my response, now how about answering the main points of my reply instead.

Re: go away troll - Roberto Alsina - 2001-08-21

Check the reply that was immediately above this subthread, which I posted *before* I posted the one saying I had posted in the right thread. I intentionally replied to this offtopic thing in a separate post, afterwards.

Qt fits into KDE - KDE User - 2001-08-06

When technology goes into Qt, KDE benefits. KDE can build next generation technology on top of Qt. If KDE does not benefit, then KDE can build it's own version of the technology or better. If QCom API sucks, KDE can make it better. KDE already has KParts so nothing may need to be done. KDE is never dictated by Trolltech. KDE does what is right for KDE. If Qt begins to suck that bad, then KDE can fork Qt. IMHO, KDE long ago accepted that Qt was more than just a GUI toolkit. This is mainly necessary because Qt deals with cross-platform issues. Qt has always been more of a foundation classes for C++. KDE has successfully built its infrastructure and desktop technology on Qt. Why will this change? Your message does not appear to have any real reasoning behind it.

Re: Qt fits into KDE - David O'Connell - 2001-08-06

If QT "sucks" KDE can fork QT but Trolltech can still charge for commercial developers to develop against that QT. Trolltech could/would charge a disadvantageous fee for this fork to "encourage" developers to develop against the official QT instead. Hence the right to fork granted by the GPL is essentially powerless in this situation. Hence Trolltech QT and KDE will never split no matter how bad QT ever gets. Not that is bad now. I like QT currently but QCOM looks very similar to Microsofts COM. Microsofts COM makes for a clumsy and error prone programming model from a C++ developers perspective.

Re: Qt fits into KDE - Bernd Gehrmann - 2001-08-06

IMNSHO QCom is a very elegant and powerful way of dealing with components, in particular the way you can invoke methods dynamically (e.g. from scripting languages). Now, since you are only able to repeat how clumsy and whatnot it is without ever substantiating this claim, I think you have never even cared to look at QCom.

Re: Qt fits into KDE - David O'Connell - 2001-08-06

I have read the overview on Trolltech site. I have looked at some Qt com classes. I listened to Matthias presentation. You are right I am not an expert on QCom. Who is at the moment? Are you? Or, are you quoting the benefits from slideware? I heard the exact same statements you are making about Microsofts COM several years ago. Those advantages are about as good as it gets, in return for a whole heap of complexity from the C++ programmer perspective. However I have a fair bit of experience with Microsofts version of COM and I feel the benefits (I know there are some) don't outweigh the complexity. I know some people like COM, but I have never heard people say COM programming is easy. Thats why KDE dumped CORBA in version 2.0. Because CORBA was complicated and so is COM. Thats what I like about KDE and QT, it had a reasonably simple and elegant programming model and I don't want that to change now. I have bought into KDE/QT and ignored GNOME/GTK on the basis that KDE/QT was easier.. I don't want to change now which is why I am so precious about it.

Re: Qt fits into KDE - KDE User - 2001-08-06

Well, for all our discussions, I agree on this. I too did not like the complexity introduced by CORBA and Microsoft COM. I don't know anything about QCom or how it will really affect KDE though.

Re: Qt fits into KDE - Bernd Gehrmann - 2001-08-06

First, the source code for Qt 3.0 is available for months already, and it's possible to hack and experiment with it. Qt designer is using some of its techniques (but not the qt_invoke stuff). Second, you're not saying which kind of complexity you mean. COM (plus DCOM) is a large collection of stuff, including the component model itself, idl, automation, language bindings, activation. Which is complex? The implementation in Qt 3.0 is 100% pure C++, so there are no idl issues, and there are no language binding issues connected with nested classes for the implementation of interfaces. Its type system is much more general than in COM. I could speculate long what exactly you mean, but your wishy-washy way of arguing doesn't lead us anywhere. Third, KDE has certainly not dropped CORBA because COM is not easy :-) CORBA and COM are two completely different things. In particular, CORBA is designed (and optimized) for distributed computing. COM is optimized for in-process components and was only later extended for distributed components. Qt's components are currently even more different, as they are defined natively in C++ and have to be bridged for other languages. Fortunately, this is quite easy with the information available at run-time via QMetaObject, so no idl is necessary, no marshalling, and no wrapping.

Re: Qt fits into KDE - David O'Connell - 2001-08-07

CORBA and COM are not two completely different things. COM/DCOM and Corba both try and solve similar problems. I admired KDE for its decision to drop CORBA. CORBA has load of advantages that look good on paper but it was difficult to use. No doubt there is people who claim that it was in fact quite easy and if only people were a bit cleverer or read up about it more or used it properly it would have been easier. Since you have seemly done lots of QCom investigation why not tell me why its simpler then Microsoft version of COM. I like the idea of components. I just found writing components under C++ under windows to be a chore and only really productive when using Visual basic. In contrast I found writing application under QT to be quite productive and refired up by enthusiasm for using C++. I am worried that the Qcom will complicate a nice elegant programming model that QT currently has. Has Trolltech come up with a different way of doing things with QCom?

Re: Qt fits into KDE - Bernd Gehrmann - 2001-08-07

CORBA and COM *are* different things, and I have listed some of the differences. Solving similar problems doesn't make seem similar and it doesn't make their usage similar. I have also listed some of the differences between COM and Qt just in the previous posting. Since you refuse to write what you think is not simple in COM, how I can explain what is simpler in Qt other than by writing up the most obvious differences?

Re: Qt fits into KDE - David O'Connell - 2001-08-08

I am sure the pendant in you has a long list of technical differences between CORBA and COM. For most people in the last 5 years they solved similar problems in a similar way and where seen as competing technology. That to most people would make them similar.

Re: Qt fits into KDE - Bernd Gehrmann - 2001-08-08

No. Most (in fact, almost all except for GNOME) people have used CORBA for distributed computing, in particular on the server. The primary use (and the origin) of COM is on the desktop. KDE dropped CORBA because it was found inappriate for the needs of KDE (which is a desktop project). There is no connection with the suitability of COM, and also KDE has never made any statements about the usefulness of CORBA for distributed computing.

Re: depressing - Evan "JabberWokky" E. - 2001-08-06

Or you could say that the component technology in KDE is drawing on 20 years of experience, and is now a mature concept. -- Evan

Re: depressing - ik - 2001-08-06

actually the technology was not invented, but made better than it ever was before. i agree its nothing new, but remember Trolltech works together with Borland, and Borland has a good component model for a long time now (with delphi and c++ builder). QT also already has a component model (do dcop <application> qt objects on a shell eg), they just made it better. I don't see whats depressing in it ...

Re: depressing - Jerome Loisel - 2001-08-07

This is actually a reply to the "trollification" thread of posts which immediately follows. I am replying here so people see it. It is meant as an information post which dispels some FUD read here. Troll Tech cannot arbitrarily change the licences on FreeQt. Any licence changes have meet with the approval of the KDE Free Qt Foundation. That foundation is composed of TT and KDE people. The TT people are in a minority position and the foundation is chartered that way. The foundation was announced in April 1998, over 3 years ago. http://www.trolltech.com/company/announce/foundation.html This foundation is not a simple "good will" gesture from TrollTech which they can conveniently side-step if they so desire. TT has signed legal documents binding them to that foundation's decisions regarding FreeQt licencing for all time. http://www.trolltech.com/company/announce/kde-freeqt/index.html The documents also state that TT cannot simply discontinue or cripple FreeQt versions of Qt. And they state that should TT ever stop releasing new versions of Qt for at least one year, the last version will fall under a BSD-style licence. There is no way for TrollTech to unilaterally revoke those documents. Should TT ever be acquired, the acquiring company would be legally bound by them just as well and would have no way of unilaterally revoking them either. The foundation has the final word, period. So that handles the licencing. Now, maybe you actually believe that TrollTech (or any company) will start releasing crippled versions of its main products just to harm one of the product's most visible and successful users. Maybe you believe they can do that without harming their paying customers. Maybe you believe they will do it anyway for whatever reason. Maybe you believe that when that happens, the KDE developers will blindly start using broken features just to cripple their own project. Whatever. If you really believe any of that (most people here don't), there is nothing I or anyone else here can do for you. Go away. I am saddened to see how much flame-infested FUD had been spouted here. What a mess. Do not reply to me here if you want me to read what you have to say. Or cc to jerome at levinux dot org. I am not at all interested in discussing this subject any further on this forum.

Re: depressing - David O'Connell - 2001-08-08

Your last paragraph speaks volumes. You want your say in public but not willing for to accept comment in public. Is anything said against Trolltech / KDE automatically labeled FUD, flaming trolling. I love the KDE desktop. I like the QT toolkit. I am happier that KDE is built on a GPL dual licenced toolkit rather than QTs previous license. I am not a secret GNOMER trying to stir things up. I normally agree with the GPL as one of the best licenses to use but not in this case. If my long term worries are indeed misplaced I am willing to be argued out of them. To date I am not convinced. What was wrong in using this forum anyway. I could always use a GNOME forum to hear what I want to hear but I don't care about GNOME, I care about KDE. I am familiar with the freeqt licensing and the KDE/QT foundation. I believe I understand it. You mention what happens if Trolltech cripple or try and close of QT and what happens next. Yes, the opensource community would be outraged and QT would fall under a BSD license. I understand that. That is not the scenario I am painting. It is one under which Trolltech stick by the tenants of the KDE/QT foundation and do not try and break them. One day when Linux/KDE is a big success and rolled out on many corporate desktops, a day where commerical development on KDE is a large scale activity. I believe and I won't repeat my points in the earlier threads, that QT will come to encompass much if not the majority of functionality that is currently under KDE (not the code, but the functionality) and I do not believe this will be good. Yes I know as its being pointed out MANY times the stuff would be under the GPL so why should I care. I do, because functionality under the dual license would be a revenue stream for Trolltech would be more influenced by what corporate what and not by what the open source people want. At which point, people mention we could always fork QT anyway so whats the problem. I have discussed why this is just a theoretical freedom at some length in earlier threads. Jerome I don't care if you don't read this. You probably will no matter what you said publicly anyway.You where trying to speak to an audience when you posted here, especially when you posted outside the main thread, otherwise why didn't you just email me privately? I also reserve my right to reply to you in a public space. However if you do really want to take it offline then email me and I will talk privately then? David

Re: depressing - Waldo Bastian - 2001-08-09

> I believe and I won't repeat my points in the > earlier threads, that QT will come to encompass > much if not the majority of functionality that > is currently under KDE (not the code, but the > functionality) and I do not believe this will be > good. It depends you know, we have been collectively wetting our pants about the new rich text edit-widgets in Qt3 (they even have been backported to Qt2 so that we could use them in the next KOffice). We had similar functionality in KDE already, but the Qt version is just way better. On the other hand we don't use QUrl or QSocket because KURL and KSocket are much better in many respects. So we are in a position of luxury where we have two impementations of many things and can pick the one that is best. I don't think that is bad. Cheers, Waldo

Re: depressing - David O'Connell - 2001-08-10

Waldo, I agree for now that the temptation to go with the QT stuff (rich text widget in this case) is desirable. However, maybe the KDE functionality would have eventually met or surpassed the QT functionality. Community developed stuff can be like that at first. It can initially look flaky or rough, but given time can beat the equivalent commercial stuff in functional richness and quality. The short term gain of making KWord stable now means handing over control of functionality from a broad based community to a commercial developer. Choosing to go with the Trolltech stuff effectively kills of the desire for anybody to produce a competing implementation. I often think people are using the mantra that so long as QT is GPLed everything is OK. I am not so sure. The GPLed code that TrollTech produce though is not really a community effort. Do they except external patches? If they do, do they allow the authors to keep the copyright?. I honestly am not sure what the answer to these questions are though, I suspect its no to both. I would draw a distinction between GPLed code that is developed by a wide range of developers and GPLed code that is tightly managed and controlled by one commerical entity. The tight central control of functionality is only attractive in the short term and ties KDE to the interests of a commercial developer whose interests may not always be congruent with KDE.

Re: depressing - Waldo Bastian - 2001-08-10

> However, maybe the KDE functionality would have > eventually met or surpassed the QT > functionality. KDE goes with stuff that works, not with stuff that might work in 3 years from now. Our users want to use a spreadsheet now, not over 3 years. > Community developed stuff can be like that at > first. It can initially look flaky or rough, but > given time can beat the equivalent commercial > stuff in functional richness and quality. Like I said, it's being judged on a case by case basis. But in this case the KDE version had major design flaws. The Qt and KDE version are both by the same author btw. As for the functional richness, we take advantage of C++ inheritance in order to provide KDE versions of Qt classes with enhanced functionality. > The GPLed code that TrollTech produce though is > not really a community effort. No, its a company effort. They are a company. > Do they except external patches? Yes. > If they do, do they allow the authors to keep > the copyright?. No, just like most FSF projects you need to assign copyright for large patches before they will include your patch in their version. > I would draw a distinction between GPLed code > that is developed by a wide range of developers > and GPLed code that is tightly managed and > controlled by one commerical entity. The tight > central control of functionality is only > attractive in the short term and ties KDE to > the interests of a commercial developer whose > interests may not always be congruent with > KDE. Unless you develop everything yourself you will always be in a situation where some of the components that you use have a different vision or roadmap than what would be ideal for your project. In general it has been proven easier for KDE to get the stuff that we want in Qt than it was to get stuff in gcc or the linux kernel. And if you know a way how to convince the openSSL project that they need to maintain binary compatibility across their fucked up version scheme, please let me know. Just the mere fact that a project is community based doesn't mean you can drop by and make the changes that you want. Cheers, Waldo

Re: depressing - David O'Connell - 2001-08-13

>>KDE goes with stuff that works, not with stuff that might work in 3 years from now. Our users want to use a spreadsheet now, not over 3 years. Being pragmatic is all well and good but how far does it go? This has come up in several posts, the primacy of having something that is working now, seemingly over and above everything else. Will KDE start excepting non GPL or even closed source binaries in the future because having something working now is more important than the ideal? Where is the line in the sand? >>The Qt and KDE version are both by the same author btw. This is kind of what I am worried about. The author decided to stop working on his widget in his own time and build a new working version of it within Trolltech. Will khtml be next on the list for the Trolltech developers? I notice that the list of KDE developers who work for Trolltech that you posted on another thread included Khtml authors. For all the FSF goes on about trying to make all software free, they do allow commerical development to take place using their core tools and libraries. Commercial companies may indeed add to these tools but cannot become a tollgate to other commercial developers. Trolltech however can and that is the difference.

Re: depressing - ik - 2001-08-11

> if you choose their implementation, you can not make it better ... (if i understood correctly) sure you can ! this is c++ ! you can inherit QRichText and create KRichText, adding the functionality you missed (KTextBrowser inherited from QTextBrowser ... there are probably way more examples)

Give the .kpr files - Thomas - 2001-08-06

As very often in the kde world, you give a link to the html pages generated by kpresenter, but not the .kpr file itself. Sure, the .html version is what most people will read, but I, for one, always like to get this presentation on the original form to be able to read it with a more user friendly interface and fullscreen. Usually I can get the .kpr by asking the author. Is Matthias' presentation available somewhere ? and if not, could you put it ? thanx !

Re: Give the .kpr files - Carbon - 2001-08-07

Yeah, it would be great if KPresenter included it's own kpr file with html-generated presentations, and a link like "Download this presentation for viewing in KPresenter". Perhaps if the PowerPoint export gets any good, it could include that version as well.

Re: Give the .kpr files - not me - 2001-08-07

What would be really great is if the fonts used were included in the .kpr file. Last time I opened up a .kpr from someone else, it looked so ugly it was unreadable because the default font used by QT when it can't find a font is *really ugly*.

Alternatives - Catalin Climov - 2001-08-06

One may want to check out Korelib, for a lightweight QCom "alternative": <a href="http://www.thekompany.com/projects/korelib/">http://www.thekompany.com/projects/korelib/</a>

COM sucks - Androgynous Howard - 2001-08-06

I really do not know whats the deal with QCom. COM sucks. Even microsoft has found that out by now. COM will not be used by .NET. It is a legacy technology that they will get rid of as fast as possible. Linux will never win the desktop when they keep imitating ten year old microsoft technology. At least they should imitate *current* microsoft technology. I think a platform independent binary format similar to java or .NET is the way to go.

Re: COM sucks - Daniel Molkentin - 2001-08-06

You maybe want the checkout the slide "Why not COM" and following (<a href="http://LinuxForum.dk/2001/slides/ettrich/components/html/slide_22.html">http://LinuxForum.dk/2001/slides/ettrich/components/html/slide_22.html</a>) Greetings, </daniel>

Re: COM sucks - Androgynous Howard - 2001-08-07

I would have loved to take a look at the slides, but the server was down (must be the famous dot.kde effect) when I wanted to take a look. I will try it now.

Re: COM sucks - David O'Connell - 2001-08-06

COM was one of those technologies that I came across in the mid 90s and thought it is was a great idea. It looked great on paper. I was impressed. 5 years later, I am totally disallusioned with it. It is clumsy, still difficult after all these years of use, and error prone way of writing software. Microsoft have been trying to hide its complexity for years behind IDE wizards, MFC libraries and finally ATL. It all just feels like a mess. What am I saying it is a mess! Now QT a great toolkit to date, seems to be fouling its elegant programming model and making the same mistake, ironically just as MS seems to be trying to get rid of COM (well de-emphasising it anyway). KParts seems to be the best blend of easy to use components and a pragmatic programmming model. Isn't this why KDE 1.0 got rid of CORBA. Yes it was flexible just like COM is now but it was just too hairy to use to be practical. KDE rid itself of CORBA in KDE 1.0 to end up embracing COM in KDE 3.0 no doubt.

Re: COM sucks - Chris Bordeman - 2001-08-09

QCom is NOT a derivative of COM, not by a long shot. QCom is much closer to the excellent Borland solution, which is both very easy to use and far more flexible because it takes advantage of language features, so IDL and all that crap is gone. Also, the 'Universal Objects' concept is very simple and flexible. QCom is probably what MS would have done if they had come up with COM 6 or 7 years later. But of course Borland has always trumped MS on technology. Please go and watch the presentation, and check out the size of the QCom code and the equivalent COM code, the QCom stuff is far smaller.

Re: COM sucks - Bernd Gehrmann - 2001-08-06

LOL. Yeah, bytecodes are surely a *current* microsoft technology. That's probably why Pascal compilers like UCSD used it twenty years ago :-)

Re: COM sucks - Androgynous Howard - 2001-08-07

Didn't you know that bill gates invented virtual machines when he was in the kindergarten? Seriously, I know that e.g. smalltalk did most of the stuff that java and .net are hyped for in the 80s.

Re: COM sucks - Krame - 2001-08-07

Yes, you are right. The basic idea of v-table binary standard is simple, but all those apartments, threads, serializing, type libraries, oleautomation etc, are almost impossible to write by hand. It is designed to be used only in high level wrappers - by the way, I read a book about COM+, wherein the author consistently calls C++ a "low-level language" ( VisualBasic is a high level one in this case ). But Linux definitely needs a lightweight, in-process, language-independent component architecture ( did you notice that - Linux has Delphi and Java compilers now, and it became a multi language environment ). I coudn't imagine however, how can platform-independent bytecodes can be put instead a COM-architecture. You mean that all libraries and programs should be distributed as bytecodes and compiled when loading ? I would be bloated, slow code, I think that it is too early for such experiments.

Re: COM sucks - Androgynous Howard - 2001-08-07

>You mean that all libraries and programs should >be distributed as bytecodes and compiled when >loading ? It would be bloated, slow code, I >think that it is too early for such experiments. I don't think so. The performance of e.g. java when used with the Qt bindings as opposed to swing (yuk!) is excellent. And with .net the platform independent binaries are compiled when they are installed, not each time they are loaded. Compiling from a good bytecode to machine language does not yield slower code than compiling from source. Why should it? So I think that this is the right time to move away from platform-dependent binaries. And if you have a well designed language with good runtime type information there is no need for a cludge like com. regards, Androgynous Howard

COM inherently flawed?? - Bud Millwood - 2001-08-07

Microsoft tried to use COM to build an "extensible" OS. Linux is an extensible OS without COM. Why? Because COM uses a binary format and an OO paradigm. It depends *way* too much on close coupling. Orthogonality requires loose coupling, something Unix in general has always had. That's why Unix is so much more extensible than Windows - it's an orthogonal OS. I'd hate to see KDE/QT fall into this trap of coupling things too tightly. One of the first lines of the UCOM docs says "you can never delete an interface". Want to know why? Because it's *too* tightly coupled to everything else. Ever wonder why grep is so damn handy? Because it has a data driven design: single input, single output, universal data representation. No knowledge of "controls" on a component. It can be extended to work in ways its designers never dreamed. Tightly coupled components simply cannot. I do not believe that a data-driven design is the best way to build an extensible UI, but I certainly believe that COM, UCOM and other close coupling technologies severely limit extensibility. (Interesting because that's what they claim to be good for). The only gain is for the short-term, where apps seem to know all kinds of things about each other. They *do*, and that's the problem. - When you only have a hammer, everything looks like a nail.

Re: COM inherently flawed?? - Bernd Gehrmann - 2001-08-07

grep is not dawn handy. It is only useful for line-oriented text files. As soon as you have to handle structured data, it completely fails. For example, for xml data, sgrep is much more useful. For searching in a database, the respective database APIs are more useful. So your example is flawed, and so is your argumentation. For a better example for extensibility of GUI programs, compare Konqueror or Nautilus with classical Unix programs like netscape, the CDE file manager or similar stuff. Then come back and repeat your myth about loose coupling.

Re: COM inherently flawed?? - David O'Connell - 2001-08-08

For more structured data use awk.

Re: COM inherently flawed?? - Roberto Alsina - 2001-08-08

Get a grip, awk is line oriented as well. It takes ungodly coercion to make awk take most kinds of structured data (as the XML example). Ok, I will byte: are you unfamiliar with the concept of structured data, or are you unfamiliar with awk?

Re: COM inherently flawed?? - Mike - 2001-08-09

Awk is record oriented, not line oriented. Furthermore, awk deals with tabular data, not just lines of text. And structured data can be encoded very easily and conveniently in tabular data, and awk is very efficient at processing it. But your response is indicative of a general disease in the industry: people don't learn to know how to use their general purpose tools anymore. Instead, we get an awful profusion of special purpose tools and overly complex standards.

Re: COM inherently flawed?? - Roberto Alsina - 2001-08-09

"Normally, records are separated by newline characters. You can control how records are separated by assigning values to the built-in variable RS." This is exactly the same as being line-oriented. It can be called record-oriented, sure. But it can not handle nested data structures very naturally. And the given example was XML, which is nothing but nested structures. Ok, anything can be encoded to be easily handled by AWK? Yes. But XML is already encoded. If you need to encode it so AWK can handle it, then it is not AWK that can handle XML, is it?

Re: COM inherently flawed?? - Mike - 2001-08-10

"But it can not handle nested data structures very naturally." Of course it can, in the same way systems like Prolog or SQL can represent structured data easily and conveniently. "But XML is already encoded. If you need to encode it so AWK can handle it, then it is not AWK that can handle XML, is it?" I did not claim that AWK could handle XML easily, I claimed that it could handle structured data easily (not to be misunderstood: AWK has its limitations as a language, but its tabular parser is fine). Nothing really can handle XML easily because XML is not a particularly convenient representation of structured data; what XML has going for it is that it makes the structure blatantly obvious to even the most uneducated user--XML, after all, has its roots in document formats. As I said before, the analogy between AWK and XML is a good one because it is indicative of what's wrong with a lot of software being designed in industry these days: people build unwieldy special purpose solutions (like XML) because they simply don't understand how to use more general purpose tools effectively. "This is exactly the same as being line-oriented." Line are lines and arbitrary records are arbitrary records. The two are different. The built-in awk parser is record oriented and assumes a tabular data model. Using that data model, you can easily represent nested data structures in a variety of ways.

Re: COM inherently flawed?? - Roberto Alsina - 2001-08-10

Line are lines and arbitrary records are arbitrary records. They are, however, functionally identical in AWK case. All AWK does is use a record separator. Turning the record separator into newlines is a 1 line command (use sed or AWk, at will ;-), and it will convert any file AWK can parse into a "a record is a line" thingy. I did not claim that AWK could handle XML easily, I claimed that it could handle structured data easily Ok, just read the thread and see where things came from, then ;-) David O'Connell started babbling about how handy grep is because of its data driven design, and Bernd Gehrmann mentioned that grep sucks when you have to, for example, parse XML, since it is line-oriented. Then David said that for more structured data (XML being the only one mentioned), AWK should be used. I simply replied that AWK is line-oriented (ok, I admit it ain't, I still say it is pretty much the same thing, functionally), and that it takes ungodly coercion to make it handle the XML example. So, you see, AWK was only brought up as a way to handle XML-like data, and when you later started talking about how AWK can handle structured data, if it is encoded in a way that AWK can handle (doesn't that ring a tautological bell? ;-) So, yes, you didn't say AWK could handle XML. David O'Connell did. And I replied to him about that. And that is what you replied to. I'd say, let's give it a rest. I am pretty convinced David O'Connell is just a troll, and honestly, I don't give a damn about AWK.

Re: COM inherently flawed?? - Bud Millwood - 2001-08-13

David O'Connell wasn't babbling about grep being data driven. It was me, Bud Millwood, trying to spur a discussion on GUI design. And I was not trolling, I was stating something that I think is very important to the future design of KDE. My post was extremely terse, but if you'll read the reply by Chris Kohlhepp, you'll get a broader picture of what I was driving at.

Re: COM inherently flawed?? - Chris Kohlhepp - 2001-08-08

I would like to elaborate on my colleague's posting "COM inherently flawed". Also, if you have not already done so, please read David O'Connell's reply to "go away troll" at http://dot.kde.org/997082845/997089185/997089678/997092359/ He has some valuable insights. I would like to look at how COM came into being, why Microsoft chose this path, and why many of us where disillusioned by it. But before I do, I would like to discuss three basic system analysis concepts. Firstly: orthogonality. Loosely defined orthogonality within a system refers to the ability to arbitrarily combine system components regardless of their nature and design. Consider the architecture of Lego blocks. Each block has an indentation on the bottom and a corresponding knob on the top. In this fashion I can fasten a Lego propeller to the top of a Lego head and make - a propeller head. The peculiar thing here is that the propeller was designed to work with a Lego aircraft, not the top of a Lego head. Unix operates much in the same fashion and owes this to the universal nature of its design in which processes interact with one another through an interface that exchanges text based parameters through simple interprocess mechanisms such as standard-in and standard-out. Example : a TCP data stream may be redirected to a script by the Inetd super daemon and then fed to an X-based GUI component by said script. The Inetd super daemon need not have any knowledge of the specifics of the data, the inner workings of the script, or the GUI. Secondly: Loose Coupling. Loose coupling refers to the degree to which a component is independent of the characteristics of another component. Our Lego head only interacts with the attached propeller through its little knob. It is not allowed to manipulate the specifics of the propeller. For example, if our little Lego man - or woman - was alive he/she would not be allowed to change the pitch of the propeller blades as the knob/indentation paradigm does not provide for this. While this is a limitation on the use of the propeller, our Lego head won't be impacted by any design changes to the propeller blades. Thirdly: Data Driven Design. In a data driven design, the nature of the data dominates the architecture of a system, i.e. how components of the system interact and what components are conceived in the first place is a function of the data. UNIX has traditionally favored a straightforward data oriented design in which processes exchange textual data via pipes, sockets, and other interprocess mechanisms. The nature of this interface paradigm is both universal and non-specific. To briefly refer to our first example, this design is responsible for the fact that the developer of Inetd need not be aware of the script and ultimately the GUI with which it is to interact. This paradigm stands in stark contrast to object oriented methodologies in which objects or entities manipulate specific states and attributes of other entities in the system. Such objects gain the advantage of being able to exploit the specific characteristics of the entities with which they interact. Example: If our Lego man/woman could manipulate a "ChangeBladePitch(Degrees Clockwise)" API on the propeller, he/she might be able to make more efficient use of said propeller, but the interaction would have ceased to be universal and non-specific. If ever a new propeller is fitted to the same Lego head, a propeller which uses radians to set the blade pitch instead of degrees, then the interaction between head and propeller is broken. Thus once the interface to the propeller has been published, it must never be altered. The very use of representation specific data ( here angles in degrees ) across subsystem boundaries has rendered the interaction non-universal. The decision when to use which methodology largely hinges on one factor: change and the ability to predict change across subsystem boundaries. The designers of "Awk" didn't know that the output of their program might years later be piped into a 256 color KDE window. They therefore had to design to a universal interface. Analogously, the engineer designing the propeller and fitting blades and drive shafts must concern himself with the specifics of each component within the context and scope of the subsystem in question. The fundamental design of Windows and Windows NT in particular is essentially object oriented. Applications manipulate the state of the operating system and the computer through a set of API calls to OS components. This is in stark contrast to Unix where sometimes the line between operating system components and application components is very blurred. Is "Awk" an application or part of the OS ? The line between application components and OS components is drawn very clearly under Windows. Until the introduction of COM, the basic issue of application interaction, simply was not addressed at all. If you wrote a network application and I wrote a printer tool, the mode in which our applications might possibly interact and perhaps enhance the overall functionality of the operating system was - NOT. We both invariably had to turn to the API furnished by Microsoft to communicate at all. Further, because the interaction with the operating system is highly specific and non-universal, he who controls the operating system API layer ultimately controls the application layer also. The design inherently does not scale well. As this became apparent to the software industry, a "patch" was needed. I call it a patch because I regard COM as poor fix to a bad design - albeit purposeful, but bad nonetheless. COM purported to give applications and components the ability to interact universally but its very object oriented design and highly representation specific ( say binary ) interface ensured that universal interaction never happened. In fact the only application suite to achieve a high level of integration between individual components and the operating system is Microsoft Office. Microsoft sold the software industry the illusion of universal component interaction at the application level while ultimately retaining control over the application level by controlling the operating system API layer. Surprised ? Of course today's applications require complexity beyond line-based standard-output redirection that we have concerned ourselves with so far in our simple "Awk" example. A comprehensive component framework must address issues such as application embedding, concurrency, synchronization, etc. Nonetheless, the design goals of universal data representation, loose coupling, and orthogonality are imperative if the framework is to be scalable. Some years ago I worked on a project which utilized a component framework designed for VME backplane systems which housed multiple processor cards, each card running its own flavor of UNIX. The component framework in question was both scalable as well as platform independent, provided for synchronous and asynchronous message propagation, and achieved this seamlessly across process boundaries as well as across different hosts on the same VME backplane. At the time, I lacked the systems analysis background to fully appreciate the depth of the design the framework had to offer. The framework in question is called SigMA ( Signaal Modular Architecture) and is fielded on large scale national defense systems. It is listed in Jane's Defense Glossary : http://www.janes.com/defence/glossary/glossi-sl.shtml Unfortunately public links to the framework are limited.

Not sure - renoX - 2001-08-13

I think that your comparison is a bit fuzzy. Take the ChangeBladePitch(Degrees Clockwise) example: you add additional control in one case, and you say that it adds additional coupling, well duh! Modifying Degrees to Radian breaks the coupling and what's your point ? Let's say you use the Unix POV with the same capabilities otherwise the comparison is absurd. So you have one program A which output Degrees number in ASCII, and another program B which parse the number from its standard output. You change A to output Radians instead of B: congratulation you silently broke the application because even if B can continue to work the result is wrong. So you have to update B so that the result is correct again. I fail to see what is your point, practically I mean.. In fact I have some difficulties comparing Unix-style pipes and Windows-style components: for me the "Unix-style pipes" is usefull mainly for text processing/script whereas Windows-style components is aimed at for example embedding a spreadsheet inside a word processor (I know COM is more than OLE). I don't really how you could do the "embedding" style with pipes,redirection, etc.. But maybe I don't have enough imagination :-), I heard that Plan9 push even further the traditional Unix-concept: the filesystem can now "contain" windows much-like /proc contain processes. Does someone more knowledgeable with Plan9 knows if they have something "similar" to COM?

Re: Not sure - nap - 2001-08-14

>Does someone more knowledgeable with Plan9 knows if they have something "similar" to COM? No way. The Plan 9 way of exposing a interface is to just export a filesystem. They try to make every system service look like a filesystem with files in a tree hierarchy. Rather elegant I must admit.

Hello "Duh" - Chris Kohlhepp - 2001-08-22

> well duh! Glad to see you can articulate your thoughts ! > You add additional control in one case, and > you say that it adds additional coupling, > Modifying Degrees to Radian breaks the > coupling and what's your point ? The point is not in the details of this example. Please look at it the context of the systems analysis principles illustrated. I'm not arguing against binary representation in general. I am contrasting the use of specific interfaces with the use of universal interfaces and where to use which. The more universal the interface, the less efficient it is at manipulating the object in question, but the more readily it will interact with other objects, even those that were not designed for it. The more specific the interface, the more efficient it is at manipulating particular aspects of the object in question. Specific interfaces are necessary for the operation of any system, but when you cannot predict with whom you will interact with - as is invariably the case when embedding a component "x" in application "y" - you will want to make your interface as universal as absolutely possible. The less specifics you make use of in your interface, the more universally usable it will be. But lets dive into the details of the example anyway. Since we got off onto that tangent > So you have one program A which output > Degrees number in ASCII, and another program > B which parse the number from its standard > output. You change A to output Radians > instead of B: congratulation you silently > broke the application I like your style. So cynical :-) > I fail to see what is your point, But at least you admit to missing the point. Let's keep this professional, shall we ? Ok, yes, you are a right about the application being broken by changing the parameters from Degrees to Radians regardless of whether you encode the values in ASCII or binary. The use of Degrees or Radians makes the interface specific, a binary representation would merely render it even more specific. For example, if you represent the value in binary on an Intel platform and sent the value over a socket to a machine with different byte ordering or alternatively from an 32bit platform to a 16 bit platform, then the interaction is broken even if both ends speak Degrees. Of course you can do the necessary translations (network byte ordering, etc.) provided you know who you talk to on the other end - if you don't you can't. The other practical problem with most binary interfaces, be it a simple LIB or a COM object is that they are not readily extensible. For example you will need to publish an altogether new COM interface if you wanted to add a Radians based function to an existing Degree based function on your object. This impacts every user of your object. Text based interfaces tend to be more readily scalable.

Missing point? - Outsider - 2001-08-09

I'm not a KDE developer, but I am planning a QT app, because it's nice to program and I want it cross-platform. Some of you people are missing the point when you say "why should QT do this when KDE already does?" Maybe KDE does but that doesn't help me a whole lot. Wouldn't it be nice if a lot of Windows developers started doing QT? Then when people compare OS's, they can discover that outside of Microsoft apps, they can run the same software on whatever platform they choose. Don't you think that would help break Microsoft's monopoly on the desktop? (Incidentally, I'm planning to GPL on the Linux version, and on other platforms work out the closest thing to GPL that I can.)

For Help : QT/Embedded on StrongARM - Tim Zhao - 2001-08-18

Dear All: I am going to porting a internet browser into StrongARM assabet. My cross compile tool is BlueCat. I have cross-compiled some QT/Embedded applications. And download them into assabet board. On the touch panel , the windows ,the buttons are showed correctly. But when I touch the panel with pen ,there is not response at all. The cursor has no any actions at all. But MicroWindow application works well. Do you have such expierence ? I will appreciate if you can provide some infomation to me. Thanks Best Regards. Bingqi Zhao.

COM, VB and ease of coding - Ignorant non-contributor - 2001-08-17

I haven't used COM myself, only talked at length with someone who has, but... I have the impression that a COM component on Windows isn't easy to code in C++. However, its saving grace is that a COM component is easy to use from VB. Thus, the hard work of a C++ coder makes life easy for VB coders thus encouraging code reuse. Can anybody confirm this? If so, doesn't this mean QCOM is not right for KDE ON ITS OWN? ie there needs to be something in the role of VB (python? kscript?) which takes advantage of the QCOM components and is easy to use.

Re: COM, VB and ease of coding - Anonymous Coward - 2001-08-29

This is mostly correct. Only "mostly" because there is a template library which makes it much easier to write COM components in C++, so complexisty is not that much of an issue. COM really shines when you are using (as opposed to writing) components and get to just click on the method you want. This can be done in C++ now too, I believe (someone using the latest VC++ please fill us in). To return to the topic at hand, QCOM *can* be the right thing for KDE on its own if the tools (KDevelop?) are updated to take advantage of the QCOM components. This is true for C++, and it's also true of the script languages. (Q)COM creates a new abstraction of a "component", and one of the ways to leverage this is to make the tools aware of this new abstraction. Hope this helps.

Re: COM, VB and ease of coding - Rayiner Hashem - 2001-10-02

Actually, it is really easy if you stick to the basics of COM (like DirectX). In essence, COM is just a C++ object that exports virtual methods. (In VisualC++, that is actually the implementation, a C++ object and its vtable). I think all the arguements going on about COM being flawed are crap. The stuff that was built around COM (DCOM, OLE, etc) may be crap, but the internals are pretty elegant. Mozilla uses something like COM for a large part of its architecture, and it works pretty nicely.