KDE 2.0 Technology Overview

Recently, there was an article about a KDE 2.0 Technology overview here on Slashdot. Unfortunately, the article it linked to was missing some details and didn't give some necessary information, which caused a huge number of complaints and misunderstanding in issues like CORBA, DCOP etc. Now mofset has posted an updated Technology Overview with all the explanations about what's going on with KDE 2.0, CORBA, DCOM, KSycoca and other terms. What do you think?

Comments

Re:I'm still nervous.

[evilpenguin]

DDE doesn't do applications embedding. That's OLE. DDE is a horse-dung IPC mechanism that sends messages in the message queue to EVERY RUNNING APPLICATION on a Windows boxen.

The expense of ORB calls can be very similar to the cost of initially calling a shared lib, but from then on shared library calls will tend to be much faster than ORB calls. This difference gets exaggerated when a lot of data is passed in the call and/or in the result, because all of it has to go through the transport representation conversion and data transmission.

Now, while I've done a fair amount of IDL/ORB/IIOP stuff in my time, I haven't looked into the KDE code at all. If they did it right, they should have a lightweight IPC API that can use a variety of transports and that will autmatically use the much faster local *nix capabilities on the local machine, and the moderately slower Xlib capabilties between X-displays, and use CORBA for anything more divergent. Point being the app writer should not have to particularly know or care.

CORBA is VERY time expensive, esp. when you're talking about things that have a dramatic influence on the perception of speed, like redrawing windows.

Often the user's feeling of performance is based more on finding the right place to stick the delay than in having the fastest end-to-end time for a process.

Case in point: I once eliminated hundreds of user's complaints about a slow system by slowing it down about 40%. We had a PowerBuilder (ugh!) front end to a client-server application. One of the forms had a pick list that was HUGE, populated by a stored procedure call. That call would often take 3-4 minutes to complete. Users went bananas because they got the good olde Win 3.1 hourglass while the pick list was populated.

I changed the code to pick up one record at a time from the result set and insert it in the pick list rather than make the single "all at once" call. It actually took 2-3 minutes longer to fully populate the pick list, but the users never got the hourglass and could start working the form right away. Zero complaints.

I guess what I'm saying is, KDE is a UI. As such, it has to focus on user issues, not technological issues. I am 100% a technology guy. I'd rather satisfy myself that things are done right than satisfy users. Even so, the KDE folks want people to use their software. That means they have to address user issues first and put architecture second. It seems to me they are doing a danged fine job of balancing these concerns.

This looks seriously neat!

[jd]

KDE 2.0 looks very nice, and I'm glad the developers are using technologies which are practical, rather than using just the "glamour" stuff. (eg: Using CORBA =when appropriate=, rather than for everything under and over the sun.)

I've tended to shy away from KDE, after KDE 1.x proved very slow on my box. However, I'm definitely going to give this a try, and see how it performs now.

This looks like the way to go ...

[LizardKing]

Having recently compiled a snapshot of KDE 2.0, I can say with some conviction that it's a Windows killer. The usability is much better, and the optimised build much smoother. Having had to do some testing of Unix apps running under the Windows Reflections X server, I'm suprised at just how poorly NT performs when more than one application is open. (I mean Windows apps like Outlook and Explorer, not the Unix apps).

The loss of Mico as a dependency for KDE 2.0 is also a good thing. Mico is just too large for it to form the basis of a component model, the only place it really shines is truly network transparent CORBA apps.


Chris Wareham

A different take on things

[itp]

This article sounds a little bit like spin to me. Not trying to start a flamewar, but here we see a bit of the architectural advantage the Gnome folks have. Writing a completely new ORB (ORBit) might have been a bit 'o work, but it's paying off for the Gnome project, while KDE still struggles with MICO.

Every application supports a basic set of IPC operations for communicating to other applications, and it is not reasonable to expect *every* application to link to any ORB.

I'm no expert, but I'm not sure I understand this. If you're already going to have the ORB running, and you've got the libraries in memory, how much of a price do you pay having 100 applications using CORBA vs. 1 application using CORBA and 99 using some other mechanism?

--
Ian Peters

Re:A different take on things

[itp]

First off,

I'm not trying to flame here, ... "some men...you just can't reach." Face the fact if you can that there is room enough for two or more A+ desktops.

You're doing a poor job, then. FYI, I in no way deny the existence of two very high quality desktop environments. This despite the fact that I choose, for my own reasons, to use, support, and develop for Gnome. In much the same way that I, as do many people, choose to use GNU/Linux, while acknowledging that there are many "A+" OS's out there (the *BSD's, for instance).

Now, to the meat of your comments.

I'm not trying to flame here, but what architectural advantage is there when your model won't allow a change in direction? ORB was not working out for everything KDE wanted it to do. So they did the sensible thing and came up with something else that was smaller, faster and easier to use, and kept ORB for those tasks where it was needed.

I'm afraid we've miscommunicated here, and I suspect the fault was mine. What I was trying to say was the the Gnome project seems to have a lead in working out these architectural issues. While KDE turned out a highly polished set of applications, the Gnome project seemed to focus on a broader framework initially. Here it seems to pay off for them.

It seems to me that ORB has become the holy grail of Gnome. A couple of weeks ago the so-called abandonment of ORB was touted by the Gnomies as *proof* of KDE's inferiority.

First, a technical note: I believe you are confusing the terms ORB and CORBA. Second, I certainly hope that you didn't hear anyone from the Gnome project saying that this is proof of KDE's inferiority. Statements such as these only serve to undermine the spirit of cooperation we'd all like to see.

Now that mosfet sttempts to correct a gross misunderstanding, you say it sounds like spin-control.

Yes. To me, this sounds like a way to put a nice face on some technical issues they were unable to resolve. This is merely my opinion, being shared in a forum which invites people to share their opinions.

--
Ian Peters

KDESoft!

[Signal 11]

KDE is not the next Microsoft. They cannot, and will not develop "proprietary" protocols because of the way open source works. It's obvious Gnome and KDE are going two seperate paths. Rather than complaining about this, we should be commending both groups efforts in the GUI arena.

The scenario alot of slashdotters believe (which is not addressed in the article) is that KDE is somehow going to become the de facto GUI. Well, due in part to the paranoia that alot of us have as well as the fact that the two groups have seperate goals, that isn't going to happen. One may be more popular than the other (How many people still use fvwm instead of E?), but because of open source (Yes, Richard, I know it's not free software..) it's impossible for either gnome or kde to co-op the other.

Besides, if that happened the paranoia many of us share in this community would quickly fork the tree and continue along a "free" path, essentially killing the old version.

So relax - there is NOTHING to worry about in this area. And while I'm up here on this soapbox - Redhat is OK too - so stop complaining about them becoming the next MS too.

--

Re:XML

[jilles]

"XML is not a programming language"

No, you are right but you could use it to model a program just like you would model other datastructure. I have often wondered why we still have to store our precious source code in flat file databases (ascii files). I don't see any apparent reason except that many people like to use text editors to work on their source code. Because of this much syntactic sugar is put into the languages at the cost of structure and readability.

Treating a program as a DOM instead of a large set of ascii files scattered in multiple directories would allow for really cool tools. I'm thinking of code transformations, changing an identifier name and have the effect of the change spread through the whole program (no references to non existent stuff), no more syntax errors (the DTD prevents illegal edits), and a whole lot more.

Neato. But...

[Enoch Root]

This all sounds really neat. It's amazing to consider that some of these ideas are brilliant, yet simple, and never seem to make their way as simply into the corporate world than they do in the Open Source movement, where a program is an end in itself (as opposed to a marketable product) and tools like CORBA are a mean to an end.

However, I wish there was some effort being done in making the various desktop environments intercompatible... I'd love to see development aimed at making it easier to code stuff that will run as smoothly on Gnome and KDE.

Linux definitely needs that sort of interportability, but unfortunately it seems that development of applications for Linux is mostly modular, which leads to various branching left and right. It's a good thing Gnome and KDE aren't branching.

Hackers of the world, unite?
"Knowledge = Power = Energy = Mass"

There is no "standards" issue here

[JohnZed]

Last time this subject came up, a number of people lamented the idea that KDE would abandon the "open standard" of CORBA for a new approach. I'm glad Mosfet has cleared things up a bit by explaining that libICE is equally a standard which, in fact, is a lot more common in the Unix/Linux world than CORBA.
What I find really strange is the argument that GNOME's use of CORBA makes it more standards compliant than KDE. Don't get me wrong, if ORBit works well for this application, that's fantastic, keep using it. But ORBit actually implements only a very small fraction of a modern CORBA standard (MICO is fully 2.2 compliant with all the bells and whistles, so it is a slug in terms of performance), and does not yet provide C++ or Java bindings. Essentially, it's a handy, GNOME-only solution, like KParts is a handy, KDE-only solution.
--JRZ

Comments on CORBA

[Laxitive]

OK. Lots have people have posted messages to the effect of "In a good ORB, the overhead of a method call to an interface is almost the same as the library." First of, there _is_ an overhead, but we can ignore that.

The big problem with CORBA is _bloat_. If you implement all your internal embedded interfaces with CORBA, it leads to really unweildy sizes.

The server for a simple CORBA demonstration (one structure and 1 interface defining 1 method), compiles to ~70K.

The same functionality, if implemented with sockets or shared libraries, will probably take up less than 10K compiled.

This is the kind of overhead you see with CORBA. Putting CORBA into every nook and cranny of your GUI implementation does not make it 3r33t.

There is a time and place for CORBA. It's not for IPC, and it's not for embedded controls. It's best suited for large distributed applications.

The K people have made a very practical decision by choosing shared libraries.

-Laxative