The Desktop Wars 132
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).
My thoughts (Score:1)
My Take. (Score:1)
I agree with the article that perhaps it would have been better if there hadn't been a 'schism' into two camps, but now we have Gnome and KDE as fully independant projects. Competition is good.
I've used KDE up until now, and nowadays I find myself switching equally between KDE and Gnome, running both KDE and Gnome applications in either environment. There are things about either environment I like. The thing is, I'm finding a lot of duplication...that's too bad, in a way. But I'm almost at the point of cross-breeding Gnome & KDE. I like KFM better than GMC for desktop management, and the Gnome panel is better than the K panel. If they all talked the same language at some level I could mix it all up be quite happy!
At any rate, if the flames are all dying down, then all I can say is GOOD. Gnome & KDE are going to take us to the next level, that's for sure...Microsoft isn't going to know what hit them. (although how much do you want to bet Microsoft will put some form of 'theming' into their next UI release?)
Re:My thoughts (Score:1)
The rest are vendor support issues or things that have been addressed already.
Most of the available VidCap cards use the line in channel for their audio so sharing of sound resources even with the kernel drivers has never been an issue.
Multimedia? The way you use the term it's just a roundabout way of bringing up vendor support issue again.
IOW: all that's really wrong fundementally with the Unix desktop now is that whole !DOS cliche'. It doesn't have 'all the drivers' and 'all the apps' that 'DOS has'.
It's an ancient argument actually, a bit tired then (a decade ago) and even moreso now.
http://www.jorsm.com/~mosfet/kde/kdetheme.html (Score:1)
Re:Unfortunately... (Score:1)
Despite how Gnome advocates like to trumpet the use of CORBA in their DE, KDE would seem to have the most stable foundation to build on in the form of KOM/OpenParts [kde.org].
I think it would be great to see both DE use this fantastic technology. With a standard implementation of KOM/OpenParts and a common DND protocol in use between the two projects, I believe that convergance or at least increased inoperability would be much closer. I fully acknowledge though that this is unlikely to happen in the near future as both camps are likely to be reluctant to change their ORB implementations and in particular the Gnome camp who have spent so long (needlessly IMO) implementing their own ORB.
On a somewhat unrelated note, although the KDE/Gnome debate may be far less vocal, there still exists a large bias towards Gnome by the story posters(CmdrTaco et al). /. freely acknowledges its bias towards Linux and open source/free/call it what you want projects, but the prejudice that would seem to exist against KDE is bad. KDE is a fantastic piece of work that deserves as much credit as all other projects and I think that CmdrTaco etc. should try to be more objective in their story posting and if they are going to announce every Gnome pre release they should also do the same for KDE.
I am a big fan of /. and it is one of the few web sites I read every day without fail. However, I think /. needs to overcome its bias lest it fall into the trap of forcing the opinions of a few on everyone, this is one sure way to lose readers.
Robert
Try NEdit (Score:1)
review (Score:1)
install an all around Linux web and modem server at work.
Does a pretty good job spooling mongo sized print jobs, too.
I've just installed the new Caldera 2.2. This is the first site I
browsed with kde. You've got a winner here. The modem
setup is a snap, and the desktop is pretty and well organized.
I like it.
I've got a SillyCelery 300 with an aging Number Nine Vision
330, and it's quite snappy. Much better than Win98.
Along with compatibility with my huge collection of TrueType
fonts, I like to have my apps start up in the virtual screens
of my choosing. Applix (I've got the demo) in screen One,
Netcrash in screen Two, asWedit in screen Three. Other
than that, I could lose DOS for this in a minute.
Re:Goofy Metaphor of the Day! (Score:2)
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....
There can be only ONE! (Microsoft/Highlander...) (Score:3)
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.
I don't care which I use... (Score:1)
I happen to be using KDE, because at the time I set up our company network, it was most usable. Some of my users are now on GNOME, and I expect more to switch when I install Red Hat 6.0.
As long as we have CORBA / Wine OLE2 / K/OM interoperability, and window managers that are compatible with both, then I'll be happy.
HowTF am I supposed to enter <-> (or ) into these poxy comments?
Re:Choice is good (Score:2)
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.
--
Re:how does one switch between gnome and kde in RH (Score:1)
I don't know what the *official* way to do this is, but I did it this way: first, I started in Gnome, I used the gnome switcher tool in system utilities to switch to KDE: I then had two panels, the Gnome and KDE panel. Then, I switched to Afterstep.
From Afterstep I had only the file manager from KDE, and nothing, seemingly, from Gnome. The file manager was in the form of the autostart folder, etc on my desktop. Then, I found a Gnome panel app in the bin, the mem and cpu one, and ran it. That started up the Gnome panel in Afterstep.
The Gnome panel has the KDE panel on it, through the "foot". So, that is how I got all three window manangers to work in one with 5.9.
And, it is cool.
Re:My thoughts (Score:1)
Re:My thoughts (Score:1)
Currently, XFree86 supports quite a few cards in their SVGA server, and the number has grown lately - for instance, now you can use SVGA or s3v servers for s3v cards.
Re:My thoughts (Score:1)
On my system, the program gxedit has this feature. I'm checking to see whether gEdit does too... yes, it does. I don't know if KDE has anything similar, because I haven't used it, but I suspect if you looked, you'd find it.
Phil Fraering "Humans. Go Fig." - Rita
BULLSHIT (Score:1)
Java - how to turn a Xeon into a 386. Server side java is worthwhile, but as an environment for writing industrial strength client applications it SUCKS. It is much slower, less reliable, and less expressive (ie it takes 500 lines of java to do the equivalent of 50 lines of STL intensive C++ - try writing something like blitz - http://monet.uwaterloo.ca/blitz/ in java...)
However the main problem is that the system libraries (AWT/Swing especially) are just not reliable. I really think MS has better programmers than Sun.
As for C/C++ being outdated - well I might believe it when I see one decent application written in Java.
Not strange (Score:1)
- We want to replace proprietary software with free software.
- We want to replace bad/Microsoft software with good/non-Microsoft software.
KDE was (originally) fine with regard to the goals of the second group, but totally ignored the goals of the first group. With the new Qt license, the problem has gone away. KDE is no longer a threat to the first group, so we can now choose solely on technical merits.
Re:slumbering dragons (Score:1)
Re:Tried EMACS? (Score:1)
Daniel
Re:My thoughts (Score:1)
Daniel
*shudder* (Score:1)
The fact that they're both based on sane languages? The fact that their APIs aren't baroque to the point of incomprehensibility? The fact that they aren't bogged down by a virtual machine? The fact that I don't feel like tearing my hair out in handfuls every time I sit down to use GTK+? (Swing produces this reaction)
The only reasons to use Java are:
(a) You want your program to run on multiple platforms but don't want to release the source.
(b) Web applets, where you want to distribute a compiled version of the program
Of the two..I don't have a whole lot of sympathy for (a) and unless you're suggesting that we should move to only using web-page applets, I don't think (b) applies.
Daniel
Re:No, HotSpot produces faster code than C or C++ (Score:1)
a GUI for than those outdated languages:
This statement makes me wonder whether you've used both Java and GTK+. I find it to be easier to write a GUI in *C* using GTK+ than Java, which is ridiculous--a real OO language ought to be better at this. Swing's API is simply too baroque; it makes it possible to do a few complicated things 'simply' (for small values of simple
and will work on all platforms including
Windows, BeOS and Macintosh - platforms that Gtk+ and KDE don't support.
As far as I know, GTK+ supports Windows and will soon support BeOS. I doubt that the desktop environments would work too well under these systems, but that's partly because they already have proprietary desktop environments and replacing them is non-trivial.
Daniel
Make that three ;-) (Score:1)
Re:In (yet another) surprising twist of discussion (Score:1)
Writing GNOME apps with Qt (Score:1)
What you said of KDE can be said of GNOME as well.
Try VDK (Score:1)
It's a fairly nice set of Foundation Classes modeled on VCL from borland. I like it, but then again I'm a C++ Builder and OWL person, so it is very familiar.
Look... (Score:2)
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.
KDE/Gnome components and component models. (Score:1)
What KDE and Gnome could use is the component model that lives behind Swing, namely Java Beans and Enterprise Java Beans. This would allow the two systems to interconnect easily.
For those of you that don't like Java in any shape or form then consider that the OMG is using the EJB as a baseline for its forthcoming component model. Contrary to received opinion this has bindings for C++ and Java at the moment. I would expect bindings for other languages to be incorporated later.
Correcting articles? (Score:1)
It would benefit everyone. The authors wouldn't have to be embarrased over their writings. 'We' would have more people to understand what things are really about and everyone else wouldn't have to be misinformed.
Re:Goofy Metaphor of the Day! (Score:2)
Integration science (Score:4)
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
Why wasteful? (Score:1)
//widgetlib.h
//widget libarary
//please excuse munging of indentation by comment system...
class gtkbutton {
virtual void handle(click *event)=0;
}
//now mycode.cpp
class myButton : virtual gtkbutton {
void handle(click *event) {
printf("Why did you click me?\n");
}
}
Granted, this may not always be a good idea -- while I like the idea of deriving classes from the widgetset and imbueing them with my own functionality, it's silly to have millions of little button classes. In this case, a more logical organization say at the form level is required -- and here a signalling system makes sense. We connect a function to each signal from a button in our form.
But I still want to derive a form from a base widget class of some kind. It might look something like this:
class appWindow : virtual widget {
//conceivably appWindow would be better derived
//from some kind of container class, itself derived
//from widget? i dunno.
gtkbutton *but1, *but2;
void but1_click(click *event) {
printf("you clicked but1!\n");
}
appWindow(...) {
but1 = new gtkbutton("foo",...);
but2 = new gtkbutton("bar",...);
but1.click.connect(but1_click);
}
}
This has some inherent disadvantages -- it does force a coding style on the
D'oh. Submit button next to preview button. (Score:1)
Boy, that code is unreadable w/o indentation...
I agree (Score:1)
class myApp : Gtk_Window {
private:
Gtk_Adjustment *adj;
void set_value(...) {
}
public:
myApp(...) {
adj = new Gtk_Adjustment(...);
adj.value_changed.connect(slot(*myApp,&myApp::set
}
};
so I would still derive from the more important one. But really only because I like the idea of keeping functionality in the interface object. That is to say, I like thinking of an application as a kind of Gtk window with the added functionality I want in there -- thus, all my code is in objects derived from Gtk base objects.
Unless there's a reason the above pseudocode wouldn't work?
Next question (heavily load w/regard to my next project): how usable is Gtk-- in win32? I don't relish having to use MFC
The teams themselves (Score:4)
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.
Not terribly accurate (Score:2)
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
Re:Choice is good (Score:1)
There are some things in KDE that I prefer over Gnome. There are also some things in Gnome that I prefer over KDE. In my view, they will each get better. Hopefully there will be some sort of idea sharing as both projects go forward.
To the folks at each project, I thank you for all of your efforts in providing a fine desktop environment. I don't feel that I have been cheated by your parallel efforts. On the contrary, I feel that I have benefitted.
Develop with wxWindows, run everywhere (Score:1)
Just develop your apps using the wxWindows [wxwindows.org] toolkit. There's a GTK version out now, a Qt version is in development, and you can also build Windoze apps using the same source code. It's a terrific, sensibly classed API for both C++ and Python, and it eliminates the problem of tying oneself to any particular toolkit (other than itself, of course).
(Incidentally, I'm not part of the wxWindows development team, merely an extremely happy user of the toolkit. I'm developing a fairly large program using it and it just makes development a real pleasure.)
Re:The teams themselves (Score:1)
Have you looked at all at the new signal system for Gtk-- which is in development? The system is in middle design stage and currently considered usable. If you care to have some changes in the methods of input or the API abstractions then please look it over and mail me the comments as I am the primary author of that module.
The new signal system is abstracted further from the C interface and makes all signals into Objects. This is exactly the same form as used for the same purpose (callbacks) in the STL. We are also changing the notation to match the STL in a number of places. If will be by far the most flexible callback model published to date.
Could you please give some exampes of how it should work or some examples of where this notation is bad?
As far as virtual functions, I don't understand the complaint. Gtk-- does use virtual functions for all of its signals. However, having to derive all of the widgets just to change a single behaviour is horribly wasteful. The entire point of callbacks in Qt, Fltk, WxWindows, and Gtk+ is to avoid unnecessary deriving of widgets. I do not understand how making virtual functions the only event handling would be helpful. Or am I misunderstanding your comment?
As always feel free to mail me feedback or better yet help contribute.
--Karl
-- Gtk-- contributor
Re:D'oh. Submit button next to preview button. (Score:1)
Look over this example [ucdavis.edu]. You will have to delete the space the /. keeps adding in the address. (Rob: this address is getting mangled by the length of line checker)
In here I have used derived methods to take over motion_notify, button_pressed, button_released, exposure and configure. (Basically most of the common events.)
While at the same time I have attached connections from sliders, adjustments and buttons between methods in the various widgets. Therefore, rather than deriving new buttons that would alter data in another object (very bad OO), instead the object responsible for that data just provides methods which are later connected.
I agree that the notation of Gtk-- does leave a bit to be desired, however that is where we are working to make improvements.
Hopefully this clears things up for you.
--Karl
Harmony being force to GPL. (Score:1)
From a note from RMS on the Harmony maillist.
With that the traffic on the Harmony list has nearly come to a halt. I suspect that too few developers feel the writting a GPL clone of something already free to Open Source code would be worth it. It would be very sad for a free software project to be taken out be the very person who most promotes freedom in software. Many of the coders of the original project and the revival seem to be afraid of being sued by TrollTech and not having the blanket of FSF will likely make the project suffer from lack of programmers.
Note that I am not associated with the Harmony project, but merely monitor their lists. I would hope that the discussions regarding this issue have just gone into the personal mailboxs and not died completely. I would encourage anyone who has the time to help get Harmony up to speed with Qt.
--Karl
Cool! (Score:1)
I do know that getting the first compile will likely be fun as we are using lots of Unix specific tools like awk, perl, sed, and autoconf. One person did inquired earlier and was told that the tools are available (through cyngus and some other site that I don't have bookmarked.) However, we have not as of yet heard back as to the results of his tests.
The win32 changes were not fulling incorperated into gtk+ at the time of the last release of Gtk--, so I can't be sure the graphic interface is going to compile. Hopefully, 6 months from now when Gtk+ has it next release I can be a little more possitive.
Hope it helps.
--Karl
Re:April Fools!? (Score:1)
--Karl
Re:Why wasteful? (Score:2)
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
Re:comments on this (Score:2)
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
Re: Shift-Cursor Selection (Score:2)
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.
--
Re:My thoughts (Score:1)
use ctrl-space to mark the beginning of a block of text, then move your pointer to the other end.
The text in between is automatically selected.
The unix editors are nothing like the windows editors. emacs requires about 15 hours of solid pratice before you can use it at all, really.
For vi, even longer.
There are a few graphical editors (that come with gnome or kde) that do what you want.
Goofy Metaphor of the Day! (Score:1)
"Viewing Qt with all the enthusiasm of an Indian sepoy regiment facing a fresh shipment of .303 cartridges slathered in pork grease and beef tallow,..."
Not a bad article but the author gets my award for goofiest metaphor of the day.
OK I know it's not really a metaphor but I forget the term... I'm not an English major for Pete's sake...
One error in particular (Score:1)
BTW, I also agree that the new moderation process has overall been more of a Good than a Bad Thing.
Nobody seems to care anymore (Score:1)
*sigh* looks like I won't need this today...
(setting down the fire extinguisher)
My thoughts (Score:3)
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 [xfree86.org] for the whole list.
Re:Waste of time? - Yes and No (Score:1)
Just, Linux doesn't work this way.
If you had, say 100 programmers to do such a job in 2 years, you'd certainly not split them up in two groups. BUT: In this case, you have 0 programmers at hand, and 100k potential ones. If you mobilise only a small part more of this potential by splitting the project, both projects will move on faster.
And that's exactly what happens. The kind of technical rivalry between the two group built up a fierce loyalty on both sides, resulting in more motivated contributors.
=>Gnome 1.0, KDE 1.1.1 q.e.d.
But of course there are serious drawbacks, especially when technically superior solutions are shunned because they come from the other camp (NIH syndrome). This was the case with Gnome's window manager hints (just duplicated KDE's effort, just in an incompatible and name space polluting way), and seemed to be similar in the case of the Corba object model (but they do seem to come together now).
As for your points: I don't think KDE and Gnome are so different. I don't see e.g. why "network distribution" is "incompatible" with KDE.
Don't forget KDE used CORBA first and are clearly in the lead with their object model already working in KOffice.
But as both projects seem to be willing to cooperate now, I see a bright future...
Re:Writing GNOME apps with Qt - Sure (Score:1)
On the other hand, Gnome developers are usually writing in C, and they don't care so much about gtk's lack of proper C++ support (GTK-- is very restricted in the use of C++ features).
So, my point is:
When people complain about KDE, then it's usually about QT (i.e. the license). I say that's unfounded, as you can write KDE (compliant) apps with other toolkits like tcl/tk.
As GTK is very popular, a KDE support lib would be very helpful for people disliking the Qt license.
Sure, if both environments agreed on more common standards like the XDND, this would be much easier to accomplish...
Writing KDE apps with GTK (Score:2)
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 [city.ac.uk] A Tixwish extension, Ktk offers KDE look and feel for Tcl/Tk developers, without using Qt
StarOffice 5.0 [stardivision.com], 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.
Re: (Score:1)
Re: (Score:2)
significant, meaningful differences (Score:1)
- KDE is somewhat more mature than Gnome
- GTK is based on C, Qt based on a variant of C++
- GTK has a free Windows version, Qt does not
- The Qt license is different from the GTK license
To me, those differences come down to that I will use some KDE components on my desktop for now, but for any C/C++-based GUI development, I will use GTK. But despite their utility, both environments seem fairly backwards looking: they are designed like the toolkits of the 80's.GUIs for the next millenium will make much more use of transparency, scaling, 3D, animation, multimodal input/output, browsing, and hypertext. I don't think either KDE or Gnome are in a particularly good position to play a big role in that. Java with Swing, Java2D, Java3D, and its other APIs, however, is in a much better position to become the substrate on which those future GUIs will be built.
To me, it's a shame that so much effort has been going into KDE and Qt, rather than into creating a non-proprietary Java-based desktop. But it is all volunteer work, after all, and people have to work on what they believe in.
Re:My thoughts (Score:1)
What am I gonna do until then? That sucks =(
Hey... we could use AccelX? But no, AX5 is buggy propreiety software!
AAAND my script to change to a VT from XQF to play quake2 sometimes causes AX5 to lock.
=( Oh well, at least with OSS, when it comes out, you know its not gonna be crap.
Re:Open source misconception (Score:1)
Thats a good point, I personally don't think either KDE or GNOME was that great when they came out. (GNOME 1.0 ahhaaha NO.)
Re:X as it stands HAS to go. (Score:1)
Choice is good...or is it? (Score:3)
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
Learn to write, please. (Score:1)
Sigh...
"Viewing Qt with all the enthusiasm of an Indian sepoy regiment facing a fresh shipment of
Bad. Bad. BAD.
Re:slumbering dragons (Score:1)
My petition to the developers (Score:1)
Personally I am a fan of KDE although GNOME has the best-written mission statement that I've ever read. I intend to run them both for a while.
Re:My thoughts (Score:1)
So what you end up with is a memory intensive toy.
I think I'll stay with fvwm.
Tried EMACS? (Score:1)
Kaa
Choice is good! (Score:2)
(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
Choice is good (Score:3)
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
Re:Waste of time? (Score:1)
If someone wants to code, then more power to them. Who's to judge whether or not it is "worth it?"
how does one switch between gnome and kde in RH5.9 (Score:1)
This is a bit of a newbie question
I have just installed RH5.9 and in gnome there is a way of chosing which to use but after I switched to KDE I can't work out how to get back to gnome
Somebody explain something to me... (Score:1)
Also, are there any practical limitations to making an application compliant with BOTH desktops? If not, what was the whole point of the desktop wars? Why couldn't application developers write apps that were compliant with both desktops and let the user choose one based on personal preference?
"Software is like sex- the best is for free"
Re:No, HotSpot produces faster code than C or C++ (Score:1)
please, pull up a shell and type /usr/src/linux/*/*/*.c /usr/src/linux/*/*/*.c
ls
or even better
cat
(I'm not dissing java - my experience with it is limited to a few hundred lines for web applets)
8-) andrew
Re:how does one switch between gnome and kde in RH (Score:1)
What you have is Afterstep as a window manager and the gnome panel as an application. It is true that the Kde menu can be accessed via the foot button of the Gnome panel but this doesn't mean that Kde is running, simply that the Gnome panel can interpret the Kde menu entries.
Re:Who wants a Windows disktop on a Linux machine? (Score:1)
Every once in a while, I try out KDE or GNOME to see what all the fuss is about. About ten minutes later, it's gone. Those things are for absolute beginners.
Look, neither of these things, G or K, are for you. They're part of the "world domination" perversion to attract people who are and should be using windows to use Linux instead.
Re:One error in particular (Score:1)
Unfortunately... (Score:1)
KDE is mostly C++, GNOME is mostly C.
KDE uses Qt, GNOME uses GTK.
This makes it far less fun to borrow code. And on top of that you have the license issue. KDE cannot legally reuse GPL code with Qt without the permission of the author because Qt (even with QPL) doesnt have a GPL compatible license. To solve this, KDE is slowly moving over to the Artistic License (perl (which, IIRC, is distributed under both GPL and AL)). This is not GPL compatible either, altho it is compatible with the QPL (meaning, GNOME cannot use the code without a separate license, altho they can use the GPL version of the code).
So, the idea of code reuse between KDE and GNOME has some problems. This does not prevent common standards and interoperability, of course.
Re:Sure, Qt for Free Software, gtk for Shareware (Score:1)
b) Uhm. The QPL doesnt do anything for compatibility with other OSS licenses. It gives a vague (and legally undefined) suggestion that other OSS licenses can be used with QPL, but some OSS licenses like the GPL cannot be used with QPL software.
And by the way, have you ever tried to go through the red procurement tape in a corporation?
"You want to buy what? That's not in the strategic buisness plan! From what company? They're not in our alliance vendor list! A new development environment? We dont want anymore, we've already got 30! Do you have a charge code? Who's budget is this coming from?"
In most corporations, if something costs something, you've got the choice to either pay for it out of your own pocket or go through a years worth of budgeting, politics, studies, projects, etc. That is the *real* bar for getting something costing money accepted.
Re:Untrue in a dreamworld (Score:1)
You dont call Troll Tech to get the license, you call the purchasing department, who need a decision that it is an official product that your company uses, which can only be obtained through an evaluation project approved by a steering comittee, etc etc.
If you really believe they'll give you the company credit card and that you as a developer can order what you want to do a project, that's not the way it happens. With (L)GPL software you can usually wing it; you dont have to bother going through the red tape, because you only have to do that if you buy something.
Re:My thoughts (Score:1)
"Single modular X server with loadable drivers, server extensions and font rasterisers. The modules will be OS-independent, and the loader design is that donated to XFree86 by Metro Link. We plan to fully document the driver API/ABI to help make it easy for third parties to supply XFree86-compatible driver modules."
I dont know if I understand this correctly. Right now XFree86 requires a Whole server for each video card right? The new Xfree86 will alow driver modules. Is this closer to the way Winblows uses video drivers?
Standard Interface - That's Why (Score:2)
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.
Waste of time? (Score:2)
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...
Re:Try NEdit (Score:1)
http://fnpspa.fnal.gov/nirvana/nedit.html
Re:There can be only ONE! (Microsoft/Highlander... (Score:1)
You can find DFM at:
http://www-c.informatik. uni-hannover.de/~kaiser/dfm/dfm.html [uni-hannover.de]
Choose One (Score:1)
In the end you will have two toolkits that differ chiefly in name only.
Re:Develop with wxWindows, run everywhere (Score:1)
Joao
Re:Goofy Metaphor of the Day! (Score:1)
Duplication comes naturally... (Score:1)
Choice without cooperation can be dangerous (Score:1)
It is critically important that the developers of GNOME, KDE and another X environment agree on a common set of rules such that all applications can be run on any platform. Without such cooperation, one killer app could make a given desktop the defacto standard and threaten the choice, innovation and new ideas that have drawn us to Linux in the first place.
Choice without cooperation can be dangerous (Score:1)
It is critically important that the developers of GNOME, KDE and another X environment agree on a common set of rules such that all applications can be run on any platform. Without such cooperation, one killer app could make a given desktop the defacto standard and threaten the choice, innovation and new ideas that have drawn us to Linux in the first place.
Choice without cooperation can be dangerous (Score:1)
It is critically important that the developers of GNOME, KDE and other X environments agree on a common set of rules such that all applications can be run on any platform. Without such cooperation, one killer app could make a given desktop the defacto standard and threaten the choice, innovation and new ideas that have drawn us to Linux in the first place.
Uhm, people seem to be doing it... (Score:1)
slumbering dragons (Score:2)
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.