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.
But surely, if GNOME merges with KDE, then it also merges with all of KDE's licensing problems, and Debian won't be able to use it. That leaves the only 100% Stallman-pure Free Distribution without a GUI. For some reason, I think that would suck.
-- the most controversial site on the Web
Here's to burying the hatchet:
- Bonobo: the GNOME architecture for creating reusable software components and compound documents
- KDE 2: An intro to the parts of KDE II like KParts and XMLGUI
- Supporters 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...
--
IIRC KParts was started to avoid the overhead of a CORBA architecture (such as the one Bonobo uses). I know the speed issues of CORBA have been hashed out time and time again but does this mean there has been shift in the KDE attitude to this?
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.
MIME types
User Personal Menus [at least]
Window Manager Hints
CORBA [if any, it should be common]
Drag'n'drop
Components model
Ciao
----
FB
This would mean:
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...
Drop me a line at:
Key ID: 0x54D1D809
There was some discussion about this today on the gnome-kde mailinglist. They say its an serious effort, but in order to succeed it needs MUCH work, and that is unlikely to happen soon.
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
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
Too bad if this move, which would be a huge leap ahead for Unix as a modern desktop and application platform, will be drown in ego wars.
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.
-- Si hoc legere scis nimium eruditionis habes.
Whatever they call it, it sounds like a damn fine idea. I must admit that don't use GNOME (much) or KDE (at all), but a package that takes the best from both worlds has to be A Good Thing (TM), and is the Open Source way.
:v)
Vik
This issue has been hashed out and solved on the KDE-GNOME list. This mail is from ORBit author Elliot Lee http://mail.gnome.org/pipermail/gnome-kde-list/199 9-October/000265.html And this one from aRTS author Stefan Westerfeld: http://mail.gnome.org/pipermail/gnome-kde-list/199 9-October/000265.htm
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
Jon Erikson, IT guru
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
Real people, not hidden behind a veil of corporate competition, but by the desire to create superior technological solutions for their own use. This is the beauty of Open Source.
;-)
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
Any development of a component model for Unix should be project/desktop/Window manager agnostic and independent.
- --------
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.
-------------------------------------------------
-------------------------------------------------
It's life Jim, but not as w
Licensing is not really an issue here, none of the shared technologies in question would need to link to Qt.
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.
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.
If the standards are the same, you have more choices. That's the whole argument that backs open standards. While this is an entirely different topic, one could extrapolate this to consider Microsoft's situation where they are purposfully closing off specs, except that what they close off is basic machine operability, whereas this is along the lines of aligning all of the objects in the individual programs (WOW! Now that's open).
Eh...
RMS specifically ordered that the wheel should not be allowed in Linux.
See man su for details.
- My password is slashdot
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!
--
Never underestimate the relief of true separation of Religion and State.
...
DNA just wants to be free...
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?
I totally agree. Remember the strategy of war... Divide and Conquer.
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.
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.
Babar
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
The Bolachek Journals
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
Only 'flamers' flame!
COM not a bad protocol, people, in fact it's quite clever. first off COM is not a protocol, since COM cannot talk outside of the box its on, you may be thinking DCOM or COM+. also read the link below, DCOM is a bad protocol, its over complicates the conversation between the two boxes, most COM components suck as DCOM components cause you don't take into account network latency or anything else when you first write a COM object. CORBA isn't better, it just sucks in different ways. http://www1.bell-labs.com/user/emerald/dcom_corba/ Paper.html
I find it rather annoying that, when the beginning of an idea was posted, with the comment that it was worth looking in to, the first thing everybody starts doing is coming up with reasons why it won't happen.
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
The ability for objects in different binaries to interact is not and should not be the responsibility of a GUI
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?)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.