Embedding external parts into KDE

Up to now, the KPart component model was limited to embedding in-process parts. XParts is an extension written by Matthias Ettrich, Simon Hausmann and Lars Knoll to extend kparts and make it possible to embed out-of-process components. The approach chosen is toolkit independent, as can be seen by their choice to embed Mozilla. Read on for the full announcement and details.

KDE takes a massive leap by providing interoperability with major Unix/Linux software toolkits and applications --
including Mozilla.

Linux and Unix developers, can now easily make KDE components --
no matter what toolkits and software they decide to develop with.
Recent Unix/Linux desktop applications are composed of small
components that could be utilized in several applications or wherever needed. KDE is now the first desktop system to be able to effectively integrate and provide transparent interoperability
with such software -- whether written in the KDE native component model (KParts), plain X Windows, or GTK.

As a first step, users can now choose to use either KDE's native
sophisticated HTML widget or Mozilla's (which currently utilizes GTK) inside the KDE browser, Konqueror. This easily puts Konqueror in the lead when it
comes to browsing the World Wide Web, since the user now gets to select which HTML renderer works best for him/her while still using Konqueror and
having all the same advantages of the popular KDE user interface and technology.

This is only a first step. Other possibilities include providing transparent access to OpenOffice components within KOffice, and embedding other Bonobo components, such as the various Nautilus components, inside, say, Konqueror... The goal is to provide the most powerful desktop for users by allowing them to pick and choose whatever software
they like while still in the familiar and comfortable KDE environment. KDE is close to closing the schism within the Linux desktop environments by
being the first project to allow users to utilize all the software written for different user interfaces within the KDE environment with unparalleled

Also, people writing standalone applications that do not utilize any desktop technology can easily integrate with our environment in ways previously

The KDE project would like to thank Lars Knoll, Simon Hausmann, and Matthias Ettrich for their coding genius in making this happen.


Overview including screenshots and installation instructions


Dot Categories: 


by Peter Putzer (not verified)

A lot of bark, but now bite?

Where are the cool apps actually using Bonobo?

by Cleber Rodrigues (not verified)

Let me see: Evolution, Nautilus, Gnumeric, Gnome-DB, and almost every Gnome Application that would make sense providing a component for re-use.

And actually, what does it have to do with 'cool apps' ???

Soon you'll be able to add AbiWord to that list...

None of these applications is stable yet. For Gnumeric there is even a text that mentions that one shouldn't file bugreports if one compiles with Bonobo (because it is still way too broken).

I'd argue against your statement. I have a fairly large role in the AbiWord project and am an ex Gnumeric hacker (amongst other things). From what I've seen, KSpread can't hold a candle to Gnumeric (though I could be wrong here). KPresenter is pretty darn cool. KWord is a damn fine app that I want to study more. A lot could be gained from Abi and KWord people working together.

AFAIK, Jody (the Gnumeric maintainer) just doesn't want to have to deal with bugreports not related to gnumeric, but rather Bonobo. This is just "boiler-plate" text that he attaches to each release announcement. If you'd try a Gnumeric release that was bonobo-enabled, you'd see exactly what I mean.

Just because an Application doesn't have a "1" as its major build number doesn't mean that it's not stable. It's just under heavy development. When Gnome 1.4 comes out shortly, you'll see what I mean.

Keep up the good work on KDE, guys.

by TrollKiller (not verified)

Gnumeric is *far* superiour to KSpread!

by Anon (not verified)

Dude, that's what "can't hold a candle to" means. Did you even bother to read his post?

by TrollKiller (not verified)

I was replying to your topic, not Dom's.

Hmm, strange. So bonobo can talk to kparts ? Or use any other truely object-oriented toolkit (i mean C++ based) ? How comes ?

by Matthias Lange (not verified)

That´s great!

The following scene comes to my mind:

[On the bridge of the starship Nautilus]

Crewman: Look, Captain, we´re being pursued!
Captain: Full Speed Ahead


Captain: Evasive Maneuvers, Fire Mozilla Grenades!
Crewman: Sir, the grenades simply attach to the
ship, no damage done.

Captain: Oh, we better give up then...


by reihal (not verified)


by egkamp (not verified)

Assimilation is a *good* thing when everyone plays nicely and shares.

by Markus Kohls (not verified)

if i would get the same feelings when i look onto the kde-desktop as when i look at 7of9, it would be great! ;)

cya. markus

by TrollKiller (not verified)

To protect the Internet from ignorant trolls.

"We are KDE of Borg. You will be assimilated. Resistence if futile."

Gnome of Q: "Oh no, not those suckers again..."

"Lower your weapons and..."
(Gnome of Q snaps in his fingers)


Gnome of Q: "Yet another KDE of Borg ship gone. Heh heh."


To protect the Internet from ignorant trolls.

by TrollKillerKiller (not verified)

What a lame reply

by TrollKillerKill... (not verified)

What a lame comment.

by jam_kim (not verified)

If you just want to be a troll and making such wasted comment you have accomplished it. Finally, you've found dot.kde.org.

by G Killer (not verified)

>> "Lower your weapons and..."
>> (Gnome of Q snaps in his fingers)

>> ***KABOOM!***

>> Gnome of Q: "Yet another KDE of Borg ship >>gone. Heh heh."

Gnome of Q: Caption.... Caption.... we....

G Killer: hehehehe... they can't even recognize there own ships...


by Jebediah Smith (not verified)

It's impressive that not a single line of code was modified in Konqueror to do this. Something can certainly be said for the architecture of KDE2.

However, I fail to see how this is in anyway revolutionary. It's been done dozens of times before in many different toolkits.

The article, and comments above, and most ntoably the Slashdot article, suggest that XParts/KParts are now able to embed next to everything - Bonobo Components, OpenOffice, etc. This is simply not the case. Embedding the GtkMozEmbed component is a very special case. This component was designed as a GTK widget. QT can already use GTK Widgets. So the effect shown is different from Galeon, Nautilus, etc only in so far as it required no modification to the Konqueror code.

This is all illustrated in the whitepaper linked to above.

I do not mean to troll, I simply want to set many of the posters here straight.

by Eric Laffoon (not verified)

I do not mean to troll, I simply want to set many of the posters here straight.

I supposed it would be more impressive if you could figure out how to post once instead of four times.

by reihal (not verified)

I don't think he did, it's a bug, it have happened many times before.

by reihal (not verified)

I don't think he did, it's a bug, it have happened many times before.

by Matthias Ettrich (not verified)

KMozilla does not require Qt's ability to utilize GTK widgets. Instead, it reparents an X-Window with XEMBED. This works on a wide range of toolkits.

But your are right. There's indeed nothing revolutionary with the approach, and I don't believe the web page or the whitepaper claim this. It is basically a demonstration on what we TOLD people for a long time now: KParts is not a dead end. It's powerful enough to support other component models. The fact that we use fast inprocess components with a KDE API doesn't mean, we cannot utilize other models. The fact that we dropped CORBA doesn't mean users suffer from less interoperability.

But not everybody is a developer and not everybody understands the technical issues involved. So people simply didn't believe us. "KDE does no longer use CORBA" was percieved as "GNOME components will never be usable in KDE". The only "revolutionary" thing is, that we demonstrated what technical people knew for a long time.

Now, KMozilla is special, because it (or rather GtkMozEmbed) isn's a GNOME or Bonobo component. But the approach we've chosen is indepentent from that. We are confident that we will be able to provide a generic BonoboXPartHost that is able to serve arbitrary Bonobo components as KParts. This is just a bride, it doesn't require changing either Bonobo or KParts.

A similar thing was done with Java and Konqueror previously, or the Netscape Plugin support.

by Jebediah Smith (not verified)

I didn't mean to suggest that the webpage and/or whitepaper suggested that it was revolutionary. I was trying to set some of the posters here - and on slashdot - straight.

If this same technology could be extended to use Bonobo, I have either read the whitepaper wrong, or you are much smarter than I:)

Probably the latter.

While this certainly shows off KParts' well-designed architecture, I'm unsure if this would be practical.

When loading a Bonobo component, you would have all the overhead of Bonobo (oafd, ORBit, etc) along with KParts' overhead. How would this effect performance?

A better idea, IMNSHO, would be a concerted effort to bring a standard COM to *N*x/BSD.

Please, don't anyone reply with "We have a standard COM....CORBA."

by Karl-Heinz Zimmer (not verified)

On Friday December 22, 2000, Jebediah Smith wrote:

> While this certainly shows off KParts' well-designed architecture,
> I'm unsure if this would be practical.

> When loading a Bonobo component, you would have all the
> overhead of Bonobo (oafd, ORBit, etc) along with KParts' overhead.
> How would this effect performance?

Jebediah, please don't get me wrong, but this does not sound very dramatically to me.
The KParts component model was designed to be effective and easy to implement while at the same time working really FAST.

There is not very much in looking for 'overhead of KParts' - trust me: the time consumed by KParts can be ignored when you have to deal with something that time-consuming as CORBA.

I do *not* intend to start a flame-war against CORBA but I thought it might be good to mention that this possibility of embedding external parts into KDE is a great thing: Just be happy and forget about the *tiny* amount of overhead that might be caused by using the KParts model.



by Jebediah Smith (not verified)

You're certainly right. The point of the post was that embedding Bonobo comonents as a KPart would require that oafd, ORBit, et al., be loaded. The added overhead isn't coming from KParts - It's coming from Bonobo.

Does a right click on the KMozilla component in Konqueror bring up a menu? The last time I saw it, neither Galeon nor Nautilus could do it. If a standard menu does not come on a right click (with save as.. copy link etc), it is better to stick to KHTML

by t0m_dR (not verified)

Well, what about using this technology to embed Gimp into Krayon (the former KImageShop)!!. That way you'll have all the power that Gimp already has without the crappy UI!

by reihal (not verified)

Make a Kparts of the GIMP libraries.

by Jason Katz-Brown (not verified)

A kde developer told me a kimp was made, a port of gimp to qt, but that gimp devs got mad so it was never realeased... hmmmmmm...


by t0m_dR (not verified)

ummm,,,,isn't it GPL? So who cares if they were Mad!. Anyway I think that was in the pre GPL era of the QT toolkit. I Think they were Mad 'bout the licence...

by Cleber Rodrigues (not verified)

I think this comes down to a lie.

I just don't believe such a port exists.

by anon (not verified)

Such a port did indeed exist. It was shown to some developers (I think even Miguel Icaza saw it) on Linux-Kongress and on Linuxtag in 1998.

by t0m_dR (not verified)

sure it did, if you search for "Kimp, Linux , Kde" keywors you'll find some (OLD) material about it...

by ChrisWiegand (not verified)

Something I keep thinking of is this: KParts seems to me (a Linux programmer and a VB programmer) to be much more like local-only ActiveX EXEs and ActiveX Controls. (To my knowledge KParts doesn't do networking). Bonobo/Corba, OTOH, is made for networking, and using it locally would have a performance hit vs. KParts (probably not much of one, but it's probably still there). Why not have both? I don't want my real-Cool-Grid widget running over a network, but putting business logic into a component on a shared server somewhere makes lots of sense to me...

by TROLL PATROL (not verified)

IE is like the fastest browser ever, and then embed in xparts in konquerer... totally fast... oh my god... Then embed VM ware in konqi in xparts and run mozilla in the konqi in the vmware in the konqi, totally the slowest thing ever lol.