Slashdot Mirror
KDE Looks Ahead
An anonymous reader pointed us to an article thats currently appearing at Linux Today regarding the future of KDE. Its essentially a report from KDE2. Talks about their new com solution, organizational changes and more. Its an excellent update on some excellent software.
.. read this .
I'm sorry to say that I have a bad feeling after reading the plans for KDE2. It sounds like KDE is becoming more and more like commercial software.
If KDE moves away from standards (CORBA) and encourages developers to use its own (open, but KDE-specific) shared libraries for communication between the applications and the desktop, then we can forget about building applications that work well under both KDE and GNOME. Sure, it could still be possible to run the application under both environments, but not efficiently and not with all the nice features that each environment offers. What happened to the nice statements about convergence and interoperability between the two major desktop environments?
Both DCOP and Kanossa would only work under KDE, and it would be extremely difficult to implement anything compatible in a GNOME application (it could be similar, but not directly compatible). That is, unless you link your software with the KDE libraries, but then again the developers would then be tied to KDE. Is it really necessary to give away this freedom (not linking with KDE libraries and Qt) to gain some efficiency?
I find it really distressing that KDE is moving away from CORBA. For one thing, the possibilities of distributed objects are endless. And Microsoft already has such a thing in their DCOM model (which sucks, I know. But still, its there).
Why couldn't they just swallow their pride and use a faster ORB? Say ORBit? I know that there are no C++ bindings, but that's better than falling back to a shared library implementation! The fact is that MICO (which they were going to use) has been pronounced too slow to be usable by everyone who's tried.
And forget interoperability with this thing -- there's no technological basis to make GNOME and KDE interoperable now.
-- Slashdot sucks.
For those of you familiar with KDE, you'll know it's component model is broken into two parts: KOM (KDE Object Model), and OP (OpenParts). The KDE Object Model is still going to be corba, but the embedding UI component part (OpenParts), will be done using the new scheme. This is similiar to both Gnome and COM.
Sorry about the previous flame... bah, I've been on slashdot too long, I didn't even READ the rest of the post. Where did my attention span go... what was I looking for again?
Just redirect that flame to someone who does argue that XYZ is the One True IPC Mechanism...
I really wish we could delete or moderate down our own posts, just someone else moderate it on down at least, ok?
I've finally had it: until slashdot gets article moderation, I am not coming back.
OK, here's my take on it.
Unix apps are integrated. It's called a pipe. Crude in its native shell syntax form, but when the pipe is used behind the scenes, it becomes very transparent to the user. Some people like this, and use something like Emacs that integrates lots of bits of Unix with each other. Some people don't like it, and only use it occasionally from the shell.
The main interesting thing about the pipe is that it sends linear data back and forth. The second interesting thing is that the pipe connects applications.
In windows, something different happens. Linear data is considered obsolete. Data is expressed as an object. Pipes work badly with objects. Simple objects could be serialized and sent over pipes, which is slow. Complex objects can't even do this, as some structures are very hard to serialize.
Furthermore, windows doesn't join up applications, it joins up objects. Objects send objects to each other. The file browser object sends a file object to the uncompress object, rather than the filebrowser app reading a file, piping the file to the uncompress object and waiting to get the uncompressed data back.
Why the difference? Two reasons. Firstly, GUI programming is VASTLY easier with a comprehensive object oriented framework. Once you start working with objects, it becomes easier when everything is an object. And once everything is an object, it's easy to integrate everything with everything else.
Secondly, it does seem that new computer users are more data focussed than function focussed. When my mum has a document on her computer she expects to be able to read it by performing certain actions. She expects to be able to use the same actions if the document is compressed. Whether or not you consider this a reasonable expectation will place you in one of two different camps in the UI world.
If you agree that this is reasonable, it becomes sensible to put a decompress object in the document viewer, so that it can handle such data seamlessly. In fact, you might even decide to put the decompress object in the file, so it could decompress itself at will, in any context. That would depend on the file, the application and so on.
If you don't agree you'll be aghast at all this. Your draw will drop at the idea of bloating a file by adding functionality to it. The data should remain a nice simple blob of bytes that can be fed through nice simple functions one by one.
I like both. They are radically different approaches that work in radically different solutions. I like editing config files with vi. I like editing emails with Eudora. I would HATE to
do it the other way round.
DCOM/COM (or equivalents) make patent sense to me. To ignore the power of distributed object systems seems daft. There is alot of head-in-the-sand 'ASCII always worked for us' attitude from the Unix camp which I think is stupid. But it is also stupid to think that just because you've gone to the trouble of creating a great object framework that you should put everything in it. Microsofts 'management console' app is a great example of unwanted objectification.
Like much of computing there are two camps, both of which see only the good points of themselves, and the bad points of the opposition. Neither camp is a great solution for everything, but both camps are too pig-headed to co-operate.
Already, I see KDE apps like Kwrite that accept no command line arguments, so I can't launch it with any specified options. Gack. Just because Kwrite can be passed a file object from Konqueror, why should you prevent it being passed data in a stream from the shell?
On on the other side, there are plenty of people who are opposed to C++ on principle, who think Unicode will go away if they ignore it, and who can't see the point in multi-threading.
-----
Having worked with CORBA for the last eight months, I can say that the KDE 2 direction seems to be the right one. CORBA is a simple, elegant concept seriously let down by its implementation. The language mappings for C++ are horrendous, and the whole thing has that `designed by committee' feel also suffered by Motif.
MICO and the other ORB's that I've used all suffer from being bloated middleware that hinders the development of efficient ditributed applications. In fact, I used a proprietary system that used the same basic concepts as CORBA at my last job. Despite the discomfort I felt using a proprietary system, it did offer a far better API than CORBA.
DCOP looks like it will build on a very efficient foundation, namely RPC and libICE from the X Window system. My only worry is that C++ isn't the best language for implementing such systems, so I hope they are sticking to C for this library.
Chris
Chris Wareham