KDE Looks Ahead

Re:Some comments... (not supposed to be flamebait) by bero-rh · 1999-10-10 20:06 · Score: 2

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

Re:More rebuts by Arandir · 1999-10-11 04:59 · Score: 2

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

Re:Dittoes by Arandir · 1999-10-11 06:20 · Score: 2

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

Re:Web Browser ? by mattdm · 1999-10-10 20:17 · Score: 2

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.

--

..for everyone not yet convinced about Canossa.. by Anonymous Coward · 1999-10-10 20:39 · Score: 5

.. read this .

Re:Troll! by dirty · 1999-10-11 06:53 · Score: 2

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

Re:No, it doesn't make sense... by mattdm · 1999-10-11 06:53 · Score: 2

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.

--

What is the level of interoperability? by Juln · 1999-10-10 18:09 · Score: 2

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

Re:What is the level of interoperability? by bero-rh · 1999-10-10 19:27 · Score: 2

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.

--
This message is provided under the terms outlined at http://www.bero.org/terms.html

Web Browser ? by 1%warren · 1999-10-10 18:13 · Score: 2

Now that's interesting...
could this mean the end of Mozilla...
wish they'd said more...

--

Full plate and packing steel! -Minsc

Re:Web Browser ? by mattdm · 1999-10-10 18:20 · Score: 2

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

--

Fragmentation of KDE/GNOME components... by Uller-RM · 1999-10-10 18:15 · Score: 2

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.

Re:Fragmentation of KDE/GNOME components... by scrytch · 1999-10-10 21:57 · Score: 3

Sorry about the previous flame... bah, I've been on slashdot too long, I didn't even READ the rest of the post. Where did my attention span go... what was I looking for again?

Just redirect that flame to someone who does argue that XYZ is the One True IPC Mechanism...

I really wish we could delete or moderate down our own posts, just someone else moderate it on down at least, ok?

--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Re:Fragmentation of KDE/GNOME components... by Jon+Peterson · 1999-10-10 18:51 · Score: 5

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.

--
----- .sig: file not found

KDE becomes more and more like closed software by Anonymous Coward · 1999-10-10 18:18 · Score: 3

I'm sorry to say that I have a bad feeling after reading the plans for KDE2. It sounds like KDE is becoming more and more like commercial software.

If KDE moves away from standards (CORBA) and encourages developers to use its own (open, but KDE-specific) shared libraries for communication between the applications and the desktop, then we can forget about building applications that work well under both KDE and GNOME. Sure, it could still be possible to run the application under both environments, but not efficiently and not with all the nice features that each environment offers. What happened to the nice statements about convergence and interoperability between the two major desktop environments?

Both DCOP and Kanossa would only work under KDE, and it would be extremely difficult to implement anything compatible in a GNOME application (it could be similar, but not directly compatible). That is, unless you link your software with the KDE libraries, but then again the developers would then be tied to KDE. Is it really necessary to give away this freedom (not linking with KDE libraries and Qt) to gain some efficiency?

Re:KDE becomes more and more like closed software by Macka · 1999-10-10 18:53 · Score: 2

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
Re:KDE becomes more and more like closed software by bero-rh · 1999-10-10 19:52 · Score: 2

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.

--
This message is provided under the terms outlined at http://www.bero.org/terms.html

Moving away from CORBA by Amphigory · 1999-10-10 20:56 · Score: 3

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.

Re:KDE provides a fully themeable widget engine by Arandir · 1999-10-11 08:57 · Score: 2

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.

--
A Government Is a Body of People, Usually Notably Ungoverned

KDE is not removing Corba by Anonymous Coward · 1999-10-10 21:16 · Score: 3

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.

Re:More rebuts by Arandir · 1999-10-11 10:37 · Score: 2

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

Re:KDE TWO Conference Sponsorship by scrytch · 1999-10-10 22:02 · Score: 2

> 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've finally had it: until slashdot gets article moderation, I am not coming back.

Re:Sycoca makes me laugh by scrytch · 1999-10-10 22:09 · Score: 2

> 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've finally had it: until slashdot gets article moderation, I am not coming back.

Don't forget the seperate apps by Rob+Kaper · 1999-10-10 18:31 · Score: 2

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.

Some comments... (not supposed to be flamebait) by Dacta · 1999-10-10 18:43 · Score: 2

Kanossa: Shared libraries rather than CORBA - yeah, I bet it is faster - it should be, too. While I agree that for simple applications this is important, I believe the future for Linux on the desktop is in enterprise envrionments. Distrubuted computing is absolutly fundemental to this, and Kanossa appears to give that away for a bit of speed. As for DCOP... don't try and tell me that yados (yet another distributed object scheme) is going to be promoted. DCOM, CORBA, RPC, DCE, XML-RPC is quite enough for me, thanks.

Remember Win95/Office95 back on a 486? Slow, wasn't it? But all those technolgies (COM/DCOM) which were introduced then are just begining to bear fruit now.

I think this is a backwards step for KDE - at least Baboon (or whatever the GNOME component model is called) still uses CORBA.

OTOH, I REALLY like the embedding of Java applets. That is going to be really useful in the future.

Comments would be appreciated.

Some replies (also not supposed to be flamebait) by LizardKing · 1999-10-10 19:00 · Score: 3

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

KDE is nice, but it does need some work by HydroCarbon10 · 1999-10-10 19:05 · Score: 2

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.

Re:Rebut by Arandir · 1999-10-11 03:49 · Score: 2

"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

28 of 182 comments (clear)