Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

KDE Looks Ahead 182

Posted by CmdrTaco from the roadmap-for-the-future dept.
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.
This discussion has been archived. No new comments can be posted.

KDE Looks Ahead More

KDE Looks Ahead

Comments Filter:
  • Hmmm. Have you got KDE 1.1.2?
    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 ;)
  • Kanossa: Speed is not the only reason to make the change. Stability is the other one. mico-c++ was never as stable as we'd need it.
    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)

    by Anonymous Coward

    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
  • First off, it seems to me that your only criteria for software excellence is that is has GNU in front of its name. That other people prefer other software, or have no preference, must be beyond your comprehension.

    "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.
  • Actually, it is the windows registry - just not a binary one - but a readable text one. Still the a registry. And rightly so. More OSs need to implement some sort of registry for settings...not stupid little *rc files and XF86Config files that can get just as big as the registry.
    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.
  • I would put that as

    mouth.insert(money);

    But I wasn't raised on C as everybody else, or so it seems.

    "Open Source. Closed Minds. We are Slashdot."

  • I've done extensive work on COM and ActiveX controls but I don't agree with you. Any self respecting COM programmer knows not to change the interface once their COM objectis released to the public. That being said - there's no problems. And in a world where thousands of ActiveX Controls are on the market - there's not as much trouble as you would expect.

    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.
  • windows users or ex windows developers?
    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 :)
  • First off, Qt is just a pretty at GTK. All you need to do is implement a style. Unfortunately, there are few style available for Qt2.0. I'm on the verge of writing a Qt style engine, but who knows if I'll get time.

    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.
  • Wow, that's even better! Okay, apparently *my* version of KDE doesn't log into slashdot.

    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.
  • I launch KFM, and I try to move a directory into a gmc window. Nothing happens. What apps can show XDND working between gnome and kde.
  • Mozilla is well on the way towards the goal of being a fast, efficient, 100% standards-compliant browser. If konqueror can do as well or better, that's great. But at best, it seems like a duplication of effort, and at worst, it seems likely to be yet another 90%-compliant browser. I'm not meaning to be inflammatory, and if it is as good as Mozilla in matching standards, I've got no problem with it.

    --

  • No. I don't want to always get "you can not run this as root" from Kozilla. Once its running as my user account it has a bus error and dies the moment i try and see anything other then straight html. But I've been using KFM for the last few weeks (when i'm not at console) and it is significantly more stable, being only allergic to slashdot at login time. :)
  • What's this stuff about giving up CORBA because of its "distributed nature"?? Corba doesn't have to be implemented using network protocols, it can be implemented in-process as well. Any good implementation will give you the choice. The main point of CORBA is that it gives you a locked down interface so that APIs can be called between languages (or same language), between processes (or same process).

    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)

    by Anonymous Coward on Monday October 11, 1999 @04:39AM (#1624139)
    .. read this [kde.org] .
  • GNOME's use of corba is not standard. IIRC, ORBit uses a proprietary authentication scheme that made interoperability difficult if not impossible from the begining.
  • No, that's only if you have an OS monopoly and are trying to extend that to other markets via bundling.

    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.

    --

  • Between gnome and kde, i mean. I think this should be a primary focus for the two projects. While it is good to have multiple competing systems for the sake of diversity and innovation, compatibility would simplify matters for programmers and users.

    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?
  • Now that's interesting...
    could this mean the end of Mozilla...
    wish they'd said more...
  • excellent :)
    ...i think i'm starting to like the direction linux is going ..finally.
  • I have a question to pose out there... despite the efforts to make the KDE (or GNOME if you prefer) a unified-feeling interface, it still has the distinct feel of being separated. Part of this is just the UNIX mindset - you write what you need/want, and only that, lots of small stuff over one huge program.

    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)

    by Anonymous Coward on Monday October 11, 1999 @02:18AM (#1624157)

    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)

    by voop ( 33465 )
    Performance....I just installed KDE-1.1.2 on my laptop (P233MMM,32MB) for testing, and I amazed that it doesn't slow the machine significantly more than fvwm2 does (no, I don't have measurements, it's strictly based on the "feel").

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

  • I hope they integrate mozilla. Does it really make sense to do otherwise?

    --


  • 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)); // RH isnt evil, kids.




    Bowie J. Poag

  • Moving away from CORBA (Score:3)

    by Amphigory ( 2375 ) on Monday October 11, 1999 @04:56AM (#1624166) Homepage
    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.

  • KDE is not giving up Corba! (Score:1)

    by Anonymous Coward
    I wish people would read... They are just not using it for embedding. The K Object Model (KOM) is still corba. The UI parts embedding (OpenParts) is used via the new mechanism. This is *very* similar to DCOM. As far as Orbit speed, Gnome is doing something very similiar to what KDE is and uses no where near the number of full components (panel applets don't count).
  • CORBA's bindings are crude, slow and big - and largely incompatable with different vendor's products. The CORBA standard is always two steps behind reality. Take firewalls, for instance. Until Corba 2.3 (IIOP 1.2) you could not communicate with CORBA clients behind firewalls because CORBA required 2 sockets for bidirectional requests. Only now are the various CORBA implementations playing catchup. We can't wait for CORBA's lack of foresight. I respect that KDE rejected it based solely on basic technical grounds. KDE is a robust and reliable desktop environment with sound design principles and an extremely low bug defect count. Clearly, these guys know what they are doing.
  • Stability is the other one. mico-c++ was never as stable as we'd need it. Then why not adopt another ORB? like ORBit? It seems to be a nice small CORBA implementation (although I never used it intensively). Are those guys so proub they wouldn't use stuff from "the other camp"? Arjan
  • irrelevant??

    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.
  • ...named "Kanossa", uses shared libraries rather than CORBA.

    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.
  • But is this plugin usable for straight Qt, or does it need KDE as well? I browsed through the CVS and didn't find anything usable for straight Qt there.

  • KDE is not removing Corba (Score:3)

    by Anonymous Coward on Monday October 11, 1999 @05:16AM (#1624182)
    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.
  • Hey Folks,

    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).
  • I think Konquerer is a serious threat to Mozilla. It is at least as functional as Mozilla and is also a real GPLed application, not just MPL. Go ahead and try it out.. it is far from perfect, but it is still a very nice (and lightweight!) browser. I know some people think it is a "duplicated effort" but I don't see anything wrong with having some competition between Linux web browsers.
  • Of course GNU software won't use Qt. If they could get away with it, they wouldn't use *anything* that's not officially GNU. Rather like Microsoft.

    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.

  • HURD is not Unix. Linux is not Unix. What was your point?

  • Slash dot readers are hopeless (Score:1)

    by Anonymous Coward
    KDE is not removing all of its CORBA infrastructure. KDE is not removing all of its CORBA infrastructure. KDE is not removing all of its CORBA infrastructure. If a Slash/Gnomies gets something in their head it really sticks.
  • I bet you also think vi is the only word processor anyone needs.

    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.
  • 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?
  • > insert(mouth(money));

    Shouldn't it be insert(mouth, money)? money as a parameter of the mouth() function is a little odd. Then again, money talks :)
  • I work on distributed systems, but not at the UI level, so I'm not very familiar with the innards of KDE or Gnome. However, from what I'm reading, both use a somewhat COM-like local component model. Another open source project that does something similar is Mozilla, with its XPCOM architecture [mozilla.org].

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

  • > But really the thing that makes me laugh about it is the endless hours of debate that Linux zealots have had regarding why the Windows registry is incredibly sucky.
    > 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.
  • I don't want to nitpick, but GNOME's CORBA implementation is not exactly kosher.

    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

  • I love reading explanations like that. Leaves no room for doubt.
  • It is a database of several text config files, that are static 99.99% of the time for faster access. And when one of the text files changes, it'll reupdate the db. This isn't the sort of Windows Registry we all know and hate. You are free to modify text files in vi just as you always have.
  • Microsoft didn't get why they are by bundling. They got where they are by bundling using exlusivity contracts, etc.. ;-P

    My message was meant as a joke. IMHO, though, they went aftr Microsoft for the wrong thing.
  • Go away, mosfet. At least the GNOME people have the guts to identify themselves.
  • Please note that it was redhat.de which is the former DELIX (maker of the German language distribution DLD). Perhaps the deal was inked at DELIX times ...
  • Only in KDE 2.x

  • mpl (Score:1)

    by mattdm ( 1931 )
    The MPL is a perfectly good competely open source license.

    --

  • I love fvwm2... none of this kay dee ee / guhnome crap... mmmmm.... old school stuff rules. Give me a Athlon with 2gb of RAM, and all I'd use it for would be fvwm2 and vi.

    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! :-) Can I use a different CORBA Orb here instead (or whatever the fuck they're called)? If anybody knows the answer to these questions and would like to help out a poor starving college student with too much free time and too many cigarettes for his own good, please email me at spong@glue.umd.edu [mailto]

    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"
  • The following is my experiences with both Gnome and KDE desktops, and is not meant to be flame. Try each for yourself, your mileage my vary ;)

    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
  • And not just a file manager...

    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. :)
  • if you looked at KDE and QT API docs you would see you can do a lot more in a lot less code because it is built from the ground up in C++. Why do you think it is getting all these features so quickly?

    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 :-) And this included the time to learn Qt from the HTML documentation they give you (which is just amazing, BTW) It just *amazing* how much more efficient a good C++ API makes your coding. It knocked my socks off, and I still haven't been able to find them. I think they're in that pile of trash over there.

    "Software is like sex- the best is for free"
  • I see this new direction as a good thing. You don't need to have GUI classes to lead you to a shared library object model. It is good for cross language object (or component) re-use.

    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.
  • What you suggest with kpackage is feasable already with Konqueror. Konq essentially just displays a view when you click on a file. If a view is available (ie plain text, html, pics with kview's view etc) it displays it. So it just takes someone writing the view, I don't think it has one currently.
  • Kanossa is basically just a short-cut to embedding KDE stuff inside other KDE apps. CORBA for this has proven to be slow, unstable, etc. CORBA still exists for communicating with outside objects.
  • Try the new 1.0.50 release. It is the last major release compatible with the old gnome, and is supposed to be stable (Its stable for me at least).
  • Is this a small victory for COM?

    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.

  • Maybe contact the mico group?

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

    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.
  • I'm sorry, but imtergration like this is forbidden by law. Please reference States Vs. Microsoft, 1999.

  • Re:Cool (Score:1)

    by joq ( 63625 )
    When all else fails chock in some ram and the feel of a Windows98-like Linux desktop won't hurt you as much. Personally I think KDE looks nice but I wouldn't run it being I could do most of the things in an xterm in half the time I spend waiting for KDE or GNOME to clear up some memory to start it. While it is nice to see a pretty desktop (I guess) truth of that matter is I can get the same results with WindowMaker without have to find a million dependant CVS files at OpenBSD sites abroad. Well for the users of KDE... I hope they fixed all those neccessary make errors.

    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]

  • The KDE people go and pull a bunch of rabbits out of the hat. The shared memory stuff sounds very interesting, especially if it going to significantly reduce memory use. I wonder though if it will be a handicap elsewhere? Has anyone actually found a practical application for the embedding of components between different machines?

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

  • KDE2 is, or will be, great. Every now and then I compile the snaps to see what's happening and every time there's more functionality and eye candy. Those new themes/styles make Linux a hot rod.

    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.

  • Considering the fact that it's the only major app that can bring Linux to it's knees?
    5.0 beta is due mid December...we'll see....
  • Shaped like a "G".

    ----------------

    "Great spirits have always encountered violent opposition from mediocre minds." - Albert Einstein

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

  • Why do people insist on bringing Window Maker into the Gnome versus KDE equation? Window Maker is a window manager. Nothing more.
  • 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.

  • At it's birth, the goal of the KDE project was to create a desktop where all apps used one common widget set. Making it play friendly with other Open Source desktop projects was never on the radar until IMO it became a political goal.

    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
  • Even KDE 1.1.1 lets me log into slashdot.
    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.
    --
  • Why are people only worried about 486s? What about all those 386s out there? The Linux kernel supports it, therefore every app I could wish to run should work on it just as well as any Athlon.
    :)

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

  • 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?

  • We need to look at the present and immediate future more than the distant future. I know many of the Slashdot readers would love to see a KDE2 come out that is terribly slow and crashes as much as something from MS. But that is not what will happen.

    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].
  • I forgot one important fact in all this. The old saying, "Show me the code." The fact is, Torben Weis took the time to implement a working version of canossa to demonstrate. If anyone has ideas about how to implement something better or whatever, they're welcome. But nothing gets the point across as having code to show your view and that it works.

    The original post about this is available at here [kde.org]. And just what David Faure predicted has come true.
  • I see a lot of people up in arms because the KDE people are changing directions in how they are developing this thing. Now, I realize you are worked up with good reasons - we all want KDE and GNOME to work and play well with each other, for each to open, etc.

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

  • 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" ... Hmmm. (Although, I'm not sure if something ambitious is needed, or will every really stack-up in the big enterprises that use Notes and Outlook applicaitons. What is needed desperately is a good open standard calendar server.)
  • 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

    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)

    by LizardKing ( 5245 ) on Monday October 11, 1999 @03:00AM (#1624279)
    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
  • Funny, I didn't see that stated in the original comment.

  • Sycoca reinvents the wheel, poorly (Score:1)

    by Anonymous Coward
    Anyone who wants a lightweight 'db' for static-type data and does not use LDAP, for unix implemented by the openLDAP project, surely needs to get out more. This is exactly what lightweight directory services is ment for, and they will get a distributed, searchable, secure and open, standardized way to store, access and share the data. It even has NS-and PAM-wrappers if one feels more at home with any of those APIs. If it was written against the standard Name Switch interface the user could choose backend from the nsswitch file, where LDAP could be one choise or text files another choise, just like host lookup works on most boxes. Oh well, 'Not Invented Here, (or by the trolls)' I suppose ...
  • Although KDE is nice, it could use some major work on speed and memory consumption. While Window Maker and Enlightenment run on my 486/50 MHz with 12Mb of RAM, KDE brings it to a crawl. Although this software was meant for pentiums, it should at least be able to run standalone without any problems, but as standalone apps they are very slow and perform poorly as opposed to GNOME apps which run at acceptable performance levels (even good enough to play that cool Othello game that comes with GNOME, Iagno I think). Even with the slow down, though, KDE is still better, faster and more stable than certain other operating systems.

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

  • KFM (the Konquerer web browser) is *really* fast, I like it. However, it doesn't support some nice web browser features, (like logging into slashdot :) so it won't be my default web browser anytime soon (KDE 2?). Let me know when it does, and I'll test it. [152.7.41.11] :)

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

  • WindowMaker is KDE compliant by the way - if you don't like KDE's window manager, don't use it.
    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.
  • There's no problem exchanging files and such.
    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.
  • http://www.gnome.org/mailing-lists/archives/gnome- components-list/1999-September/0027.shtm l

    "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=9387083 8307236&w=2

    "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 :-) This is OpenSource. We can not force people to learn OpenParts and for understandable reasons almost nobody did."

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

    /mill
  • I hope that they do too.

    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).
  • "It sounds like KDE is becoming more and more like commercial software."

    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.
  • We have konqueror, which is based on kfm, and does
    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)

    by Anonymous Coward
    Any developer who has done extensive work with COM and ActiveX controls will tell you that while the whole idea sounds great, in reality it intrduces so many subtle problems, that in the end it isn't worth it unless you are doing little utility software.

    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.

  • KDE doesn't move away from standards without a good reason.
    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.
  • From Orbit to Bonobo the Gnome project never has tried to ineroperate with KDE KOM/OP. If Gnome isn't going to attempt supporting the KDE component model why should KDE not optimize their own code. It's not like Gnome has been trying to interoperate, so it's better to make KDE run as fast and efficently as possible. The Gnome team has done the same thing.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close