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.

Comments

screwed up naming conventions?

[grammar nazi]

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?

Reverse forking?! :)

[MikeFM]

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. :)

Common Platform whish list

[bockman]

from the hope-costs-nothing dept.

MIME types

User Personal Menus [at least]

Window Manager Hints

CORBA [if any, it should be common]

Drag'n'drop

Components model

Rivyn does not speak for KDE

[Andrew Cady]

Daniel M. Duley posted this message to linuxtoday.com:

Since none of the KDE core developers have been contacted, I am sorry to say I think Rivyn jumped the gun here. While Miguel may have talked to Rikkus - he's not a primary KParts developer. As a matter of fact, as far as I can tell no KParts developer or maintainer was spoken to at all. Thus this is misleading at best. Not that it wouldn't be good to interoperate, but no KDE core developer or KParts developer has been contacted so don't get too excited. A lot of KDE developers have serious issues with Bonobo such as overhead, and nothing has been discussed at all with them.

Sorry guys, assuming Mr. Duley isn't a fraud (and there's no reason to believe he is), this looks like vapor.

Duley doesn't know everything

[Ur@eus]

Rivyn has talked with a lot of KDE and GNOME developers about this, with mostly postive reactions. Duley is an ardent GNOME hater so I think that is why he downplays this so much.

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.

Why not include COM as well?

[Alien Conspiracy]

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...

This reminds me...

[DevTopics]

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.