KDE Looks Ahead 182
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.
Re:KDE, browsers, and reinventing the wheel. (Score:1)
It took a little bit of persuading (accepting cookies) but I've got it logged in now and posting quite happily as me - this is written using Konqueror.
At the moment the annoying thing is that it doesn't do javascript - there are one or two sites I frequent, and one of work's products is very javascript-intensive, so I can't use it for exactly everything yet.
OTOH, if KDE2's Konqueror produces the goods and does support it properly & stably, then I'll be more than happy to abandon Mozilla and Netscape altogether...
In the Open-Source world, who do we ask for a browser that's both fully-featured AND stable? Erm: DIY
Re:Some comments... (not supposed to be flamebait) (Score:2)
DCOP: It's basically a wrapper around libICE, which is a well known X11 standard that just didn't get as much attention as it should have, and it's entirely possible to build a wrapper that transfers requests from other systems to DCOP.
aRts makes linux *the* multimedia-platform (Score:1)
Why doesn't anybody talk about this yet? aRts will obviously propell linux towards being the multimedia-platform #1 of choice (at least concerning sound). It is even near to outperform BeOS. And no: it's not vapourware because it has been developed since two years now and is rock-solid-stable. And yes: even GNOME considers to use aRts as it is so much better than anything else out there (and no: ESD looks like parts of a bee next to a plane if you compare them).
Stefan Westerfeld demonstrated aRts -- his next generation network multimedia framework. aRts uses a very modular system of CORBA components to achieve nearly limitless potential for multimedia playing and manipulation. KDE 2.0 will use an optimized subset of aRts to handle all audio playing. Future releases of KDE will then use the more advanced video and audio/video manipulation abilities available in aRts. The aRts server is incredible. It's synthesis and filtering abilities are leagues ahead of anything yet found on Unix.
Perhaps it would help to mention that this KDE-2-multimedia-framework will *still* use CORBA?
AC
Re:More rebuts (Score:2)
"they use QT"
This is a criticism? Gnome uses QTK. What's the difference? Both are Free and Open. Both are of high quality. One just doesn't have a "G" in front.
"they use C++ to write the core libs"
So what? C++ is an open, standardized and freely available language. Every bit as much as that other language used to write the core libs of Gnome. GUIs use object-like constructs, messaging, subclassing, etc. It makes sense to write GUIs in an OO language.
"they abandon corba"
They did not abandon CORBA. They just stopped using it for the GUI.
"they critize gnome left and rigth"
BFD. You're criticizing KDE but you don't see me crying about it. If it's okay for Gnomies to malign KDE, then the opposite is fair game.
"well, it was nice competing with you KDE."
ROTFL!!! Anonymous cowards now have the priviledge of deciding which desktop will win or lose?!? Make me laugh any harder and I'll start shooting milk out my nose (visual mercifully deleted). This is not a zero-sum game. Both Gnome and KDE can win. But if you insist on only one desktop for everyone, then you will be the one who loses.
Re:It's not Windows Registry (Score:1)
All you need to do it make it transactional, and also mirror two registries....and you'll have a safe and fast 'database' type way to store and access persistable information.
Re:KDE TWO Conference Sponsorship (Score:1)
mouth.insert(money);
But I wasn't raised on C as everybody else, or so it seems.
"Open Source. Closed Minds. We are Slashdot."
Re:COM...OpenParts... sounds great but... (Score:1)
However, that being said - I do like the elegance and ease of Java Classes. Even java needs IDL etc when it comes to RMI, CORBA etc.
Is it just me or are many Linux developers today (Score:1)
I'm talking about the guys who know what they're talking about and do the core development for Gnome and KDE. Hell, even netscape developers are following MS with xpCOM and their little registry.
I mean, KDE looks very much like Windows, even the dialogs, menus etc all look more like windows than anything else.
I'm actually kind of glad everyone's gotten some sense and are going with COM/CORBA/KOM/WHATEVER. It's about time Unix ppl stopped thinking of ASCII or executing scripts. Componentisation (as microsoft has found out) is a very successful technology.
What a web we weave
Re:Dittoes (Score:2)
But I absolutely agree with you on Qt's productivity! Now I couldn't write a email client in an hour, I'm not that good yet. But I've thrown away dialog editors because setting up layouts and widgets by hand is almost as fast. When QtArch gets upgraded to Qt 2.0, then you will have something very close to a Free RAD.
I am currently working on my second Qt app. The first one took six months. Kept finding a better way to do it and going back and rewriting. I cursed MFC the whole time for teaching me bad habits. This second project is going much, much faster. It's only been a month and it's looking like it will be at feature complete in a week or two. It already looks infinitely better than my first one. Trolls documentation is so great, that O'Reilly's book is almost superflous.
Re:KDE, browsers, and reinventing the wheel. (Score:1)
It came with RedHat 6.0, and it was slightly upgraded, but it's still 1.1.1-pre2, and it
crashes when I try to login... However, I'm writing this reply with W3M, so go figure...
I'll try KDE again when I upgrade to RH 6.1, and hopefully I'll be pleasantly surprised.
Thanks for the info.
Proof (Score:1)
Re:Web Browser ? (Score:2)
--
Re:Web Browser ? (Score:1)
What planet are they from? (Score:1)
Now KDE is already struggling because of its C++ centric nature. If they're going to cast away a standard language interaction technology like CORBA... well I'm more and more convinced that Gnome is the way to go.
Either way, linux developers only want one API to talk to, not two. I keep hearing the mantra "competition is good". Only to a point. The reason MS is dominant now is they gave everyone ONE API that covered 90% of the computers in the universe. With 2 Linux APIs, it's just not good news.
Couldn't KDE at least have a look at migrating widget sets to GTK? That would be a step in the right direction. I guess it's not going to happen. I think it's a pity.
..for everyone not yet convinced about Canossa.. (Score:5)
Re:Troll! (Score:2)
Re:No, it doesn't make sense... (Score:2)
I know this seems a bit off-topic, but really it's not. The question is: why can KDE get away with doing something MS is taking so much heat for? And yeah, the answer is: it's not what MS did, it's how and why they did it.
--
What is the level of interoperability? (Score:2)
According to kde.org's news, redhat 6.1 includes both windowing systems and as they put it, equal opportunity installation choice for KDE and Gnome. As a new user of Linux, or more precisely, someone who is about to become a new user, I was wondering whether i should install the same desktop on each of my systems for experimental purposes, or would it be more difficult to share applications and files?
Web Browser ? (Score:2)
could this mean the end of Mozilla...
wish they'd said more...
Re:It's not Windows Registry (Score:1)
...i think i'm starting to like the direction linux is going
Fragmentation of KDE/GNOME components... (Score:2)
However, I just want to pose a question for my own notes (i.e. PLEASE comment) at what point does it become worthwhile to integrate closely related programs, and at what point is it better to keep them separate? Obviously it's different for every situation, but case examples are fine. For example, while web and e-mail may be better off separate, what about combining kpackage and kfm? (Or leave them alone and provide a third executable that does this?) This applies to libraries too. One large QT/GTK/etc library and header that does it all, separate libraries and headers for core and components?
One of the points on the dual-edged sword that is *nix is that although things are cleanly separated and non-bloated it also does make things genuinely difficult for new users to get around in. Whether or not this is a goal that should be overcome or something to leave in to preserve *nix style is a whole other brand of flamebait. =-)
Just some random thoughts that popped into my head.
KDE becomes more and more like closed software (Score:3)
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?
Re:Cool (Score:1)
If they improve the performance in KDE2, then I think we have a winner
Next week I'll try out GNOME - rumor has that it's quite ressource demanding, so....
Re:Web Browser ? (Score:2)
--
KDE TWO Conference Sponsorship (Score:1)
I'm wondering if anyone else noticed this but me -- Red Hat was a partial sponsor for the KDE TWO Conference in Erlangen, as listed on the conference page itself.. I seem to recall everyone screaming and wailing about how Red Hat was in bed with GNOME (and GNOME only) not too long ago..and all this beefage that they basically didnt care about KDE development.
insert(mouth(money));
Bowie J. Poag
Moving away from CORBA (Score:3)
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.
KDE is not giving up Corba! (Score:1)
KDE is not struggling. CORBA is struggling. (Score:1)
Re:Some comments... (not supposed to be flamebait) (Score:1)
Not YET pap (Score:1)
Its going to work sometime ! the layout engine works pretty damn well now, and is a lot better than Netscape 4.x by far.
Just becasue they aren't done yet is no reason to discredit their effort.
Re:..for everyone not yet convinced about Canossa. (Score:1)
Thank god. Sorry, but I really have given up on CORBA. It has yet to provide everything it promised. The OMG seem to have their head in the ground recently. I will be following Kanossa very closely.
Personally, I've become great supporter of COM, mostly because I program with it everyday. It's such a timesaver, if you do it right. It's too bad that there are no open source implentations of it. I know, it was made by Microsoft, but that does not mean it was a bad idea, just unforunately a propritary one.
Shared libraries are okay at long as there is good backwards compatability, which for Linux seems not to be a big problem.
Re:KDE provides a fully themeable widget engine (Score:2)
KDE is not removing Corba (Score:3)
A request to the KDE architects... (Score:1)
I understand that the performance hit and increase in complexity you get when using CORBA is a royal PITA, but IMNSHO there are better ways of dealing with this than ditching it in favour of Yet Another Proprietary Solution. Even if that solution is 100% free software.
While a `local' component model will probably be the fastest possible solution, you throw away a LOT of flexibility by going that way. Why not attack the performance hit at the core and implement a faster ORB? Maybe hitch a ride with ORBit, and put some energy in improving the C++ bindings? Or create an ORB with some sort of internal `short-circuit' for local communications, so that you can gain the benefits of the local model while remaining CORBA compliant for communications to other (non-KDE) applications? Use whatever you want (shared memory, AF_UNIX based pipes, whatnot) on the local side to get all the speed you want, but leave in the plumbing for full CORBA compliance.
This would increase the complexity of the `ORB', but that complexity would be hidden for the applications (and users).
Re:Web Browser ? (Score:1)
Re:More rebuts (Score:2)
But GNU/GPL/RMS is not the holy trinity of Free and Open software. Not by a long shot. RMS is not my god and I'm not going to pattern my life after his wishes. If RMS doesn't want me to be able to choose a non-GNU desktop, then to Hell with him! I don't give a fart in a hurricane how many people are using Gnome or KDE or whatever. If I wanted to use what everybody else is using, I'd be using Windows.
Re:More rebuts (Score:1)
HURD is not Unix. Linux is not Unix. What was your point?
Slash dot readers are hopeless (Score:1)
Re:Fragmentation of KDE/GNOME components... (Score:1)
Pipes require you to define the message boundaries yourself, do not have any facility for type safety or return values, require synchronized access across threads, have limited size before they fill up and block, cannot be opened across multiple transports (on BSD, SysV unixen are much nicer about this).
Look, when I'm working with objects and methods, I want an IPC mechanism that supports, astonishingly enough, objects and methods. Without having to wrap my own marshalling and synchronization protocols around something as low-level as a pipe.
Re:Fragmentation of KDE/GNOME components... (Score:3)
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?
Re:KDE TWO Conference Sponsorship (Score:2)
Shouldn't it be insert(mouth, money)? money as a parameter of the mouth() function is a little odd. Then again, money talks
Does Open Source *need* a COM-like standard??? (Score:1)
Shouldn't this be telling us that there's a need, in the open source world, for a standard model of this kind? In-process CORBA seems to have been found wanting by these projects, as discussed elsewhere in this thread and also, for example, in this kde-core-devel message [kde.org].
Perhaps there's something to be learned from Microsoft here - MS started out with COM as a strictly local component architecture (and took a lot of PR heat from the OMG at the time because of not being distributed), but, has it ended up with a model that's more suitable for local component work?
People have talked about the potential benefits of being able to develop for both KDE and Gnome - a way to help this happen would be for them both to be using the same underlying component model.
Something like this would have benefits way beyond KDE & Gnome. Very few open source projects use CORBA as a central architectural model. Berlin is one exception - it would be interesting to hear what its developers see as the pros and cons of CORBA in that context. But the lack of a standard component model elsewhere limits interoperability throughout the open source universe.
Perhaps the open source community would have better luck than the OMG in coming up with a smaller, tighter common spec for local components than CORBA. It doesn't mean the whole of CORBA has to be thrown out - XPCOM still uses IDL, for example.
As one small example of the benefits of a common local component model, imagine if Mozilla, KDE & Gnome could share low-level components! Surely there's some potential for reuse between those projects (even if only at the level of the component model itself)? Also, developers could work on more than one of these projects, without having to deal with a different API in each case.
Of course, these kind of benefits would all be possible with CORBA. I don't have direct knowledge of the reasons these projects have rejected CORBA in this context, but I'm assuming their reasons were good, and extrapolating from that to the question asked in the subject:
Does Open Source need a COM-like standard???
Re:Sycoca makes me laugh (Score:2)
> And then KDE goes and implements the Windows Registry.
I see no hypocrisy here. Uninformed flaming zealots have a knee-jerk reaction against the registry because it's part of Windows, and real coders like the KDE people implement it because they know better. The main problem with the registry is that it's become abused as a dumping ground. That doesn't make the database itself bad.
Re:CORBA can be fast - and incompatible... (Score:1)
Usually using a different ORB isn't a problem, even if it has some custom features which make switching ORBs a bit more difficult. The Internet Inter ORB Protocol (IIOP) ensures that ORBs can speak to each other.
Now GNOME uses an authentication mechanism that simply breaks the IIOP, and makes interoperability with other ORBs impossible (ORBit does by far not support the whole CORBA standard).
This defeats the purpose of having CORBA at all.
Enlighten me if this has changed already. Right now the KDE way is much more sensible:
- use CORBA properly, where it makes sense
- use shared libs where speed is required
Torben at his best! (Score:1)
I love reading explanations like that. Leaves no room for doubt.
It's not Windows Registry (Score:1)
Re:No, it doesn't make sense... (Score:1)
My message was meant as a joke. IMHO, though, they went aftr Microsoft for the wrong thing.
Re:Since Gnomies are accusing KDE of FUD (Score:1)
And here's a link, for your click-through pleasure (Score:1)
Re:KDE TWO Conference Sponsorship (Score:1)
Re:Drag and drop works fine (Score:1)
mpl (Score:1)
--
Mmmm... fvwm (Score:1)
On a completely unrelated note, I tried to install KDE 2 from CVS on my Debian Slink system the other day (upgraded to glibc2.1 with some deb's from the potato distro) and while compiling mico I got an error saying that idl had Segfaulted on me! Anybody else have a problem like this (it was mico 1.3.0 or something, whatever the one they have in ftp.us.kde.org/unstable/required4KDE or whatever the hell the directory is) (ignore my non-use of grammar, I haven't slept in 2 days... but y'all will like what I'm working on when it's released!)
Anyway, back to the point here. Is there a problem with mico here, or what? I haven't had any problems with anything else on my system (even Mozilla M10 worked, BOTH times it was posted on slashdot!
Thanks y'all
Oh yeah, and no bitchin' about my language, either. I'm tired, I'm hungry, I'm thirsty, I'm bored, and I have to go to class in 15 minutes. Ugghhhh my life sucks.
Oh yeah, and I'm not a hick. Ignore my blatant misuse of y'all in this posting (which, I just found out, is actually grammatically correct!)
"Software is like sex- the best is for free"
Re:Just when I thought I was happy with Gnome... (Score:1)
I have to say that I have tried both Gnome (twice, a 0.3 release, and a 1.0something), and KDE (been using it off and on since beta3), and have the following observations
Gnome:
It just didnt work well. The panel would crash, the help system takes forever to load, the desktop icons (from GMC) just "feel" clunky. The fact that E/Windowmaker will try to use screenspace that is in use for GMC icons for example.
I know the "feel" is very subjective, but it just "felt" awful to try and use. I admit I did not try to make it pretty with themes, mainly due to the crashing and general sluggishness, I couldnt be bothered.
The help system is a measurable thing though, I honestly dont know what it is doing, but it takes over 10-20 seconds to load (p2-350, 128meg, just a desktop machine). The more complete KDE help system loads almost instantly (ok, so i timed it: less than 5 seconds).
Gnome 1.0 was a lot better than 0.3 in most respects (especially the panel crashing for example), however i would in no way label it as a "1.0" release. I think a more realistic version would be about 0.6. Eventually I just got bored and uninstalled it (and spent forever tracking down all the libraries it had installed to eradicate them - thank god for dpkg
Some people say KDE is ugly, and I will definately agree that gnome currently has the potential to look much nicer (if you download or make your own themes) however the default KDE setup is clean, understandable, and gets the job done. Personally I think it looks neat
KFM just plain craps all over GMC. All i want from it is Java/Javascript support that doesnt lock up constantly (a la Netscrape Navigoater) and I'll be very happy.
Installation is another issue. Everything I install these days is with APT, however I compiled KDE beta4 (and 1.0) from source under slackware without a hitch.
I gave up trying to track down all the RPMs for gnome (and required updates) under redhat (5.2), and didnt bother getting it installed until I used apt.
The fact that Gnome uses GTK is a big plus, as a lot of apps I use (xmms, gimp, etc) use it, but to be honest, loading both KDE and GTK into ram seems to be snappier than running gnome for me at the moment.
At the moment, my general feeling is that if i gave up KDE, id just go back to straight Windowmaker (+ the obligator Xterms) that I was using before.
If there is a Gnome release that people can point at and say "yes this is stable" that doesnt look like a hacked together mish mash of a clumsy panel and GMC then I'm all for it.
People will no doubt comment that Gnome has a lot more going on underneath or whatever, and the grand scheme of things is going to be great, but currently, I want to get my work done. I currently dont care, I'm goig to use the best tool for the job, and for me that is currently KDE.
Id just like to point out that other than gnome itself, the vast majority of GTK applications have been very nice
Sorry to be blunt and all.. but thats my experiences, lets hope they arent pointless
smash
Re:No, it doesn't make sense... (Score:1)
You can enter URLs for several network protocols like http, ftp, gopher, pop, (eventually) imap, smb, etc You could read email, check news, read slashdot all in one app.
Re:C++ is what got KDE as far as it is. (Score:1)
YES. Now, I'm not a big fan of either C++ (I still like coding in C a lot better) or Qt (GTK just looks so.... pretty!)... BUT... after getting pissed off at GTK's stupid-assed API, I decided to try and write a program in Qt. In an hour I had a fully-operational email GUI, kinda like MS Outlook, only stabler
"Software is like sex- the best is for free"
Re:Does Open Source *need* a COM-like standard??? (Score:1)
At work I am working on a project to wrap in COM a large business object framework written in one language so we can write new applications in another language. So far, our COM objects are only "in-process servers" (this means DLL based).
At home I am using KDE and learning Qt/KDE programming. I gave up on GNOME for two reasons.
1) C++ is a second class language in the GNOME world but is my primary programming language.
2) I had lots of problems on startup with GNOME. Applications coulnd't find the session manager.
The world in which re-usable components are written in C++ and are used from applications written in other languages is growing.
I'm not interested in going back to lots of C programming.
The Kpackage bit (Score:1)
Re:Some comments... (not supposed to be flamebait) (Score:1)
Re:Just when I thought I was happy with Gnome... (Score:1)
Re:Is this a blow for CORBA? (Score:1)
None of these projects are actually using COM itself (they can't because COM isn't sufficiently multi-platform), so it's not exactly a victory for COM per se.
But you could see it as a victory for some of the ideas behind COM, which has a stronger emphasis on local components.
Re:Mmmm... fvwm (Score:1)
Mico's compiled flawlessly for me for the last several versions, 2.3.0 is the current version required by KDE2. I configure it with "--disable-mini-stl --disable-static --enable-shared --disable-coss".
But, if anyone is thinking about trying to compile the cvs snapshots, don't bother for a few more days. There is still some post-KDE-II work going on, so things may or may not work completely. Or use a snapshot around Oct 7.
Re:What planet are they from? (Score:1)
CORBA... well I'm more and more convinced that Gnome is the way to go.
Don't confuse your hopes with reality. KDE is not struggling at all. Last time I checked RH was the only distro that promoted GNOME and the level of sophistication and the number of applications available for KDE outperform GNOME by a long shot. Not to mention that their deployment model actually allows you to install the darn thing without problems and to add the updates without going insane chasing the dependencies and version numbers of each components (GNOME).
Let's take the time to review Kanossa and all its implications before criticizing. I bet the decision was not an easy one and they took it only after a year of struggling with CORBA.
Re:No, it doesn't make sense... (Score:1)
Re:Cool (Score:1)
kdethis-v1 was not found
kdelibs-1 a neccessary dependant is needed
kdebloat-1 is neccessary
God forbid they throw in QTlibs which seem to be the biggest headache... All in all I think that its nice to see anything *Nix related, step up to the plate time and time again, as it shows the progress of *Nix systems and the movement associated with it. Now if only they could bring down the mem usage and overall Windows98 feel, I'd jump to it, but until then I stick with a proven winner: WindowMaker with 20+ xterms.
MTV h4x0r show [antioffline.com]
Just when I thought I was happy with Gnome... (Score:1)
I can't resist...
Q: How did Gnome get its icon?
A: It's got a big footprint!
But seriously folks, I did some benchmarking over the weekend, timing things like starting up netscape from the command line a first and second time with different memory sizes.
The general trend was that KDE and Gnome both perform with 32Mb similarly to Windowmaker with 16Mb. In 16Mb both Gnome and KDE are hopeless, but KDE was marginally less hopeless. In 32Mb Gnome seems to perform slightly better than KDE (strange). In 48Mb, both run perfectly. (default themes, RedHat6.0GPL packages, plain desktop, KDE+KWM, Gnome+wmx).
Don't forget the seperate apps (Score:2)
However, even more important are all the seperate applications. I recently saw a page with Ksendmail, Kbind and soon to come Kapache. It looks like soon you can rely on KDE for everything and theoratically would not need a text console at all anymore. KDE is setting standards. It compiles, even KDE2 for the most part and it's not even done yet. It's purty. It works and gets the job done.
Of course: KDE is bloated. And perhaps a bit too much like Windows for some.
Nevertheless it's definitely part of my wishlist for Spring 2000: Linux 2.4, Xfree 4.0, KDE2.0, Koffice, Mozilla... I can hardly wait.
Re:Web Browser ? (Score:1)
5.0 beta is due mid December...we'll see....
Re:Just when I thought I was happy with Gnome... (Score:1)
----------------
"Great spirits have always encountered violent opposition from mediocre minds." - Albert Einstein
Some comments... (not supposed to be flamebait) (Score:2)
Kanossa: Shared libraries rather than CORBA - yeah, I bet it is faster - it should be, too. While I agree that for simple applications this is important, I believe the future for Linux on the desktop is in enterprise envrionments. Distrubuted computing is absolutly fundemental to this, and Kanossa appears to give that away for a bit of speed. As for DCOP... don't try and tell me that yados (yet another distributed object scheme) is going to be promoted. DCOM, CORBA, RPC, DCE, XML-RPC is quite enough for me, thanks.
Remember Win95/Office95 back on a 486? Slow, wasn't it? But all those technolgies (COM/DCOM) which were introduced then are just begining to bear fruit now.
I think this is a backwards step for KDE - at least Baboon (or whatever the GNOME component model is called) still uses CORBA.
OTOH, I REALLY like the embedding of Java applets. That is going to be really useful in the future.
Comments would be appreciated.
Re:Just when I thought I was happy with Gnome... (Score:1)
Re:Fragmentation of KDE/GNOME components... (Score:5)
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.
Re:KDE becomes more and more like closed software (Score:2)
As far as I'm concerned, the new changes will promote speed, cut code bloat, and made KDE applications easier to write. Those advantages far outweigh any benefits gained by pursuing interoperability with non-KDE software.
The KDE team should not tie themselves to GNOME if the result produces an inferior product.
Macka
Re:KDE, browsers, and reinventing the wheel. (Score:1)
I didn't have to do anything special, either. I have Konqueror
set up to warn me for cookies, I saved my login in a cookie and
now every time I'm logged in. And I agree, I hate having to
load up slow netscape everytime I go to a javascript site.
I don't see why we're hanging onto Mozilla like this.
--
Re:Let's stop worrying about 486's (Score:1)
:)
Mow lawns, save up $300 and buy yourself a K6/300 or so. Or that Oracle NC thing a few days ago, they said something like $150 for it...
Is this a blow for CORBA? (Score:1)
I see that many people are under the impression the CORBA will be entirely replaced in KDE. I thought the same thing until I read through all the comments and links I could. It really wasn't all that clear to someone that is not directly involved with KDE. Maybe a clarification is needed, I would hate see a pro MS article saying, "COM object model winner, KDE project drops CORBA" Or maybe I'm just stupid and can't read right ;-)
I think the KDE team has done incredible work, and I don't doubt their abilities and decisions. I don't understand what is actually being done, so I will ignorantly ask what does this say about CORBA? Does this say that (D)COM is a better solution/technology? KDE has received a lot of attention (and justifiably so). When I found out that it was going to use CORBA I thought that it was going to bring more attention to CORBA and that this would be good thing in light of MS wanting to set the standard with their COM technologies. Is this a small victory for COM?
The future (Score:1)
Currently, this is the best method for applications to be extremely fast and usable. It does still leave the door open for CORBA. But for native KDE code, it saves a lot of headache. Users do not care if five years from now some app will be fast, but until then live with its slowness. KOffice has been the chief user of OP (the part Canossa replaces) and has been pretty unstable for about a year now. Fixes occur here and there but it just has been unmaintainable. In three days, a couple guys have made Canossa and it's much more stable with it. Development now has a chance to improve real features of the apps.
Where do you want to go today? A mythical utopia, or what works now and works well. And I'll say again, CORBA isn't dropped completely, it is still in there. Despite all the ranting about these sort of subject, the ultimate factor to keep in mind is the users. We must provide products that get the task done in the best manor available.
CORBA may catch up someday, and we can adapt with it. Do you think KDE2 will be the end of any further changes? Heck, with KDE3, KDE4, etc it's probable the code we've written will be gone and redone faster/better/cleaner. Development can and does move with the times. These decisions do come with plenty of thought, the mail lists are publicly readable at http://lists.kde.org [kde.org].
Re:The future (Score:1)
The original post about this is available at here [kde.org]. And just what David Faure predicted has come true.
Let's not get too worked up about this.. (Score:1)
However, to that I say this: let the KDE people do whatever the heck they want. The beauty of open source is we DON'T have to stick with whatever they produce. If KDE2 sucks bigtime, we can all go back to GNOME, WindowMaker, or what have you. So we have choice, which is what makes the whole open source movement so fantastic. So let's applaud the KDE developers on the work they are doing, and when they are done, we'll see what works best and work with that. If in the end it is subpar, we don't have to stick with it. This isn't Windows, people.
Just my
Re:you must see this KDE app (Score:1)
A MS Outlook clone for Linux - very interesting.
What's disappointing is that there's no back-end yet. However -
later versions will be split into "open client" and "open server" and will include data sharing, such as ability to share mail folders, addressbooks etc. The long term purpose is to transform Magellan into a document-handling client and server.
Sounds alot like "Groupware"
Re:KDE becomes more and more like closed software (Score:1)
communication between the applications and the desktop, then we can forget about building applications that work well under both
KDE and GNOME
This is not exactly true, because KDE did not drop CORBA for embedding, it just removed the necessity of CORBA for embedding and replaced it with a more stable, faster and much easier to use solution.
If there is really somewhen in the future some engagement to produce an application that runs under both environments, then it's easy to write a canossa plugin that itself exports a CORBA IDL interface to which the GNOMEish application can connect to. Remember, it's not just done by using CORBA itself, the KDE team would be forced to use the same interface GNOME has, otherwise the apps still wouldn't be interoperable.
Some removing the CORBA bloatware from the embedding framework (and nothing else is discussed here), is a very good step. Applications that still want to embed using some CORBA protocol can still do that, but the normal KDE application has a much faster solution. And it also makes application development faster and easier, and that's one of the main goals of KDE: Make it simple, make it easy to use, make it fast and make it useable NOW, not anytime in the future.
There is not much to say about DCOP. As it uses the ICE protocoll, it's pretty much open standard
Some replies (also not supposed to be flamebait) (Score:3)
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
Re:Duh! (Score:1)
Sycoca reinvents the wheel, poorly (Score:1)
KDE is nice, but it does need some work (Score:2)
Re:Some comments... (not supposed to be flamebait) (Score:1)
I agree with your comment about CORBA (although I haven't used the C++ bindings). It does run slow and appear bloated.
DCOM, OTOH is quite nice - at least via Delphi. It is the configuration needed to get that running which sets it back.
So what is left? XML-RPC appears nice & simple, but slow.
I really don't like the idea of trying to get another standard accepted.
KDE, browsers, and reinventing the wheel. (Score:1)
A lot of KDE looks inspired by Windows. If they can keep it fast and free, I don't mind if they go that route, it should make a lot of people happy. However, it would be nice if there could be an easy way to get multiple bindings, or some other kind of standardization between all of these Desktop Environments.
I'd be really happy if I could just theme everything, and have an all-encompassing widget set (or bindings for everything, and recompile). If you ever get bored... it's GNOME and athena widgets, or KDE and motif, or something. Also, then we could get the Mac bigots to shut up about the consistent-look-and-feel thing, so we can explain about network transparency. ;)
Re:Cool (Score:1)
KDE gets along well with both WindowMaker and Enlightenment 0.16...
Can you tell me some more about those make errors? I can't reproduce them.
Re:What is the level of interoperability? (Score:2)
The interoperability problems that are there are mostly because of the totally different nature of the libraries, therefore, you can't for example do Drag and Drop from a KDE application to a GNOME application or vice versa.
But you can run GNOME programs on the KDE desktop and vice versa, that's not a problem.
Re:The Gnome model is based on Miguels Ego (Score:1)
"This is my personal view on KOM/OpenParts: I myself find it very complicated and too complex to understand."
http://lists.kde.org/?l=kde-core-devel&m=938708
"l) Easy to use APIs
Bad APi -> nobody learns it -> no code -> Does not matter how powerful the API is since no code uses it
I think it is kinda funny after all the criticisms Miguel and GNOME in general have got (from actual KDE developers instead of the advokiddies (great term by C. Browne btw) here on slashdot) for writing ORBit and Bonobo.
I don't know if the performace issues would be solved by using ORBit instead of Mico, but those who actually are solving them (the KDE developers) seem to think it wouldn't. Who would know better?
I for one would like be able to run something like a GIMP server on a nearby Onyx and have the image embedded in a document, but for 99% of the desktop users out there this is probably not possible so a fast local-only solutions is the way to go.
Not that I would let many cycles be used by office applications when I need all of them for gcc/Emacs
Re:Web Browser ? (Score:1)
I have not used the KDE 2.0 Konqueror, but I have used the 1.1.2 kfm and while it works very well for most basic browsing tasks (it's great for reading documentation) its cookie support is flaky and it is somewhat slower than Netscape or Mozilla 5 at rendering pages. I would love it if they used the renderer from Mozilla and kept all of their nice extensions (such as support for reading man and info pages).
Re:Rebut (Score:2)
What?! First of all, Free Software as defined by RMS, and Open Source Software as defined by OSI, are not antagonistic towards commercial software. On the contrary, they are in support of it. Second, what's so bad about "commercial" software? Not everything can be the result of a hobby. Developers have to feed their families as well, so why not do so using their skills?
"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..."
First of all, and this has been stated here dozens of times, KDE is not abandoning CORBA. OpenParts is just a layer between CORBA and the GUI.
Second, why shouldn't they use their own libraries? That's precisely what KDE (and Gnome) is, a bunch of shared libraries! One of the participants in the communication is always a KDE component, so it makes no difference if it is a KDE library or not. The number of people desiring to use the KDE communication implementation between two non-KDE applications is insignificant.
Third, if I recall, Gnome encourages its developers to use Gnome shared libraries as well. That's what makes Gnome Gnome!
"Both DCOP and Kanossa would only work under KDE..."
Not necessarily. Remember your earlier point about them being shared libraries. Nothing prevents the interface from being used by Gnome, XFCE or anything else.
"That is, unless you link your software with the KDE libraries, but then again the developers would then be tied to KDE."
I'm not sure I know where you're coming from with this. All KDE applications have to be linked with KDE, just as all Gnome applications have to be linked with Gnome. If Gnome implements a Kanossa interface, or if KDE adds a Gnome interface for Kanossa, then it doesn't matter if your application is Gnome or KDE. If your application is tied to neither desktop, you will still have to use someone's communication protocols!
"Is it really necessary to give away this freedom (not linking with KDE libraries and Qt) to gain some efficiency?"
What's the difference between linking to KDE and Qt versus linking to Gnome and GTK? Playing devil's advocate, Gnome already gave away this "freedom" when it mandated its own shared libraries.
Re:Web Browser ? (Score:1)
pretty much the same things Mozilla does.
I don't see a real need to integrate Mozilla - why have 2 things that do the same?
COM...OpenParts... sounds great but... (Score:1)
Perhaps they have identified the problems and will make architectural decisions to prevent them.
If people thought the glib change-over problems were bad, just wait until a developer in Slovakia decides the IInterface to his ITextEditor could be done better and re-architects it; in the process breaking 1000 applications.
Re:KDE becomes more and more like closed software (Score:2)
CORBA is used less (NOT dropped) because it had severe speed, memory usage, and stability problems.
Compare the CORBA version of koffice (which has been around for ages) with the 3 days old Kanossa based version and yoU'll see the difference.
Also, it is not impossible to write a CORBA wrapper for DCOP.
Gnome never has attempted KDE interoperability... (Score:1)