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

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

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.

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.

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.

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.

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

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?

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.

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?

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

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

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?

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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?

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

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.

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

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

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 !

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.

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

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.

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.

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.

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.

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

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.