Slashdot Mirror
KDE And GNOME To Share Component Architectures?
DragonHawk writes: "Miguel of GNOME fame and Rikkus of KDE/KParts fame have been talking about collaborating to build a common object component architecture for use in both KDE and GNOME. This would let developers and users alike share components from both projects, which would just rock."
There's a lot to this one, and largely it's technical stuff, but it is definitely interesting.
This is a Good Thing(tm). If you look at the open source projects around, you see that a whole lot of projects all overlap. You've got gnome, kde, and a bunch of other desktopmanagers. Ofcourse, it's a good thing that there is a lot of choice, but wouldn't it be smarter to put all those devellopers on 1 large project?
I think that this idea of creating a common model that both the projects can use is a very good idea. Look at Micros~1 COM (Component Object Model) for instance. You may not like this MS specific object model, but it works very well. You write a library once, and lots and lots of applications can use it instantly.
I think that cooperation of Open Source projects will be the most important thing in projectmanagement the next couple of years. Instead of living on a island, devellopers cooperate and create software that is completely interexchangable.
Good move guys!
--
If code was hard to write, it should be hard to read
What will things be kalled now?
e.g.Knapster or Gnapster
Doesn't anyone know that you kan't kombine two products that both add/change the first letter in their gnaming konvention?
Keeping
I always figured KDE and Gnome would over time merge and then each become more like a differently oriented distribution of the same code tree. While this isn't quite that far yet it is a good proof as to why opensource is better than commercial. Here's forking for ya baby, in reverse.. you fork and we merge. :) These guys rock. I love KDE and Gnome both and in fact use both on a daily basis. :)
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
What the hell are you talking about? They're not merging, they're just going to use the same componant architecture. Actually, KDE is taking the componant architecture from GNOME (and not the other way around), so there's absolutely no way there could be a licensing problem for GNOME. They're not talking about GNOME using QT, and QT is where the license problems exist. They're *certainly* not merging into one project.
MIME types
User Personal Menus [at least]
Window Manager Hints
CORBA [if any, it should be common]
Drag'n'drop
Components model
Ciao
----
FB
That said, the contact is at a very preliminary stage so it is correct to say that things are more at like the start of a new mid-east process than very close to a solution.
What Rivyn is trying to do though is gather user support behind those developers on both sides that have a positive attitude towards the issue, in order to keep things moving.
In short, the best example (which is in the article), is being able to use the konqueror html display engine in nautilus -or any other gnome app for that matter- such is the beauty of components programming.
The elegance and power of the unix command line is due the fact that a whole bunch of tools all communicate with each other in a fairly standard way - the interchange of flat text through standard in/out. This is what gives me the ability that lets me find out how many different IPs visited my web server in August without (somebody) writing a utility specificially for that purpose.
With GUI stuff, flat text is no longer what programmes are taking in or putting out. Composing capabilities of multiple X programmes is difficult. The answer to this, IMO is a broadly used and supported componentisation. If the two most popular environments COULD agree on a sufficiently rich component object model, we might start to finally see GUI programmes not merely co-existing, but actually using and communicating with each other, giving REAL flexability and power.
I think that would be kind of cool.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
So, why not create a three-way bridge which includes the WINE COM subsystem as well?
Just think of all the thousands of COM components out there which would then be available to both GNOME and KDE environments too.
For instance, kfm would then be able to display MS Office documents if you had Office installed using WINE etc...
of StarOffice - once upon a time someone spread the rumour that there will be StarOffice for Linux - and everybody kept on asking: "When will StarOffice for Linux ship?". Actually, there was no plan to port it to Linux. But so many people asked for it that the rumour became a selff-fullfilling prophesy (sort of). So, maybe, we should keep on asking the KDE and the GNOME teams: "When will you finish the merge of your components?". Even if they don't plan to do so for now, keep on asking, and in a short while they will do it. It will "scratch an itch". It will make the people doing it famous. And after they started it, everybody should write to the developers and tell them how much this was appreciated... Maybe that is just a dream, but I think that it would work. To cite Fogel (Open Source Development with CVS): "The sheer pleasure of working in partnership with a group of commited developers is a strong motivation in itself". Yep. And if done right, the component model won't touch the QT libs, so there is no need to worry about licenses.
You found a sword: +4 damage, +5 moderator points
This is of the utmost importance for the acceptance of Linux. There is far too much fragmentation in user space. It's just silly.
I looked around last week for a widely accepted C++ framework for use on Linux. It's ridiculous, about 20 different (equally attractive) options.
Choice is of course good. But the first thing people should do before writing some code is:
a. Has it been done already.
b. Has anything like it been done that I can tweak
This is the only advantage Windoze now has over Linux. It's easy to get MFC/VB/ATL developers as that's really the only options in the windoze space.
In summary people need to stop going off writing stuff for their own glory, and think of the general benefit/detriment to the Linux community as a whole.
In 9 days there is the Linuxtag meeting in
Stuttgart, Germany. A lot of key KDE people
will be there as well as quite some Gnomes.
Unfortunately Miguel will not attend (his
leture will be held by someone else according
to the Linuxtag schedule), but perhaps we
will see a BOG session addressing that topic.
I for my part would very much like to see such
a merger. This is a really exciting idea, if
it can be made to work technically and politically.
© Copyright 2000 Kristian Köhntopp
The ability for objects in different binaries to interact is not and should not be the responsibility of a GUI Yes, this ability is used by a modern GUI to glue together visual components, but it should a general mechanism that can be put to other uses.
Neither COM or Corba require a GUI.
So unless the core services of KParts and Bonobo can run on a command line (does Corba = "core services of Bonobo"?), both are badly designed. If they can run on thier own without thier favorite GUI, they can be used as a general mechanism for object interaction.
My Karma: ran over your Dogma
StrawberryFrog
At present KDE and Gnome are the classic fork nightmare situation: two incompatible worlds which cannot interoperate. If the developers can bring good interoperation then the rift will be healed. This will demonstrate that the forces for convergence in free software outweigh the forces for divergence, unlike in commercial software, and hence present yet another good reason for using free software.
In addition, both Gnome and KDE components exhibit network value effects. By Metcalfe's Law, dividing a network in two halves its value. So (assuming that Gnome and KDE have roughly equal value), allowing them to interoperate will double the combined value.
Paul.
You are lost in a twisty maze of little standards, all different.