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