Gnome & KDE and all that jazz!

Some reasons why the can't merge:
1. They use different languages:
GNOME is written in C (GTK) and KDE is in C++ (Qt)
2. They have different goals:
GNOME is an environment built on customization; They were the ones with the "theme" idea, and there are a good deal of apps based on its toolkit, but loosely affiliated with the project.
KDE is a desktop environment. Their apps, like KDevelop and KOffice, are fundamental to Linux. Their window manager, however, is not the best, and I find the desktop to not be as visually appealing as a well-tuned GNOME desktop (esp. the Panels). KDE looks, and behaves, much more like Windows.
3. There's no need.
I install the Qt libraries and the KDE apps, and the run the GNOME desktop. This gives me the flexibility of GNOME and the great KDE apps.
4. What X is
X consists of 2 parts, the client and the server. When you type stuff in a GUI, that goes directly to X, which then handles the input. X draws stuff on the screen. X then uses a window manager to mange windows (duh). All of these parts are important for a GUI. The reason X is so heavy is 'cuz it does EVERYTHING Above Kernel Layer and Below Window Manager. That's a lot of stuff.
5. Why are things so monolithic?
Monolithic kernel, Monolithic Desktops.  
Seriously, though, most buinesses dont even USE a GUI. They use Linux as a server. The few buisnesses that do use Desktop Linux use KDE because it is like Windows.
Most enthusiasts use GNOME (no flames), because it is so customizable, and because you get the great stuff Ximian has. And that monkey is so |337  

"If you teach a child to read, then he or her will be able to pass a literacy test" - George W.

C++ and C aren't so different... but it's easier to think of KDE and GNOME as toolkits (or even dll's for simple apps) to make developing apps faster and easier. I don't really see why you want to merge them. Are you looking for an MFC sort of thing for Linux? With the One True Path for coding Linux apps, and Delphi/Kylix etc on the side? I think I'm missing your point.

Re the X thing. I believe that there is a framebuffer driver for X, but it's dog slow compared to the accelerated drivers. From my perspective, X is anything but monolithic. There are so many drivers and libraries it scares me!

"C++ and C aren't so different"

In theory, true, and in basic programming, truer. But when you get into real programs, they differe greatly. C retains very archiac, powerful stuff, like malloc, etc. While C++ has classes and its OO style is totally different from C.

Since both toolkits are complex programs, it would take an incredible amount of work to convert Gtk-- to C++. There are apps that allow you to use C++ with GTK, however.

And for the MFC stuff, apparently the CORBA system is much better?

"If you teach a child to read, then he or her will be able to pass a literacy test" - George W.

Actually, since C++ is a superset of C, it can do everything C can. Don't even go into MFC, it is so much pain, banging your head against a brick wall actually relieves the headache! It is extremely easy to do simple things with MFC, but overly complicated to do complex tasks. For, non-graphical apps, I prefer STL to MFC anyday.

I really don't mind there being two different desktops or even hundreds of them. As long as people didn't have to develop "for" them. I don't care what they do in the cosmetic level, but I would prefer them to have a lower level abstract commonality. Perhaps a bit like (This really hurts) Microsofts COM. I know Corba does similar things, but I've never used that, so I don't know. Perhaps a common core with abstract classes, where Qt and Gtk implement them differently. For example you use the common asbtract classes to say, I want to make a TypeX window. Gnome will look at Gtk, and say ahha, This is how I make TypeX windows, while KDE will look at Qt to make its window. No matter what arguments come from either camp, it sounds verymuch like they share the same goal. They wanna go about different ways to achieve them, and add different things. But because of the long time "rivallary" neither camp will agree with each other nor admit their doing the same thing. Whenever I see a KDE-Gnome argument, its a political one, not technical as it should be.

Perhaps "merging them" is a bit extreme, but I think they should at least have common abstract libraries. I'm not looking for "one true path", but a path that makes sense. To me it doesn't make sense to make different "versions" of the same thing for the same platform. Seeing that Gnome does pretty well to handle the Qt Library, if I were to go into developing linux apps, I would choose the Qt library.

I still do think X is largly monolithic, because the drivers and so don't slot in but go around it quite like Microsoft Windows. DirectX is about the best thing Microsoft has done since Dos. I know ms windows doesn't use direct hardware access for doing the windowing, but I think X should be able to. With all the graphics cards out there, a proper framebuffer with direct hw access used for windowing should make a lean desktop environment. If it wasn't so monollithic (the graphics part, anyway), you could something like pull out all the graphics code and stick in nVidias drivers, so the windows are drawn directly on the hardware by the hardware. This is a very crude model, even naive considering I've hardly ever done any Linux development but I don't see why it shouldn't work.



<font color=red><i>I refugee from Guatanamo Bay,
dance around the border like I'm Cassius Clay
</i></font color=red>