Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Is KDE digging its own grave?

By enterfornone in Technology
Tue Dec 26, 2000 at 12:34:37 PM EST
Tags: Software (all tags)
Software

In the last month the KDE project has made a number of advances that provide greater interoperability between their desktop environment and the rival Gnome environment. Earlier in the month they announced the Extended WM Specification allowing compliant Window Managers to work with both the KDE and Gnome environments. And in the past week they have released Xparts allowing components written using toolkits other than KDE to be embedded in KDE applications, and QGtkWidget which allows GTK widgets (the widget set used by Gnome) to be used in KDE applications.

Since Gnome components can now be used in KDE, but not vice versa, is there any reason to develop applications directly for KDE?


As Linux and other Unixes gain popularity on the desktop, the demand for easy to use desktop software has increased dramatically. Traditionally desktop applications under Unix have used the proprietary Motif toolkit and CDE desktop, but as free alternatives to these have become popular, application developers are being forced to take sides.

By far the two most popular desktop environments under Linux are KDE and Gnome. But while both are popular, neither are dominating the market. Application developers who choose one desktop will therefore only be serving half the market.

In the past the solution has been to only use features that would play well with both desktops. But this has resulted in applications with limited functionality. One function that is rarely utilised in Unix, but common in other operating systems such as Microsoft Windows is the ability to embed a document from one application into another. Both Gnome and KDE have the ability to do this, but via very different methods.

But the recent announcements by the KDE team have changed that. Now users will have the ability to embed components into both KDE and Gnome applications. However the catch is, it will only work if the component is written using the Gnome libraries, it can't yet be done the other way around.

By supporting Gnome components under KDE, the KDE have created a standard component architecture for Unix. Unfortunatly for them it is the component architecture of their competitor. Now that they have done this, is there any reason to develop components for KDE?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o KDE project
o Gnome
o Extended WM Specification
o Xparts
o QGtkWidget
o GTK
o Also by enterfornone


Display: Sort:
Is KDE digging its own grave? | 40 comments (34 topical, 6 editorial, 0 hidden)
Interoperability (3.42 / 19) (#3)
by Signal 11 on Tue Dec 26, 2000 at 12:29:27 AM EST

Saying interoperability is bad is the same thing Microsoft has been guilty of repeatedly. But that aside, if anything, this move by KDE indicates to me they are in a position of strength and they know it. By extending the symbolic olive branch to Gnome they're telling the world that they're moving past the "Us v. Them" propaganda, as well as indicating that they believe that their product is sufficiently superior to Gnome that they can "get away" with interoperability.

Lastly, I suspect that Gnome has succumbed to the very thing it has feared so much - becoming too political and cliquish, which has resulted in huge problems cropping up in the toolkit and a general slowdown in the production of code. Don't get me wrong - I support neither KDE or Gnome as neither meets my needs presently, however I believe KDE is further along the path towards a practical linux desktop. Either way, it couldn't hurt for Gnome to impliment similiar functionality (can they?) and work towards merging the two projects. There's far too much work to be done to have parallel efforts this early on in the development of a desktop for linux.

Personally, I wish somebody would ditch XWindows and create an architecture that was alittle more modern, and fast... I don't think XWindows will work well enough to compete with Windows in the gaming or business environments until it either ditches XWindows, or seriously re-engineers its core architecture.. which is basically the same thing. We need a low-overhead way to write directly to video memory.


--
Society needs therapy. It's having
trouble accepting itself.

there is one, at least. (3.00 / 4) (#14)
by wolfie on Tue Dec 26, 2000 at 09:29:27 AM EST

Personally, I wish somebody would ditch XWindows and create an architecture that was alittle more modern, and fast... I don't think XWindows will work well enough to compete with Windows in the gaming or business environments until it either ditches XWindows, or seriously re-engineers its core architecture.. which is basically the same thing. We need a low-overhead way to write directly to video memory.

Well, there's Berlin

[ Parent ]

Reengineering X (3.87 / 8) (#18)
by roystgnr on Tue Dec 26, 2000 at 02:22:10 PM EST

I don't think XWindows will work well enough to compete with Windows in the gaming or business environments until it either ditches XWindows, or seriously re-engineers its core architecture..

No kidding. People rant about usability and feature creep, but business environments are made or broken by whether your spreadsheet's dropdown menu appears in .02 seconds or .01 seconds. Why else would your boss have purchased that new dual PIII-800, if he didn't really need it? And it's only getting worse for X, as greedy programmers write with these new Pentium class systems in mind. Why, I've heard that some toolkits may soon be using "pixel-map themes" which would slow things down even more!

which is basically the same thing. We need a low-overhead way to write directly to video memory.

Yes, if only someone would implement some sort of Direct Rendering Infrastructure, or Direct Graphics Access, then things would be wonderful.

Really, now. I thought you had stopped trolling after you left Slashdot.



[ Parent ]
Interoperability! (4.13 / 15) (#5)
by joeyo on Tue Dec 26, 2000 at 12:38:08 AM EST

Since Gnome components can now be used in KDE, but not vice versa, is there any reason to develop applications directly for KDE?

Hmmm. It would seem to me that letting KDE run Gnome components would only help KDE: It GREATLY increases the number of apps which work with KDE. Plus, so what if people don't develop specifically for KDE? That sort of talk smacks of Microsoftism. I want interoperability!

--
"Give me enough variables to work with, and I can probably do away with the notion of human free will." -- demi

What I'd like to see (2.40 / 5) (#6)
by djkimmel on Tue Dec 26, 2000 at 12:53:56 AM EST

I'd really, really like to see something similar to OLE on Unix.

Now, first off, I'm not really a hard core programmer, so my terminology might not be correct. When I refer to OLE Automation, I'm refering to the things that let me control one program from another and allow me to create and use reusable components.

At work, I have a Windows program that reads text files from a directory on a Unix server, uses MS Word to format them, then uses WinFax to send them. The program that does all this is something I hacked together in Visual Basic. It also uses a custom control that comes with Visual Basic, but is not accessible by default, you need to explicitly reference it.

The reason it can do this is because there are a set of services and APIs available on Windows which allow all of this to happen.

Windows has a mechanism for automating another process, which is how my program talks to Word and WinFax. There is also a mechanism for creating and using reusable graphical controls, which is how my program gets access to the Windows Common Dialogs and some other Common Controls that VB doesn't let you use by default.

These services are not Microsoft specific either, I have also used them with Delphi. In fact, I have created components in Delphi and used them in Visual Basic.

That is what I would love to see in Unix. KDE embedding components from Gnome is a small step in that direction, lets hope that someone takes the next step and makes it universal.
-- Dave
Bonobo (3.66 / 3) (#7)
by fluffy grue on Tue Dec 26, 2000 at 01:12:49 AM EST

Isn't that what Gnome's Bonobo component architecture is all about?
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Well... (3.33 / 3) (#8)
by djkimmel on Tue Dec 26, 2000 at 01:38:32 AM EST

I checked it out and yes, this is supposed to be what Bonobo does.

So now I've got to wonder - why did the KDE guys make something to embed GTK widgets in Qt apps instead of something to embed Bonobo widgets in Qt apps? The latter strikes me as more useful since, in theory, the Bonobo widget could be written in anything, using any toolkit, not just GTK.
-- Dave
[ Parent ]
Huh? (3.00 / 1) (#23)
by fluffy grue on Tue Dec 26, 2000 at 07:27:47 PM EST

Um. GTK widgets embedded in Qt widgets gives things like the GTK color picker and the GTK pixmap stuff. Bonobo isn't a widget, it's more of an IPC mechanism, and I don't see any reason that Bonobo would be bound to GTK at all, and even if it is, then that means that a GTK-based Bonobo-aware widget could be embedded inside Qt like any other GTK widget.

I don't see how the existence of Bonobo precludes the usefulness of GTK embedding.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

I meant... (2.00 / 1) (#25)
by djkimmel on Tue Dec 26, 2000 at 08:09:38 PM EST

...a Bonobo widget, as opposed to a GTK widget or a Qt widget.

Bonobo, from what I read, is a system to allow functionality similar to OLE under Unix - automating other applications, creating and using shared controls, etc.

So, if Bonobo does everything that OLE does (I didn't read too much in depth), then I should be able to write a Bonobo component using straight C which calls Xlib functions direction to display its GUI and embed this component in any application that acts as a container for a Bonobo component.

I'm thinking of Bonobo as being similar to OLE - is this right?
-- Dave
[ Parent ]
Yes, and? (3.50 / 2) (#27)
by fluffy grue on Tue Dec 26, 2000 at 10:47:17 PM EST

Yes, Bonobo is supposed to be an OLE-type thing for UNIX. And I still don't see how making a Bonobo widget for Qt would be more useful than making a GTK metawidget for Qt - your whole question was (to paraphrase) "Why not make a Bonobo widget for Qt? Wouldn't that be more useful than making a GTK metawidget for Qt?" These are orthogonal things - making a GTK metawidget for Qt is a separate thing from making a Bonobo widget for Qt. They're orthogonal concepts. What making a GTK metawidget for Qt does is it makes it possible to reuse code from GTK within Qt (and really, GTK isn't Gnome just as Qt isn't KDE), which means that Qt-based programs have a lot more widgets to choose from all the sudden.

Basically, the whole premise of this article is kinda flawed, since really, the GTK metawidget for Qt makes Qt a strict superset of GTK, rather than somehow making Qt "less competitive." Some people happen to like Qt's object model more than GTK's, and by enabling a Qt programmer to use widgets from both, it makes KDE programmers a lot happier without giving any clear advantage to Gnome programmers - in effect, it makes KDE more compelling to write for, since it has everything Gnome has.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

I see... (2.00 / 1) (#28)
by djkimmel on Tue Dec 26, 2000 at 11:45:00 PM EST

...just how unclear I was being. Sorry.

I think a Bonobo widget would be more useful because you could potentially embed ANY Bonobo-compatible widget into a Qt program, not just a GTK based one.

This is, in my view, the argument between a VBX control and an OCX control, back when both were in use. A VBX control can be created by Visual Basic and used in Visual Basic. An OCX control can be created in anything and used in anything.

Relating that to this discussion, a Bonobo widget is like an OCX and a GTK widget is like a VBX. Obviously, the OCX is more useful since it isn't tired to one particular language/development environment.

If this is valid, then my argument stands, it would be more useful to create a Qt widget that lets you use a Bonobo widget in a Qt program. However, if I'm out to lunch on this, which is very possible, then I suppose its all a moot point.

Also, if a GTK widget is the same thing as a Bonobo widget, then my arguement is perfectly invalid too.
-- Dave
[ Parent ]
Ah, I see... (3.00 / 1) (#29)
by fluffy grue on Wed Dec 27, 2000 at 01:24:56 AM EST

...but doesn't an OCX widget have a lot more overhead than a VBX widget? After all, an OCX is (from what I understand) intended for OLE, which is basically a heavyweight IPC mechanism, which is what Bonobo is intended for. This gets outside the realm of my knowledge on Bonobo, but I thought that Bonobo was for things like, say, embedding a Gnumeric (i.e. Excel) spreadsheet inside an AbiWord (i.e. Word) document - that is, the purpose to Bonobo is much more like 'let's embed some application-inspecific data into this document' than 'here is a nifty thumbwheel widget to use' - that is, a thumbwheel widget would be a GTK widget (and would be used in Qt using this wrapper library or whatever it is), and an embedded Tetris game would be a Bonobo widget. They're for different application domains, and so I don't think the OCX/VBX comparison really applies...
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Interesting take on it (2.00 / 1) (#30)
by djkimmel on Wed Dec 27, 2000 at 02:04:55 AM EST

I got the impression from Bonobo that it would basically do everything that OLE does - from custom controls to embedding documents.

From what I see now, this widget has the potential to be better in that it can be optimized specifically to embed GTK widgets, and since GTK is open source it can be modified to accomidate such embedding. Something like Bonobo has the advantage of being more general, but as you point out would have more overhead.

So here's the question that brings up: Will the GTK developers modify it to better accomidate embedding?
-- Dave
[ Parent ]
_ (2.00 / 1) (#31)
by fluffy grue on Wed Dec 27, 2000 at 02:14:09 AM EST

Jeeze, I don't know, what are you asking me for?

:)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

true (none / 0) (#38)
by skeezix on Sat Dec 30, 2000 at 03:59:56 PM EST

Bonobo is not necessarily Gnome-specific. Unlike KParts, it could easily be used by any language or platform. It was designed from the beginning with that in mind.

[ Parent ]
This isn't OLE (Re: What I'd like to see) (5.00 / 1) (#36)
by rsmith on Sat Dec 30, 2000 at 01:29:22 PM EST

At work, I have a Windows program that reads text files from a directory on a Unix server, uses MS Word to format them, then uses WinFax to send them. The program that does all this is something I hacked together in Visual Basic. It also uses a custom control that comes with Visual Basic, but is not accessible by default, you need to explicitly reference it.

I think this isn't really OLE. It is more like the scriptability that UN*X has enjoyed for decades.

In fact, you could do all this, or better, on unix:

  • read and filter the data, e.g. with perl, or awk.
  • format it with perl, (La)TeX, enscript or whatever
  • fax it with one of the several fax programs available (or mail it)
  • wrap this whole thing up in a cron job to do it regularly.

You could do this with shell-scripts, perl. python or whatever tool that suits your taste.

I find that I tend to write more and more shell-scripts to automate silly little things. To me, this is one of the single biggest wins that I got from switching to Linux. (next to more freedom)

IMHO, OLE is a mess. Whenever I use OLE at work, (usually to embed a spreadsheet or picture in a Word document, I see several things happening

  • file sizes explode (even when you just link to something).
  • applications slow down or crash.

IMHO, the unix philosophy of small programs doing one thing well, and work together with others seems much more elegant.

But then again, I don't care much about KDE or GNOME either.

Roland



[ Parent ]
He who would rule must know how to serve. (4.00 / 9) (#10)
by elenchos on Tue Dec 26, 2000 at 04:32:24 AM EST

The article makes it sound like the KDE has solved a mutual problem by being cooperative rather than competitive with their "rival." It has an almost Taoist ring to it: by seeming to give something up they gain everything.

Adequacy.org

Let me ask the question the other way around.... (3.55 / 9) (#13)
by 11223 on Tue Dec 26, 2000 at 09:13:13 AM EST

Now that KDE supports embedding GNOME components as well as KDE's own KParts, what reason do I have to use GNOME? To me, there's no reason not to use KDE anymore, because KDE now supports all types of objects. It even supports using Netscape plugins as internal components. (Don't believe me? Set konqueror up to use your Netscape plugins, and then right click on a PDF file and choose "Preview in -> Netscape plugin". You'll be seeing your PDF file in Acrobat Reader if you have it.)

--
The dead hand of Asimov's mass psychology wins every time.

conversely.. (none / 0) (#37)
by skeezix on Sat Dec 30, 2000 at 03:56:26 PM EST

Xparts allows you to do in KDE what you've been able to do from the beginning with Gnome's Bonobo technology. So the argument is moot. As always, one will use the environment they like the best; there are advantages and disadvantages to both.

[ Parent ]
Similar argument to 'Linux' vs 'Windows'? (3.71 / 7) (#15)
by Speare on Tue Dec 26, 2000 at 11:06:14 AM EST

Since Gnome components can now be used in KDE, but not vice versa, is there any reason to develop applications directly for KDE?

Reworded: Since Wine lets Windows apps run on Linux, but not vice versa, is there any reason to develop applications directly for Linux?

This isn't a troll, or a stab at the Linux groupthink, but a serious question that my development team has to address in the nine-to-twelve month range. Is writing for compatibility under Wine enough, or do we have to limit native functionality and use compatibility widgets like Qt or GNOME? Since we're looking at a 90% vs 5% desktop market discrepancy, supporting the underdog is more of a political motive than a business motive.

Bringing this back to the posted question, any such standards-building move changes the landscape of the decisions faced by potential developers. Does Wine make Linux more or less targettable? Does KDE's GNOME-compatibility make KDE more or less targettable?


[ e d @ h a l l e y . c c ]
Why does it have to be a zero sum game? (4.44 / 9) (#16)
by Anonymous 242 on Tue Dec 26, 2000 at 11:10:58 AM EST

First off, as a side note, Gnome's bonobo has been able to do this for some time. Secondly, this is not as big of a deal as it seams. If I understand other people's comments on this correctly, there were no changes to the KDE code for this, but the code that is getting embedded needs to have some significant modifications.

My real point is that why does interoperability have to be a zero sum game? Why does KDE (or Gnome) offering interoperability with other took kits and environments have to be detrimental? I know many Linux fans that use KDE or Gnome for the desktop and use apps built on both the KDE and Gnome libraries. Just because I use Gnome at home doesn't meant that I don't use any KDE apps. (My wife keeps Knotes on her Gnome taskbar. :^O )

In advancing interoperability though Window Manager specifications and the ability to embed foreign components, desktop environments like Gnome and KDE are giving their users something world domination advocates don't like: choice. I hope that someday desktop environments are true commodities and that enough smart middleware exists that I can seemlessly wire together divergent applications. Bonobo and Kparts are decent starts toward that future, but a lot of work needs to be done.

In the meantime, quit acting like There Can Only be One. There is room for plenty.

The big picture is more clearly KDE. (3.66 / 3) (#17)
by Wolfkin on Tue Dec 26, 2000 at 11:47:21 AM EST

Now that they have done this, is there any reason to develop components for KDE?

Well, there's always appearance. :) Seriously, while this means that components are better written in GTK, for inter-operability, it also means that apps that function mainly by embedding components are better written for KDE. When deciding what to create, many people, observing that there are multiple components for nearly every conceivable purpose, would choose instead to combine them in new, useful ways, and the choice of environment for that is now clearly KDE.

Randall Randall.

the BSDs (3.00 / 2) (#19)
by Jordan Block on Tue Dec 26, 2000 at 02:52:21 PM EST

In my own experience, KDE seems to have for of a following in the BSD crowd. I'm not sure why this is, or even if there is a reason for it, but it's something I've noticed.

Re: the BSD's (4.00 / 2) (#22)
by UrLord on Tue Dec 26, 2000 at 06:40:38 PM EST

That's because BSD users are known to be snobbish, just like KDE users. Of course I use OpenBSD, and I use KDE more than Gnome. ;)

Seriously though, KDE seems to have a cleaner design and has always run better on my machines. I may have been using older versions of Gnome, but the KDE version would have been off the same cd.

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

Re: the BSDs (4.00 / 2) (#24)
by sbamattre on Tue Dec 26, 2000 at 07:50:08 PM EST

That has been true for me too. I think that it has to do with the fact that KDE/KDE2 ports *seem* to be cleaner and better maintained than the Gnome/Helix port. Or maybe it's just that KDE fits the philosophy of the BSD community.

[ Parent ]
Re: the BSDs (5.00 / 1) (#33)
by YellowBook on Wed Dec 27, 2000 at 11:20:06 AM EST

Could nationalism have something to do with it? Both the BSD family and KDE seem to be more popular in Europe, while GNOME is more popular in the US and in Latin America...



[ Parent ]
Originating country (4.00 / 1) (#40)
by job on Fri Jan 05, 2001 at 06:31:04 AM EST

That would be strange, since Linux originiates from Finland (in nothern Europe)...

[ Parent ]
BSD vs GNU (5.00 / 1) (#34)
by Brandybuck on Wed Dec 27, 2000 at 09:26:44 PM EST

As a part time BSD user (the rest of the time it's Linux), I can offer my own perspective:

1) KDE works and works well. It's also "friendly" to non GNU environments. A lot of GNOME apps seem to be Linux-or-GNU-only which is a big pain in the butt. I can get them to work under BSD, but they're quirky.

2) I'm running BSD, not GNU. I suspect that there is at least a sizable minority of Linux users who choose GNOME simply because it's GNU and thus is the "native" desktop for their GNU environment. Neither KDE nor GNOME are native to BSD, so we have to evaluate them solely on their merits, and not according to which "team" they are on.

[ Parent ]

BSDs, GNU, politics&tastes (5.00 / 1) (#35)
by fsmunoz on Thu Dec 28, 2000 at 07:52:35 AM EST

While some may call them 'snobish' the truth is that there is a number of BSD users that refuse to touch GNU software be it good or bad; KDE/GNOME opposition feets well into this scheme, since initially the arguments were rather political. I'm not saying that other considerations do not come into play, but all in all it's a matter of taste, need and politics. I run GNU, not BSD. Still, I can use GNOME or KDE, but I must admit that I'm biased toward GNOME. In fact, I run WindowMaker (a part of GNUStep), and so do many BSD ppl; in fact I don't have a need for any Desktop Env besides WindowMaker (I find the OpenSTEP design very appealing). In the end the fact is that each one should choose what the hell he/she likes more, since both GNU and BSD are free OS's with free-software. I must agree with another friend in this thread that said that GNU users might tend toward GNOME becasue it is 'the' GNU Desktop (well, one of them at least), but the same number of ppl, or maybe even more, use KDE because it is *not* the GNU desktop. yours, fsm

[ Parent ]
Consistent interfaces are good (4.16 / 6) (#20)
by jesterzog on Tue Dec 26, 2000 at 03:39:33 PM EST

Unfortunatly for them it is the component architecture of their competitor. Now that they have done this, is there any reason to develop components for KDE?

I hope so. I also hope that soon there's no reason to develop components for Gnome, aswell.

To me, the idea of trying to keep features and interfaces propriety and restricted to keep market share seems a bit childish. It's like have a website with no links to anywhere offsite in a feeble attempt to lock users in and prevent them from leaving. People will come, but then they're trapped and once they escape they won't come back. It doesn't do anything for the reputation, either.

Also having two (or more) incompatible desktops to develop for is irritating to say the least. The day that developers can develop to a standardised set of API's and let the desktops compete between each other independently is the day that portable software is going to start getting more reliable and usable.

Not that a lot of it isn't already - I'm not trying to troll. But even within window managers, interfaces are often very inconsistent because developers override them to keep the interface consistent within the product.

There's another webpage analogy here, because the web's just starting to get this right with XHTML and independent style sheets. By designing a page to the standards and saying what the bits of the interface are supposed to do, the browser can put together a presentation to suit the user. IMHO, this is what window managers and desktops should do. They can compete with each other based on who the users are and what they want, but keeping the interface consistent benefits everyone.


jesterzog Fight the light


Standard interface. (4.00 / 2) (#21)
by DrEvil on Tue Dec 26, 2000 at 06:13:50 PM EST

I agree, what we really need is a standard way of doing things. I'm not suggesting that we should stick to either KDE or Gnome, what I think we need is one way to do it, but you can use what ever environment you want.

You then would be able to use Gnome, KDE, or product X even, as long as they all follow the same standard. It wouldn't matter which is used, the interface might be different depending on which system is used, however the interface would be consistant across that one system.

I think this would be the right way to do it because if I liked the way GTK drew it's widgets then I could use the GTK system, or if I liked the KDE way of drawing widgets I could use it, or if I didn't like any of them I could make my own widget set.

This would allow for a consistant interface which everyone seems to think should happen, as well as leave the flexability for everyone to chose thier own system settings.

[ Parent ]
Not by a long shot.. (4.00 / 3) (#26)
by Chiron on Tue Dec 26, 2000 at 09:43:25 PM EST

Just because KDE can embed a component, doesn't mean that component has full access to the KParts API, or has the full abilities of the original component. Case in point, using an X app in KParts really just causes it to regard the enclosing app as a window manager, and respects its decisions on window size, placement and elevation relative to the other windows.

Frankly, I see embedding X apps as a kind of gee-whiz/proof-of-concept for the KDE guys.

The integration of GNOME components, while interesting, suffers the same situation, that the two APIs are not isomorphic to one another. There are capabilities in Bonobo that aren't in KParts, and vice versa. While it should be possible to write components that work under both fairly well, developers will probably still find it necessary to write dedicated interfaces to each to integrate tightly.

By this logic, KDE already dug its grave... (3.33 / 3) (#32)
by PresJPolk on Wed Dec 27, 2000 at 08:35:34 AM EST

..by maintaining interoperability with console apps.

By having a terminal emulation facility, KDE ensures that standard Unix console apps will function unmodified from within KDE.

So, the question is, if one could write a console app, and have it run under the Unix console and under KDE, why would any write a KDE app?

Here's the answer: because KDE has a lot to offer, and the way to take full advantage of KDE's features and facilities is to write KDE apps.

Besides, it's not as if using KDE or GNOME bars you from using the other environment's apps. I could run GNOME's panel if I wanted to, or Gnumeric, or Gabber. I just choose to run kicker, KSpread, and Kit instead.

As long as there are people who prefer KDE apps to GNOME apps, KDE apps will continue to be written. Portability at the expense of usability is not a tradeoff everyone makes.

The Real Question(tm)... (none / 0) (#39)
by tsmith on Tue Jan 02, 2001 at 05:52:47 AM EST

Since Gnome components can now be used in KDE, but not vice versa, is there any reason to develop applications directly for KDE?

The real question is: since Gnome components can now be used in KDE, but not vice versa, is there any reason to still use Gnome?


Programmers do it in Real Time

Is KDE digging its own grave? | 40 comments (34 topical, 6 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!