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

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

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

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.

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.

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.

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

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

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

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.