KDE And GNOME To Share Component Architectures? 168
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.
Good Thing(tm) (Score:3)
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!
Kde/Gnome Interface Common Interface (Score:1)
screwed up naming conventions? (Score:4)
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?! :) (Score:5)
This is going to screw Debian, isn't it? (Score:2)
Just The Facts, Ma'am (Score:2)
Here's to burying the hatchet:
- Bonobo [helixcode.com]: the GNOME architecture for creating reusable software components and compound documents
- KDE 2 [clara.net]: An intro to the parts of KDE II like KParts and XMLGUI
- Supporters [derkarl.org] of the KParts/Bonobo merger
Most people I've spoken to are against Linux kernel/OS fragmentation, so what could be good about GUI fragmentation? I know KDE and Gnome are generally looked upon as mutually exclusive religions, but it *would* be nice to have the two work together.Just my $0.02...
--
Congratulations (Score:1)
would be nice, but ... (Score:1)
Speed Issues. (Score:2)
Also i seem to recall reading at one point that KParts was going be extensible to enable it to use CORBA objects if the lightwight KPart was not available. How much of a shift is this for KDE? it would seem that such compatability was always on the cards.
IMHO the interesting part for is the compatability that will come from having KParts accessable from Gnome which is something new.
Good work guys! here's to an truly open and portable component model.
Sahred components (Score:1)
Re:This is going to screw Debian, isn't it? (Score:3)
Re:This is going to screw Debian, isn't it? (Score:1)
Of course if they do manage to merge GPL & QTL code sucesfully, i guess the Debian problem will be solved at the same time.
No problems whatsoever (Score:1)
Common Platform whish list (Score:4)
MIME types
User Personal Menus [at least]
Window Manager Hints
CORBA [if any, it should be common]
Drag'n'drop
Components model
Not fake, just different views (Score:1)
Re:Common Platform whish list (Score:1)
You know, i think that's what the C in CORBA is for. Common Object Request Broker Architecture.
Must be the coldest day in h$ (Score:2)
0.Gnome and KDE apps that work together well.
1.Gnome and KDE ppl sharing resources.
2.Goodbye QPL and Qt!
3.Debian ppl will stop whining;)
4.Debian will finally include KDE.
All very Good Things(tm).
Off hand I can't see a downside, other than fixing a lot of code.
Never, ever thought I'd see the day when they were even talking about doing this. This is the happiest day since Baseball went on strike...
Rivyn does not speak for KDE (Score:5)
Re:This is going to screw Debian, isn't it? (Score:1)
your point was valid, you just sound like a fool.
Re:Must be the coldest day in h$ (Score:1)
Just In Time (Score:1)
Suppose we had a ftp-client component. Now you make a html editor and you want add remote file
editing capablilities. Currently, you would have
to re-invent the wheel, but if we had a ftp component, we just reuse it instead. Ofcourse,
ftplib exists (which actually qualifies as a component), so this isn't a good example. But having a good component model would make creating and using components easier.
Ofcourse, it requires some change in attitude. Currently re-invent the wheel seems to be the driving force (anyone counted the amount of irc/mail/news/icq -clients?).
gome-kde mailinglist (Score:2)
One of the main problems are the great architectural differences between kparts and bobobo.
If anyone interested, I am sure there is a archive of this mailinglist around somewhere on http://www.gnome.org/
--
Samba Information HQ
Re:Must be the coldest day in h$ (Score:1)
It's like in that movie... (Score:1)
(picture Miguel and Rikkus walking off together from a misty dock)
Re:Good Thing(tm) (Score:1)
Duley doesn't know everything (Score:5)
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.
Clearing some confusion (Score:3)
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.
This is the best thing (Score:1)
If MS can be given any credit for innovating it should go to their component architecture. Yes, I realise they didn't invent components but they were the first ones to push them on a system wide scale. This allowed them to reach new levels of software reusability. Well designed components are like plugins, if the interfaces are well thought out the benefits are far greater than the costs.
I'm not sure how much change will be required in both projects to support the new component architecture and how well the teams can cooperate to design this new component model. The main risk here being a slowdown in progress due to the design by commmittee effect kicking in. But all going well we just may have a grand unified component architecture for *nix, thanks to GNOME and KDE... Off to celebrate, bye!
Re:This is going to screw Debian, isn't it? (Score:1)
Though I agree that a common object model would be A Good Thing (tm), it's questionable how this will be best achieved:
CORBA does indeed include a lot of unnecessary overhead for local applications, and general interoperability is currently hampered by Orbit's non-standard authentification mechanism...
Re:This is going to screw Debian, isn't it? (Score:1)
QTL is the Qt Template Library, a set of cross-platform template classes used instead of the STL.
You propably mean the QPL, but that license only applies to Qt, not to KDE.
KDE is GPLed for the most part, except the libraries which are LGPL, and some applications that come under different (Artistic,
Re:Clearing some confusion (Score:1)
See, i'm still not too sure about this. The component architecture that is finally settled on is going to be realised under a licsense of some sort. You can bet your bottom dollar that the Gnome team will want to use GPL.
How will the GPL component code fit into the KDE code? Will there be any parts of KDE where the QTL and the GPL will overlap and/or conflict? Maybe this isn't an issue, and i've missed the point entirly (Has been known to happen once you know
unix (Score:3)
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.
Re:Common Platform whish list (Score:1)
window manager hints are done (NETWM)
drag'n'drop is done (XDnd)
desktop files (MIME types and menus) are done (the ".desktop" standard)
Re:This is going to screw Debian, isn't it? (Score:1)
If what you say is the case, fine. I'm all for it.
BTW, swearing wasn't needed, it makes your post look like a flame, and you don't wanna start a flame war.
Re:Clearing some confusion (Score:1)
QTL != QPL && !KDE.coveredBy (QPL)
Re:This is going to screw Debian, isn't it? (Score:1)
(Neither is a post further down, where I again explain the difference, only in "formal" notation
MIME types are not done (Score:1)
I'm having goosebumps (Score:1)
Why not include COM as well? (Score:4)
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... (Score:4)
Re:Rivyn does not speak for KDE (Score:1)
Vapor or not, the cat is out the bag, and we have the oppertunity to stand up and say - yes, this is a good thing, we want this to happen!
I've been saying this, or something like it should happen in KDE and GNOME stories for ages, and very little comes of it, it brings a smile to my face that the idea, from me or not, is now getting prime time coverage.
Thad
Too bad (Score:2)
I do not believe it's not possible to sit for a week and make common object architecture. It needs not to be fastest, smallest, leanest one in the world. It just needs to work and be common, so that I could call Konqueror from gnumeric and vice versa. Microsoft has COM, and with all it problems, people use it, and do it a lot. Common component sharing arcitecture is a very important thing. That's like common binary file format - imagine two distributions have different binary file formats - at the end nobody is going to use any of them for serious work.
GNODE? KDOME? (Score:2)
Vik
COM is not as open as CORBA (Score:1)
Orbit's authentication mechanism (your are wrong) (Score:2)
Re:Clearing some confusion (Score:1)
And there won't be any problem, since because it will be toolkit agnostic, it won't need to link to neither gtk nor qt
CORBA ORBs and standards (Score:2)
Nice idea, great standard and all that, but does anyone know of a decent ORB that handles all of the 13 CORBA services well? The main ORB I've used is Orbix, and that only supports 4 out of the 13 standards as of version 2.3, which quite frankly sucks and makes using it a real pain in the arse (along with a lovely bug where two servers end up with the same ID, causing them to crash).
As for performace, sure you take a hit, but I'd say that the benefits using a unified model for local and remote connectivity outweighs the penalties - after all having different standards in different parts of the system introduces bloat elsewhere anyway. And writing code for such a model is a lot easier...
---
Jon E. Erikson
Re:Orbit's authentication mechanism (your are wron (Score:1)
One nitpick, though: why not use ? [slashdot.org]
Good news (Score:1)
unforkingbelievable! (Score:1)
Re:Orbit's authentication mechanism (your are wron (Score:1)
Uh, I just noticed:
You propably meant this Mail [gnome.org] by Stefan Westerfeld, didn't you?
NO. (Score:1)
Re:Good Thing(tm) (Score:1)
No, and that's not what this is about. The point of the common model is that with it, KDE and Gnome applications can interoperate, i.e. you could use drag&drop between them. That's a Good Thing. The point is not to turn them into one big project. For example, the preferences of both will probably remain separate.
Please do it! (Score:3)
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.
Linuxtag in Stuttgart - 9 days (Score:3)
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
No, but here is the correct URL (Score:1)
http://mail.gnome.org/pipermail/gnome-kde-list/19
THIS IS WHAT OPEN SOURCE CAN DO (Score:2)
I can't ever imagine Micro$oft and Macintosh getting together to create a solution that facilitates the greater interopability of their two operating systems (I know this example is lacking in technical merrit as they are both completely different architectures and KDE + GNOME are not operating systems, but you know what I mean
Re:This is going to screw Debian, isn't it? (Score:1)
-------------------------------------------------
Re:This is going to screw Debian, isn't it? (Score:1)
-------------------------------------------------
Re:CORBA ORBs and standards (Score:1)
Here's the URL:
http://www.cs.wustl.edu/~schmidt/TAO.html [wustl.edu]
Unix Component Model (Score:2)
COM, CORBA and EJBs are not soley pitched at GUI apps, so it's a bit irresponsible to design a component model which will only function with two graphical environments.
Also, what shouldn't be happening is that KDE just adopts BONOBO wholesale - simply because the KDE team have already dropped CORBA from KParts. Both projects (and other interested parties) should work towards a scaleable, lightweight manageable and truly independent framework.
Having said that, this is a step in the right direction.
-------------------------------------------------
Re:Rivyn does not speak for KDE (Score:1)
can a developer of either project tell me if the effort involved in ensuring gnome/kde interoperability at the component level is worth the efficiency gain of being able to leverage the existing components of both projects?
there is nothing worse than writing a chunk of code only to find that someone somewhere has already churned out exactly what you were already looking for..... ;-)
in any case, kudos to all kde/gnome developers.... you are doing an amazing job....
d_i_r_t_y
This is unlikely (Score:1)
1. the difference in licence between KDE and Gnome
2. the state of the "market" (I am convinced that the freer Gnome would get an overall boost over the less free KDE if the plan/rumour would become reality)
make me doubt the good intentions. Although I am slightly in favour of KDE because of practical reasons, I would love it if the freer Gnome took the lead.
John C. Drashcan
Re:screwed up naming conventions? (Score:1)
How do you think Bonobo fails on those criteria (Score:1)
Gnome Versus KDE Apps. (Score:1)
Re:This is unlikely (Score:2)
As for who would benefit the most, I think it is academic, the real winner would be the users and linux in general. If this thing works out choosing desktop environment would be very much like choosing a window-manger.
Famous? (Score:1)
Gaelen
Re:Sahred components (Score:1)
The best solution (Score:1)
Interoperability is a good thing.
However, this does not mean that Gnome and KDE should merge into one codebase. In fact the interoperabiliy is the best solution all round. The Gnome and KDE factions could still argue who's is best but it wouldn't really matter.
This interoperability is what Linux needs if it is to make any headway in the desktop stakes.
Please excuse my shouting :-)
Re:Please do it! (Score:1)
It's educative for the developers which want to learn about a new field;
It's more fun that studying other people code;[ and many still do open-source coding for fun], especially if said code has little or no ducumentation.
On the long run, it generates fresh ideas that might prove useful ( think of the Berlin project ).
Moreover, some time two different groups of developers are different in too many ways to work toghether.
Re:Just repeating what's in the article, karma who (Score:1)
--
Still too many COM-like component architecture? (Score:1)
But am I mistaking or Mozilla has its own component architecture?
And in linuxtoday Frederik C. talks about another component architecture tailored for high performances:
> Check out this link for an explanation form the
> developer of aRts/MCOP:
>
> http://space.twc.de/~stefan/kde/arts-mcop-doc/why
Would it be possible to have only ONE component architecture ?
I Have Another Idea About A Thing Called A Wheel (Score:1)
It makes things go faster.
Its the coolest thing since sliced bread!
What?
Someone already invented the wheel?
But my wheel is better!!
Yeah I know I know its just a wheel.
Can you say OLE? Can you say COM?
Components != GUI (Score:3)
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.
Re:It's like in that movie... (Score:1)
And you owe it all to trolls! (Score:1)
Re:screwed up naming conventions? (Score:3)
That's easy. Split the difference -- halfway between 'g' and 'k' is 'i'. Ergo it would be the iNapster. Available in five fruity colorschemes.
--G
Killer reply to "Linux fork" argument (Score:3)
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.
Overlap creates more choices (Score:2)
Yay! We rule! (Score:1)
Hee hee, now we can claim to be "trolling for Linux" and take the moral high ground when people start moaning at us... Finally, someobdy actually listens and learns from a troll :)
Re:This is going to screw Debian, isn't it? (Score:1)
Here's an article [derkarl.org] you might want to check out.
It's about using Bonobo in KDE, or at least merging Bonobo and Kparts.
See? No mention of GNOME using Kparts. It would never happen because Kparts depends on QT. But, Bonobo is toolkit independent.Re:THIS IS WHAT OPEN SOURCE CAN DO (Score:2)
Also your analogy lacks merit, let's try this one. Wouldn't it be cool if some people created a cool technological solution that allowed various seperate apps to talk to each other (e.g. spreadsheet, wordprocessor) seamlessly as well as expanded the infrastructure to include third party software and then created a distributed version of this? Guess what, MSFT did.
I hope that puts things in perspective. I'm not an MSFT supporter (even though quite a few of my friends work there) but when people ignore their achievements then praise people for ripping off those same achievements it makes me wonder. After all we were all up in arms when they claimed they invented symbollic links
PS: This is not a troll if you disagree with me post a response.
Troll Time (Score:2)
RMS specifically ordered that the wheel should not be allowed in Linux.
See man su for details.
That remark is as stupid as the discussion itself (Score:2)
It's very funny seeing the die-hard anti-MS people twisting and turning to avoid having to say 'Implement it as COM!'. COM not a bad protocol, people, in fact it's quite clever. And besides that: there are a LOT of com objects around the world, and a LOT of COM developers around the world.
For Free, Mike!
--
Re:screwed up naming conventions? (Score:2)
Actually, you could try to split the difference phonetically. /g/ is a voiced velar stop while /k/ is an unvoiced velar stop. Hmm...could be tough. On the other hand, in honor of the friction that exists between the partisans of the two projects, I'd vote for a velar fricative. And we might as well go voiceless, since that's already a German phoneme. And we could spell it as X as in TeX.
Xnapster: the sounds of a Xnew generation.
CORBA predates DCOM, doesn't it? (n/t) (Score:2)
Server Component Architecture (Score:2)
Firstly, I hope this (merger between BONOBO & KParts) takes place. Even if this annoucement was somewhat premature, I hope it becomes a self fufilling prophecy.
That's not really what I wanted to discuss, though. Please excuse me if this is a little off-topic.
What component archictectures are sutible for use in server side (ie, website) development on Linux/Unix? Is the only option Enterprise Java Beans?
I'm not saying there is anything wrong with EJBs, but I think there is room for a proper language independant component architecture suitable for server development on Unix. As far as I know, there is nothign directly comparable to COM+ (or COM/MTS) on Windows, apart from EJB. I don't think either BONOBO or KParts fills this gap, either.
I suppose CORBA support is a good start, but there is more to a component architecture than a remote object calling standard. COM+ supplies database connection pooling, object pooling and some failover features, all of which need to be added by developers or non-standard vendor tools to any CORBA based solution.
I'm not too optimistic about this changing, though. Or am I wrong, and there are projects already underway?
Re:Too bad indeed (Score:2)
Its sad though if Microsoft (like we have anyone else to worry about??) doesn't even have to do the dividing.. we end up doing it ourselves.
It was nice to see KDE and GNOME in their race for GUI supremacy... it might have even helped speed things along on both of their accounts. But how long can linux wait for its URGENT NEED for a user-friendly interface and GUI developers heaven?
We need to get things together NOW. And if alot of these duplicate open source projects out there could simply put aside their egos, congratulate each other on a job well done on each of their seperate projects, and simply realize that 2 heads are better then one.. then they can focus their efforts together in a mutually beneficial merger of their projects... we'd see ALOT more development get done.
Can we all agree we want one thing? We want to live in an age where "software doesn't suck". It'll happen, we know it will. But would you rather see that age come now or when your 65 and can't type as fast as you use to?
Ok, put it this way... Motorway traffic problems are VERY frustrating to the typical commuter that has to drive to work every day. Its annoying to see all the stupid things that happen on the road simply trying to get from point A to point B. And also, People who compute for a living, or for pleasure, or both... are we not also frustrated by the stupid things today in computers? Having to use software we HATE, watching our computers reboot daily when in reality, mankind could do better...
Linux NEEDS to be userfriendly, and developer friendly. We wonder why Linux doesn't have the apps or games to bring it to the masses, its because the very SUPPORTERS of Linux aren't awake enough to see what they really have to do to SUPPORT IT. You need to work together. Compete with each other later, especially if your young, you have time. But for now, can't we just work together to make our share of the pie larger, for each other? Why so little work on the Linux Standards? Why so many damn browsers? Can't we just agree Mozilla is the best thing we have going, and rather then starting up your own little browser project.. you really should help push something that is almost at the finish line rather then starting from the beginning on your own?
Ok, I've ranted enough. I hope I moved some developers in the right direction.. would be sad to see the Linux community to continue to be the reason for its own stagnation in gaining mass acceptance.. which is what we really need.
-Matthew Cortes
Technetos, Inc.
Re:That remark is as stupid as the discussion itse (Score:2)
The last thing is certainly true. And it does seem like every major open/free software project has now had a go at (re-)implementing or (re-)inventing either CORBA or COM. Can anybody with real knowledge and experience out there compare and contrast the ups and downs of the KDE, Gnome, Microsoft, and Mozilla (XPCOM) approaches?
And, no, this isn't a troll. I have no idea what such a comparison would conclude and no vested interest in a particular answer, but a lot of interest in seeing the amount of duplicated effort in the world go down some.
Re:Please do it! (Score:2)
DCOM Sucks Rocks! (Score:2)
That 'most cases' (emphasis added by me) is the telling bit. When DCOM faile, it can fail spectacularly. I've been working with it quite a bit lately, and it seems like anything dealing with late bindning or mixing you environments is just asking for trouble. Ever try to get a VB app to talk to a multi-threaded C++ ActiveX component? Here there be dragons! And don't even get me started about interfacing DCOM to non Windows systems. Things just seem to work more consistently in the CORBA world.
Just my $.02.
Thad
This is good... (Score:2)
However their is another reason that this is good. It means that efforts will not have to be duplicated across the board anymore. While it is still possible and probable, it will make more apps for a linux desktop. Those who want to run kde can still run kde and those who want to run gnome can still do that (personally I use windomaker with gnome panel and kfm).
The only issue that I see arrising is that this may mean that in order to use this functionality that you must have qt installed along with the kde base, libs and sup, and some other parts opf kde as wel as gnome core and gnome libs. It they can make an independant common set of libs that depend neither on kde nor gnome it will work. This is not much of an issue as most people will be willing to install both sets of libs if need be. However this would be problems with distros like debian. Also how would the license for these libs read? If it uses gnome which is gpl would this become a gpl library or qpl? I know that this is in the early stages, but with the recent incident with debian this should be something that the developers need to think about. How can they do this and keep their seperate license in tact?
It will certainly be interesting to see this acomplished.
Shut up or I'll replace you with a very small script!
send flames > /dev/null
Re:That remark is as stupid as the discussion itse (Score:2)
Re:Common Platform whish list (Score:2)
Re:unix (Score:2)
This is only aspect of your post which I don't consider a flame, so it's all I'm going to respond to.
An app that does not have a GUI communicates with the user and/or other apps via standard input and output. A GUI app as a general rule does not. I THINK what you are saying is that there's no reason that all GUI apps can't have TTY modes of operation to supplement their usual GUI mode, but that's only reasonable if the information they are outputting is readily trasformable into unstructured ASCII text.
Dimensionality is the key. streams/pipes are flat data, linear in nature, as are TTYs, and the unix CLI approach of composing utilities. "cat | grep | sort | uniq | wc" - it's linear, they communicated with an unstructured stream of ASCII text, parsed and formatted for each |.
This linearity is not absolutely inherently tied to the CLI, it just suddenly gets hard to represent more sophisticated relationships componentisation may allow. A good component architecture is also necessary for passing large quantities of structured data - where parsing ASCII would become a lot of work. Examples of where this is useful abound in the GUI world - widgets, movie player codecs, image readers, browser windows, et cetera. COM allowed Windows to easily make the File->Open dialog just another explorer window, and god is that handy...
Sure, all these apps could output XML or something to stdout, and parse XML on stdin, but
Nobody was "speaking" for anybody (Score:2)
Niether my submission, CmdrTaco's comment, or Rivyn's pages say this is going to happen. It consists mainly of speculation and ideas at this point. Why the hell are we trying to kill it before it is even born?
Did it ever occur to anybody that, even if this hasn't been coded, tested, and approved by everyone from the Pope to the Bob the Lawmower Man, it might be a good idea? That maybe it is worth looking into?
Simply considering an idea doesn't mean that KDE is going to have to adopt CORBA for IPC or that GNOME is going to switch to Qt or that Bill Gates is buying Linux.
I submitted this to Slashdot in the hopes that a good discussion on the technical challenges involved might happen. I didn't expect a political cat-fight.
Geez people. This kind of attitude reminds me of the proprietary Unix vendor wars of the 1980s. Keep this up, and Microsoft won't need a monopoly to dominate.
What's What (Score:2)
What you say is correct. However, what you say doesn't necessarily apply.
GNOME uses CORBA for IPC. Bonobo is a set of CORBA interfaces designed to enable component reuse. Bonobo is also an implementation of those interfaces for GTK.
KDE uses DCOP for IPC. DCOP is a layer on top of X11 ICE. In concept, DCOP is a lot like CORBA, but with all the things KDE doesn't need striped out to improve performance. KParts is another layer on top of DCOP designed to enable component reuse. KParts is tied to Qt, not so much in terms of the GUI (although that does come into things), but because KParts uses Qt's "signals and slots" mechanism for function callbacks.
The practical upshot of all this is that the IPC mechanisms and some of the component architecture is very GUI independent for both KDE and GNOME, but they didn't go to extremes trying to keep their GUI from being tied to their GUI. Which is reasonable.
(Note: This is an executive summary, and as such, may not be completely accurate. What do you want in three paragraphs?)
Re:Killer reply to "Linux fork" argument (Score:2)
Paul.
I didn't say anybody was (Score:2)
I never said this isn't going to happen, even though I think it's realistic to presume it isn't (as they say, "where's the code?"), at least until the KParts and KDE-core teams have agreed to at least look into it. I know that KDE has looked at CORBA before and decided against it -- when I saw this, I thought that they had changed their minds. In reality, they haven't, and that fact should be recognized. We don't accept such early announcements from corporations, let alone from individual developers working for corporations who are not official spokespersons. There's no reason to accept this early announcement either.
That said, I certainly hope this happens, and I'm not saying it shouldn't or that it couldn't. I'm not "trying to kill it" and I don't think anybody else is either. Just trying to sort out the real facts and possibilities, and to avoid unrealistic expectations.