Slashdot Mirror
KDE Looks Ahead
An anonymous reader pointed us to an article thats currently appearing at Linux Today regarding the future of KDE. Its essentially a report from KDE2. Talks about their new com solution, organizational changes and more. Its an excellent update on some excellent software.
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
~Tim
--
Rushing on down to the circle of the turn
click on the KDE2 in action link :)
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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
Mico 2.3.0? You'll need a fairly uptodate version of egcs, I'm on 1.1.2, it compiles ok here.
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
pb Reply or e-mail; don't vaguely moderate.
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.
I know I will be moderated down for this, but . . . Vincent
--
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. :)
OFTC: By the community, for the community
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.
The name is funny. :)
:)
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.
Oh sure, it's just a cached version of the setup files, but the purpose is still the same.
.. read this .
First off, KDE 2 will be done long before Mozilla is, second the browser in KDE is actually a internet transparent file manager similiar to IE, not Moz.
Bummer.
The corba issue has nothing to do with the widget set (Gtk vs. Qt), it has to do with KDE using components extensively now and interapplication IPC via Corba (even locally) is too slow and buggy.
These KDE guys are not fools. They use only what suits their project - they have no political agenda. I am glad that they've objectively evaluated CORBA and dismissed it on solely technical grounds and found a more suitable solution. Also remember - THEY are the ones writing the darn thing - if you don't contribute, you have no right to complain.
I do not question the great work Elliot has put into ORBit - I quite like it - but the problem is with CORBA itself - it is the most documented incompatable standard yet devised in computerdom. The problem was the specification was too loose in the early days and the other problem was that it was designed by committee. Neither of these factors produce quality software specifications. I would much prefer a GNOME-centric or KDE-centric approach (or KDE-GNOME-centric approach) because I respect the ability of these pogrammers much more than the top heavy and political OMG organization.
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.
-matt
Nice work with KDE2, they seem to be heading in the right direction. After all, they've got a pretty good blueprint to work after ;)
// C
At last some people concerned about performance ! I'm more than fed up with those bloated desktop environement.
> Actually, it is the windows registry - just not a binary one
.rc-files is being collected and stored into the binary-file if .rc-files are being changed. That way it won't matter if the binary file is being corrupted. But everything becomes incredible fast!
It *is* a binary one. The contents of the
AC
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?
Juln
If you read the 50 odd CORBA services specifications you would think that it rules the earth - nothing could be further from the truth. Most ORBs implement only a tiny subset of all these CORBA specifications - and different and incompatable subsets at that! KDE can't wait for this nonsense so (for now) it's charting its own path - with real code that works today - and not only within a specification. Bindings can be made at a later time for CORBA (should they be required).
Now that's interesting...
could this mean the end of Mozilla...
wish they'd said more...
Full plate and packing steel! -Minsc
excellent :) ..finally.
...i think i'm starting to like the direction linux is going
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.
Just listen to yourself:
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.Everyone has exuses about CORBA's lack of speed of lack of flexability or its awkward API. Frankly, we're tired of it. The world cannot wait for CORBA. Why waste time cramming a square peg into a round hole? If CORBA is the answer - what's the question? A year has already been wasted using CORBA within KDE. KDE wants solutions today.
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?
The CORBA model is not a very simple one. You could argue that the KDE developers just did not take the time to learn it, and as result are unfairly dismissing it. Or you could argue that because CORBA takes so long to learn and is so difficult to maintain that KDE did in fact make the correct decision. You cannot force programmers to use a library unless they like it. If they don't like it - no code will result from it. We all agree the KDE project's results speak for themselves. If they have collectively evaluated CORBA and are dismissing it they must have a sound reason.
-- "they use C++ to write the core libs" -- "So what? C++ is an open, standardized and freely available language." Ever heard about masquerading? Ever tried to call C++ functions from another languages? sipan
They just use Orbit for Corba. KDE is doing the same thing - they are not dropping Corba.
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
Bowie J. Poag
Well to many people it is, but I somewhat agree with you. KDE should not have to worry about how it performs on a 486, since there are many other lightweight WMs to use on 486's.
Very good overview.
I find it really distressing that KDE is moving away from CORBA. For one thing, the possibilities of distributed objects are endless. And Microsoft already has such a thing in their DCOM model (which sucks, I know. But still, its there).
Why couldn't they just swallow their pride and use a faster ORB? Say ORBit? I know that there are no C++ bindings, but that's better than falling back to a shared library implementation! The fact is that MICO (which they were going to use) has been pronounced too slow to be usable by everyone who's tried.
And forget interoperability with this thing -- there's no technological basis to make GNOME and KDE interoperable now.
-- Slashdot sucks.
They weren't even going to carry it in 6.0, and when they did they made no mention of it in the install documentation. They are playing nice now because it has become the dominant GUI.
CORBA performance is not there. It produces binaries that are, frankly, huge. CORBA is the most incompatable standard ever devised. For instance, it took them until December 1998 to realize that their object Naming Service was useless since there was no standard mechanism to even find it! What good is a distributed object system that can't even lookup the naming service in the first place in a standard way?! Now (finally) they have well-known TCP/UDP ports for the lookup - or do they? They attempted to use ports already assigned to another group (9999). The Sun Java 2 project couldn't wait and just arbitrarily assigned the Naming Service another port that was not taken. CORBA was designed by a huge committee of companies - and it shows - badly.
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.
Juln
KDE is already released and needs software to work now.
I ported Siag to KDE and that uses both C and Scheme. Wasn't that hard at all. Any language that can be binded to in C and also be binded to in C++. mosfet@kde.org
As well as a file manager... as well as contributing to mico hacking... I think they know Corba by now. If they don't think it is good for a GUI then it's an educated decision. It's still going to be used for the object model tho
The plugin supplied by KDE support full themeing with a large supply of options. Look at www2.jorsm.com/~mosfet
...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.
Not very bright.
>First off, it seems to me that your only criteria for software >excellence is that is has GNU in front of its name.
Actually he has a very important point. Gnome is a GNU project more or less. Which means major GNU and other software projects will be designed around the features of Gnome rather than whatever form KDE is using at the time. For example take HURD for example. No matter what anyone thinks about it's prospects, does anyone seriously think that software created for HURD is going to actually use the QT libs for *ANYTHING*? Now do you see the size and scope of the minefield the KDE userbase have just stumbled into.
Even though the HURD has GNU in front of it's name, don't kid yourself into thinking that anyone will use it with Linux around. And Linux doesn't have GNU in front of its name, unless you've been successfully brainwashed by the GNU cult.
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).
--frank[at]unternet.org
The problem is with embedded communication via IPC period. Nothing in Gnome approaches the amount of component integration used in KDE2 so there is nothing saying it would help. Actually, using the Corba API period is extremely slow for this type of work independant of which orb you choose.
Do you think it's a good idea to have someone called `Sucker' in the finance dept.? ;-)
;-)]
[Just kidding. At least one has to be pretty smart to `suck' like that
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.
A Government Is a Body of People, Usually Notably Ungoverned
KDE is widely recognized as being further along in development and having more users than Gnome. Yet here is the press only release for the next version of Gnome where they call themselves the leading desktop (lies), and promote a bunch of beta technology as available to end-users. Also note there are two versions, one without lies for the Slashdot crowd and one with lies for the press. And people wonder why KDE'ers don't like Gnome and RH. They lie and are two-faced. If this upsets you please mail RH and Gnome developers and let them know. http://people.redhat.com/sopwith/og/
Take a look at the October Gnome announcement funded by RH. They have two separate versions, one without overt lies for Slashdot, etc.. one with lies for the press only. They call themselves the leading desktop even with less users and promote a bunch of beta software as usuable by end users. People accuse KDE of FUD, at least they are not this two-faced. http://people.redhat.com/sopwith/og/
HURD is not Unix. Linux is not Unix. What was your point?
Business. Numbers. Money. People. Computer World.
>Even though the HURD has GNU in front of it's name, don't kid >yourself into thinking that anyone will use it with Linux around. And >Linux doesn't have GNU in front of its name, unless you've been >successfully brainwashed by the GNU cult.
This has nothing to do with the GNU name nor the number of people using Linux or Hurd. It has *EVERYTHING* to do with creating/porting software bettween the two. I can see a fully working "Official" port of software like Xemacs for instance that has GNOME/COBRA support for both HURD and Linux designed in from the start.
>HURD is not Unix. Linux is not Unix. What was your point?
That KDE has just driven itself headlong into a dead end. That KDE has been infected by the mindset that sank the Amiga in the end.
>They don't care what internals their desktop uses.
They'll care whem KDE crashes and burns on them when running software that works perfectly fine on machines running Gnome. Go ask the Amiga users the grief MUI (another bad idea) caused.
Too right.
Will the person who can write an application that integrates cleanly with GNOME in look, feel and functionality, using ONLY CORBA (and libc) please step forwards.
Or to put it another way, how do I
- Create/Open a new window.
- Set up a canvas in the window.
- Draw to it.
With GNOME's object interface?Without that sort of thing (as the KDE people have observed), the CORBA functionality is reduced to a glorified, buggy, slow IPC that has no real place in the code -- When CORBA is a simple in application as PDO, maybe it could be reconsidered.
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.
Didn't think so. Talk to me when you get a browser, much less one with Java.
I posted 3 times to different comments that KDE is only replacing OP, not the object model which will still use Corba. Either people can't read, don't care to listen, or just like ignorance.
i came across this very cool link on linuxtoday it was about a once though vaporware for KDE called magellan you must see the screen shots http://www.kdeforum.org/news/Stuff/magel lan/ and read the article at http://www.kdeforum.org/news/939533 382/index_html
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.
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???
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
KDE config files are in a human-readable ASCII format just like the rest of Unix, not some messed up binary format.
I love reading explanations like that. Leaves no room for doubt.
All this talk about Mozilla is irrelevant. It's no where near stable. KDE has a stable HTML widget and now java and javascript.
Subject says it all. If that's not evil, then tell me what is.
At least so it seems :)
Miguel de Icaza was amazingly uncooperative when designing it.
Which leads to the conclusion that good ideas for Miguel can only come from Miguel himself...
CORBA tries to paper over the distinction between distributed objects and local objects. This is a fundamentally wrong approach as has been covered in several papers.
Now note that KDE is not dropping CORBA. They are just not using it for embedding applications on a local computer. A CORBA wrapper can always be made for those of you who believe distributed computing can and should be unified with local computing. KDE has had much experience with this (what has anyone heard of Bonobo?) and do not believe this is the right way.
CORBA will be retained for scripting, server/client and for talking to GNOME/other.
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.
Control center applets are not a good demonstration, and doesn't use Corba for embedding either. And Bonobo isn't a standard... Does Gnome allow file manager plugins, does any released Gnome app have the capability to embed dozens of plugins effeciently? Don't call something a troll just because you don't agree.
either the HURD will use X and then KDE will work just fine in it, or the HURD will not, and then it's even more dead than it looks like (which is already very very dead)
> 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.
this "sounds" nice, but it wouldn't work well at all, think about all the image data that had to be transferred over the network all the time.
We thought about a network transparent KImageShop via CORBA, but it'd be nowhere near usable.
http://people.redhat.com/sopwith/og/.
Someone has been monitioring our lists tho because I feel pretty much the same. mosfet@kde.org
Only in KDE 2.x
This message is provided under the terms outlined at http://www.bero.org/terms.html
--
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?
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.
:-) 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
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"
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
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
And maybe an arrow pointing at it for all the people don't seem to actually be reading things.
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).
I know I will be moderated down for this, but . . . Vincent
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.
CSS has some patent problems making it proprietary.
Programming in the real world, you still run into versioning problems. I'm not talking about the product of some hobby-hacker, but code coming out of a couple half-billion dollar companies.
If you ever had to deal with any "black box" code you'd at least have a clue. The trolls may get the architecture right, but they'd be the first.
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).
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.
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.
Not just "some". I would rather say "alot more".
CORBA is nice, but if it is heavy and requires ditto HW, well then one have to be pragmatic.
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.
--
steve
C-x i ~/.sig
The widget themes are *very* fast and pretty :)
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?
FINALLY SOMEONE GOT THE POINT!!!!! I hate people who don't know what they are talking about...
GNOME uses the ORBit implementation of CORBA to implement a design that is based on ideas from COM/OpenDoc/OLE/etc.. They are still using CORBA all the way to handle the communications between components.
They both use the Xdnd standard.
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.
The authentication mechanism uses the standard CORBA_Principal part of the IIOP message specification. There is nothing preventing interoperability with other ORBs, and in fact they say they have tested ORBit to work with mico/tao/ilu/omniorb. That is good enough for me!
It seems to me GNOME tries to use standards that will interoperate with not only KDE but the rest of the world. CORBA is a standard, DCOP is a custom KDE invention, but you want to make it sound like KDE is in the right here. CORBA is not bloated, just the KDE usage of it. GNOME 1.0.x, which uses CORBA, uses as much memory as KDE 1.1.x, which doesn't use CORBA.
At least I know GNOME cares about standards, since they are using CORBA, Xdnd, and other things that work outside the teapot universe of KDE.
And, the GNOME people have made a CORBA implementation that is actually fast - it is not CORBA that is the problem, but the implementation that is used.
I made a suggestion once to the GNOME people about Bonobo, and they listened to it. Maybe if you would try talking instead of sticking your head up your rear end, something would happen.
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.
.02
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
WindowMaker is brought in as a comparison to determine the level of overhead involved in running a desktop environment versus running a window manager.
It's pretty pointless doing benchmarks without a baseline.
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
Pity they want to use their own shared library standard instead of corba components. Corba components are also inprocess too, and it would keep to open middleware standards.
Of course there isn't a good implementation yet, but I was hoping they'd help.
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.
The best way to accelerate a windows box is at 9.8 meters per second square.
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. ;)
pb Reply or e-mail; don't vaguely moderate.
http://www.gnome.org/mailing-lists/archives/gnome- components-list/1999-September/0027.shtm l
3 8307236&w=2
:-) This is OpenSource. We can not force people to learn OpenParts and for understandable reasons almost nobody did."
:-).
/mill
"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
Ha, he wore a brown paper bag over his head at KDE II due to his embarrassment over OpenParts.
and now that it is people complain... although they have no idea what they are complaing about ;-)
With the new model you can just derive from a class and reimplement 2 methods to make a part :)
So it doesn't suck ;-)
"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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
How well an application, or desktop environment, performs on a 486 just isn't relevant anymore. I'd rather see developers working on stability or new features rather than trying to support people still running a 486/50 with 16 Meg of RAM. I threw away my 486 last year.
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.