Slashdot Mirror
The Desktop Wars
An anonymous reader writes "Sam Williams at Upside.Com on
the Gnome vs KDE wars with real quotes from real people."
It's interesting that this debate has faded so much. This article
is a nice summary of the situation right now too- lots of
interesting bits (although the server seems laggy).
The author definitely wins the obscure reference of the day award!!
But I think it was very apropriate. The decision to use animal based lubricants on cartridges was based on practicality, but failed because no one considered the religious/social impacts.
This parallels pretty well what happened with KDE....
Why have we managed to inherit this 'ONE winner ONLY' attitude from Microsoft. I can see that some things need a single standard, like X Windows. I can also appreciate that a desktop manager is a BIG project, making duplication of effort a question-worthy practice.
But desktops are a darned personal thing. Nobody questions multiple window managers, for that matter nobody questions the sheer number of wm's that clone NeXt, alone. The desktop is at least as personal as a wm, even if just a little more development resource intensive. But I'd like to have my preference, and I don't mind if you have yours. But please don't try to send my preference into oblivion.
I'd be far more concerned about seeing some level of interoperability between KDE and GNOME. I look at some of the new announcements, and think, "K-this, G-that, and F-You!" I'd rather pick the desktop environment I like, pick the applications I like, and just run.
I also kind of wish KDE and GNOME were a bit more different - to emphasize the choice aspect a bit. They both chase WinXX a bit too much, I sure wish someone would chase the OS/2 WPS a bit harder.
1) Choice is good.
...
2) Competition for desktops existed before KDE vs GNOME. There is of course, KDE vs MacOS and KDE vs
Win9x and
3) Parallel systems are good when they are creating new code, not when they are duplicating work.
4) Forcing applications to deal with both forces developers to dilute their code to use "common" features between the two instead of use features which only exist in one of the two.
I could see people wanting to use CORBA features of GNOME, but not being able to in KDE. The comprimise would be not to use CORBA which would result in an inferior product. The same is true for other parts of GNOME features which do not have counterparts in KDE, and vice-versa.
I guess KDE & GNOME is akin to Linux & FreeBSD. A large portion of work & code between Linux and FreeBSD is duplicated and for all intents and purposes, wasted. However, people who work on FreeBSD would not work on Linux and vice-versa and at some point will create code which doesn't duplicate the effort of the other programming team... This is an inefficient way to go about working on a project, but it beats the alternative of not producing any code at all.
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
In the end, both projects really should converge (or nearly converge). Why? Choice is good, but only when all of the choices meet certain standards. To give an example: vi and Emacs. Both editors are radically different. but they agree on one simple standard: ASCII text. What does this mean? It means that I can work on a file in either Emacs or vi (or Pico, or joe, or any other text editor) without worrying about who created it.
Gnome and KDE need to do this. They've made one attempt by agreeing on XDND (technically you could say that X is a standard here as well), but that attempt is, quite simply put, feeble. They need to standardize on other issues, such as window manager support and the object models they'll be using. The end goal of this: Take two computers. One has only KDE on it, the other has only Gnome (though both have GTK and Qt). Take one app and compile it on each machine. Then run it on both machines with no problems.
The idea of having to write code for two desktop environments is ludicrous, and developers simply will not do it. TH4ey'll choose one or the other (in the furute it'll more likely be Gnome simply because that frees commercil developers from having to pay monstrously high licensing fees to Troll), and users will have to keep both on their system. That shouldn't have to happen.
As it stands, both DE's are currently flawed. KDE is ugly (even with themes support, which is too limited), the apps don't interact well, and it has the worst WM I've ever seen (though that can be replaced). Gnome, however, should still be in beta; despite the FUD that KDE users love to spread about version numbering it's not quite stable enough (and it still doesn't compile well on LinuxPPC R4; it can be made to compile not not particularly easily). Besides that, the installation is simply too difficult right now. Converge the products, and you have something that's not too shabby.
Comparison, maybe? Anyway, the Sepoy mutiny in India was partially sparked in 1857 because some Indian soldiers were jailed from refusing to use new cartridges. You had to bite off the end of cartridges before using them, and they had been dipped in a mixture of beef and pork fat, which are taboo to Hindus and Moslems. See this article, for example.
The Gnome/KDE "war" gives us the opportunity to think about competing systems in a totally new way. A lot of people think about it in essentially the same terms as Win vs Mac, but I think this is a narrow view.
There are basically two ways of getting a unified system. You can start with a design for how things Should Be Done, and reject anything that doesn't meet the design. It's a good approach - the Mac has done this with great success. We laugh at newbies who try to put a Mac disk in a PC and expect to run the software. Should we?
The other way to do it is to work to make the pieces integrate well. And this, my friends, is more the Linux Way, if you ask me. We don't talk about NFS vs. Samba vs. Netatalk. You've got a heterogenous network? Run 'em all!
Now, to get KDE and Gnome to seamlessly integrate is quite a challenge, both technically and politically. But I have some hope that the two teams are willing and able to work on it, in a way that Microsoft and Apple never could.
Here's a specific example of what I have in mind. Both Gnome and KDE have some mechanism for "themes", ie the ability to configure the graphical look. What if there were a theme setting application that set the themes of both desktop environments, and so that they're consistent? Ultimately, a person might not need to know or care whether an app is KDE or Gnome - it will be a matter of developer preference.
Of course, this vision takes quite a bit of work. A bi-theme application is quite a bit harder than one for a single desktop. Work will no doubt be required to bring the theme systems in harmony. But I think all of this can and will happen.
Raph, a Gnome developer who supports KDE
LILO boot: linux init=/usr/bin/emacs
have been on good terms for some time now, according to Ian Peters, the GNOME Games maintainer. Apparently they're working towards interoperability of object models, which will allow components of one desktop to be used with components of the other, giving end users even more free choice.
/. has greatly increase S/N aroud here and reduced pointless flamewars. And increased prevalence of what Ian calls "score whores" -- people who always write long detailed comments (guilty as charged). It's an improvement, by any measure.
I'll also note that the moderation system on
Now for a hard jab: I'm not at all impressed with Gtk--. You shouldn't have to do signal handling that way in C++, dammit. I know Gtk+ does things that way, but it's C, it has an excuse. I want nice civilised event handling via virtual functions. Someday I'll write it m'self, I guess.
The important differences today are the design ones: the two GUIs have different goals, and the difference for commercial developers: the GNOME libraries are usable without a fee by commercial applications while the Qt ones would require a fee from the commercial developer. Both are equally usable, without a fee, by free software developers.
It also looks as if the Harmony project has been resumed, and that there will eventually be an LGPL version of Qt that is usable without fee by commercial applications.
Thanks
Bruce Perens
Bruce Perens.
But actually, what you are requesting exists in Gtk--. What you want is also the perfered form (it is faster and more efficent). However, as most of the Gtk-- coders come from Gtk+ backgrounds they use the connect form over the derived form. The functionality is there, just most programmers don't use it. (most of the examples are translated from gtk+ so they also use that form, although if you look on the ones on my web page you will find that I use the derived form for all but connections that combine two widgets.) Your code with very small modifications would work with Gtk--. We support both virtual functions and signals as the framework.
Most cases do require the signal system over the derived through. For example, your first demo is coded nicely with just virtual functions. However, consider the case where two widget are interacting. One widget has a slider value and the other is a slider. So the interactions are built like this. (Rob please add PRE to the html format! also lt; and gt; don't work.)
class Gtk_Adjustment
{
signal void value_changed(float);
};
{
public:
};
class MyWindow: Gtk_Window
{
Gtk_Adjustment *adj;
MyApp *app;
public:
MyWindow()
{
app=new MyApp;
adj=new Gtk_Adjustment(0,0,360,5,30,30);
adj.value_changed.connect(slot(*app,&MyApp::set_v
}
};
Here using simple derived techniques would not work well as you do not what to make your application a subtype of the Adjustment. It is better to just connect the method of the adjustment to the method of your application.
We find it best to allow both forms. I am sure you will agree this is the best policy. Do you find any flaws with the signal system in this light? (If I was every writting a pure C++ widget set I would probably use the Gtk-- signal model as it is very flexible.)
--Karl
I agree that at some point in the future it would be nice to after the functions and features from Gtk in a more native C++ form, however, that is not the way things are currently going. Also for portablity reasons having pure C++ is not desirable. We are working very hard to increase the readablity of the Gtk-- wrappers as it seems to be the most intimidating thing to starting programmers.
I hope that at some point Qt will switch their signal system to something closer to Gtk-- as Gtk-- only uses the native C++ features. (Thus avoiding the evil preprocessor.) It should also be noted that the template based signal system is considerably faster that both the Qt and gtk models. The Gtk-- signal library will be released seperately as LibSigC++ probably by the middle of summer.
(BTW I also like Fltk but find its callback system a bit limiting. It strives for a very small footprint that rules out some of the features that Qt and Gtk have.)
Those interested in writting there own C++ widget set might be interested in checking out the libsigc++ module from the Gnome CVS. It provides completely native C++ callback mechanisms with unmatched flexibliy.
--Karl
Use XEmacs.
Grab pc-select from here:
http://www.xemacs.org/elisp.html
Install it as appropriate.
Add this to your ~/.emacs:
(load "pc-select")
(pc-selection-mode)
Beauty, eh.
--
#19845
XFree 4.0 is going to be a quantum leap. Modular design, plug-in drivers for different video cards, native TrueType font rendering, accelerated 3D in a window, etc. check www.Xfree86.org/releaseplans.html for the whole list.
0 1 - just my two bits
One thing that is overestimated is the toolkit dependence of KDE. Sure, Qt is needed for the basic libs, but as they are free software, this will never be a problem.
But why does everybody think *every* KDE app does need to use Qt? For programmers, KDE is just a framework, and you can easily 'plug in' other toolkits.
Ktk for Tcl/TK A Tixwish extension, Ktk offers KDE look and feel for Tcl/Tk developers, without using Qt
StarOffice 5.0, offers some KDE integration like Drag&Drop, Mimetypes and KMenu support. Its widget set is not publicly available, but it shows this can easily be done.
FLTK supports theming in the next release, which does also include certain KDE support
There is no fundamental problem in writing a KDE support lib for GTK, making it easy to add a certain KDE compliance to GTK apps. Maybe it's not as comprehensive as with Qt apps, but common Drag&Drop, colours, Mimetypes, address book, help system still make it a lot easier for the user.
It could be a compile-time option (like Window Maker), or even a run-time check for the KDE system running.
So people won't end up having two desktop environment libs loaded into memory.
Once again:
KDE is a open framework for the developer, and an integrated environment for the user.
The user doesn't care about which widgets are used, as long as they feel the same. The developers don't have to use Qt to make their apps fit into this environment.
I've been debating this issue a lot myself. I like the LGPL of GTK. I also like the fact that it will probably become the standard toolkit for unix if it is not already. However, I adore OO programming even more. So I want a true C++ OO toolkit. I don't want a wrapper that lets you do 'some' C++ while eliminating templates, overloading, overriding, etc
:)
:-)
I've looked on LinuxBerg and found FOX. It looks like pure C++. That is cool since you don't have to deal with a pre processor like in QT. However, it isn't a standard and therefore the learning curve will be harder without having a large support group.
Another user here pointed out FLTK to me. It also looks nice. However, it isn't finished yet and seems to also lack a large audience.
So, I decided to 'get over' the preprocessor issue and use QT. Maybe Harmony will be completely finished some day
I'd love some feedback if anyone has any suggestings or critisim even
Romans 10:9-10
For those who have not yet read this, I quote:
Most European cathedrals show differences in plan or architectural style between parts built in different generations by different builders. The later builders were tempted to "improve" upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. So the peaceful Norman transept abuts and contradicts the soaring Gothic nave, and the result proclaims the pridefulness of the builders as much as the glory of God.
Against these, the architectural unity of Reims stands in glorious contrast. The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design. The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride.
Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.
I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
-Fred Brooks, The Mythical Man Month
Granted, conceptual integrity is a good thing. However, consider two points:
(1) What is a system? For the purposes of this discussion I would call Linux a platform, and an application a system. An application (e.g. text editor) should have conceptual integrity or suffer from bloat, feeping creaturism and other horrors (but see EMACS for a kitchen sink counterexample). But a platform -- no. There is no need for all applications to share the same underlying design concepts. All they have to share is *user interface* design concepts, which are pretty much standard by now in the GUI world. Gnome and KDE should be internally consistent -- true. All Linux applications should be designed on the basis of the same principles -- false.
(2) What if I don't like the underlying design? Let's say KDE is the only desktop for Linux, full of conceptual integrity, but I, personally, hate some of its features. Must I therefore, not use Linux or be limited to command-line interface?
Conceptual integrity in a small system is elegant. Conceptual integrity in a huge system is boring.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
I don't see the parallel existence of KDE and Gnome as a bad thing. On the contrary, I believe it to be very good for Linux to have competing desktops. The reasons are, basically, (1) Choice is good; (2) Competition stimulates improvement and destroys complacency; (3) Two parallel systems are good for robustness and insurance; (4) Forcing applications to be able to deal with both reduces their tendency to exploit "undocumented features" in the API and in the end makes them more robust and upgradeable.
I don't buy the duplication of effort argument. If Gnome didn't exist, its developers would NOT have all been working on KDE. Besides, the outcome of the Mongolian Hordes approach is well known.
The networking arguments (as in, the more fax machines are in the world, the more useful yours becomes) for a single desktop environment make some sense, but not all that much. There is a fine line between too much standardization and not enough standardization. Clearly it's good that most everybody can talk TCP/IP. Clearly, it's not good if everyone is forced to use the same key mappings in, say, an editor. This fine line is shifty and blurry, but IMHO a single desktop for Linux is too much standardization. Again, choice is good.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
The reason we need *One* Interface and only one interface, is standardization. I absolutely hate the fact that when I'm using a GNOME theme, all my KDE windows look completely different. I hate the fact that Netscape's button/scrollbars/checkboxes look totally unlike the ones in KFM.
There are simply too many different toolkits being used out there and in order for Linux to become accepted as having a decent GUI, it needs to have a standard interface. That's the whole idea behind UI's isn't it? The idea that you can use every application the same way? Linux is getting closer, but it's simply not there yet.
As much as I disklike Microsoft's quality of software, their interface is just plain better because it's all the same. The same, of course, can be said for the MacOS. Linux needs a standard SDK/toolkit to work with. It will never become the mainstream OS without one.
I would not consider any time used coding to be wasted. Time used on flamewars are wasted, and as an aside one must say, that there is a lot of time wasted here, but that be it. But as I see it, time used on developing public software is all to the common good.
If Dalheimer is satisfied with his doing (and the rest of the KDE team is the same), he should have a fine time making KDE. If the Gnome people feels this way too, there is no waste.
OTOH if anyone is doing their task as "a tough job, but someone has to do it...", they would probably feel it is a waste. But who knows...
:-) = I am happy
:^) = I am happy with my big nose
C:\> = I am happy with my OS
Yes, the flame wars have somewhat calmed down
which I attribute to the Gnome 1.0 release.
This and the proposed licence change for Qt
have allowed Redhat to include both DE's in their
newest release, and if Redhat includes KDE
it it must be ok, eh?
I am not sure whether the article gets all the
facts straight though. Wasn't the QT Free
foundation announced much earlier than November
last year? Also, what has the fact of the
smoothness of the OpenLinux 2.2 install much
to do with KDE or any desktop.?
And what about the statement that
"in Europe, (where) independence from American
software companies invokes issues of
national security, not just personal choice."
I doubt very much that the KDE developers were
worrying about national security!
It would be nice if the authors would have also
gotten some quotes from Gnome developers, after
all it takes two sides to end a (flame) war.