GParts is an in-process component system for GNOME based on shared libraries and is in fact KDE's KParts adoption. GParts also implies Bonobo integration. That means that Bonobo components may be wrapped into GParts components and vice versa. The goal is to acheive the highest possible degree of interoperability between GNOME and KDE component models.
GParts for GNOME is everything that KParts is for KDE.
Based on shared libraries, it provides the developer with the following objects and abstractions:
- parts - reusable widgets with XML description of UI layout and actions
- mainwindow, whose interface is described in XML so that it is able to embed parts
- a part manager, an objects whose task is to handle the activation and the deactivation of the parts
The most important aspect of GParts is its integration with Bonobo, so that together these two models form a consistent bipolar component model, providing a feature-complete development platform for GNOME developers that is fully compatible with KDE component system.
In the very beginning two main Linux desktop projects have chosen different approaches to write reusable software components. Both projects had the same goal - to have ability to form new applications from previously written components as from building blocks. GNOME has chosen CORBA language-neutral approach that lead to creation of Bonobo, while KDE has chosen a simpler technique with C++-only components accessible through shared libraries and created KParts.
Though GNOME's Bonobo is probably technically superior to KParts as it offers language neutrality, network transparency and has the whole power of CORBA inside, it turns out that KDE's KParts technology works better. It is:
- by design simpler than Bonobo
- easier to learn for a beginner programmer
- working faster
The consequence of these advantages is that there is more than 30 useful KParts components in KDE at the moment while written GNOME's Bonobo components are mostly useful only inside core GNOME programms, such as Nautilus and Evolution. So, KParts is a better for writing reusable peaces of software just because there are successfull examples of KParts applications, e.g. Kate text editor component, and there are no comparable Bonobo equivalents, though Bonobo 1.0 was released several years ago.
The major difference between KParts and Bonobo is that KParts allows creation of in-process components only, while Bonobo is able to handle both in-process and out-of-process components. In-process components are noticably faster than out-of-process ones, and given that, they are a preferred method of reusing code inside a desktop, because this way we can offer more responsible applications. The example of this is the Konqueror file manager, that is faster than Nautilus and that defines most of users' choices. Even worse, Nautilus is known to be cleaned up from extensive use of Bonobo in 2.9 series for the sake of performance and probably this process will continue.
Unfortunately Bonobo has failed to provide good support for in-process components. The reason of this is probably that CORBA is more network- and interprocess-oriented, and thus it cannot offer a standard ABI interface for in-process objects. So nowadays GNOME does use Bonobo when it worths using, e. g. for integration of really large peaces of software like parts of Evoltion and does not use it anywhere else, because out-of-process components are too heavy to use them everywhere. Given that we may conclude that there is no lightweight in-process component system in GNOME, though it would be extremely useful if we had one.
It is important to notice that there is a separate out-of-process component technology in KDE called XPart. XPart was developed to embed Mozilla's gecko rendering engine into a Qt widget. And through XPart kmozilla component can be accessed as a KParts component! Along with kvim and several sample components there was no need at all in out-of-process components for KDE and XPart development has temporarily stalled.
Now lets look what benefits GParts offers. At first, GParts may be viewed just as a direct mapping of KParts into GNOME's development environment, so that GNOME developers don't need to care if they are interoperating with KDE and embedding a Qt-based component or are reusing GNOME's native Gtk+ code. All they need to know is that they are working with KParts. Similarly, KDE developers may use Gtk+ GParts components as if they were native KParts components. This is possible because KParts and GParts will be in fact two implementations of the same technology and will share as much code as possible. The only difference is that KParts has bindings for KDE/Qt while GParts has bindings fot GNOME/Gtk+.
GParts to KParts mapping will be quite straightforward and consist of a simple bridge between Qt and Gtk+ objects and a namespace mapping, so that KParts may be viewed as GParts and vice versa. I've tested embedding Gtk+ widgets iside Qt and Qt widgets inside Gtk+ within a single main loop and there's a working example as a proof of concept.
GParts would be undesirable if it couldn't be integrated with the current GNOME's component system, Bonobo. But KParts/XPart example makes it clear that out-of-process components can be represented as in-process ones. That means that Bonobo components can be wrapped into GParts interface and used as GParts objects. And from Bonobo's perspective it would be extremely good if GParts could be seen as Bonobo objects. Bonobo<->GParts mapping may involve some design questions such as how to form an IDL definition for a GParts component and is it possible to automotically generate GParts wrappers for Bonobo components from their IDL definitions. I believe these questions may be nicely solved and an easy-to-use simple unified component platform can be built.
GParts->Bonobo mapping allows to use GParts components in any programming language supported by Bonobo. Mono, for example, may use C/C++ coded GParts components as out-of-process components, or if it worths the effort, a direct in-process support for GParts can be added into Mono runtime and some sort of a language binding might be created. Such binding may be closely related to IDL extration for integration with Bonobo.
Now imagine GParts is already here and it offers all the described features.
What are developer's options to write a new complex program and reuse existing code?
First, look at how all mentioned component models interoperate:
XPart --> KParts <--> GParts <--> Bonobo
Here we have a choice: what technology to use as a base for our new program?
Here are the most likely answers:
- We are writing for GNOME in C/C++
Then GParts is the best choice: it allows us to use in-process GParts and KParts/XPart components directly, and Bonobo components through Bonobo->GParts mapping. - We are writing for GNOME in any of supported languages except C/C++, e.g. Python
We use Bonobo as a base technology and that allows us to use KParts/XPart/GParts through GParts->Bonobo mapping. We may write our own out-of-process bonobo components that can be wrapped to be viewed as GParts. - We are writing for KDE in C++.
We obviously use KParts and have the ability to reuse all available GParts/Bonobo components.
All these cases of development should be throughly documented to allow the developers to use them effectively, so I see proper documentation as one of the main objectives of GParts.
To sum up, GParts is intented to fill the gap between GNOME's and KDE component models and to bring us to the world where we can use everything everywhere, write whatever we want in our language of choice and have the ability to reuse all kinds of GNOME and KDE components. Sounds like an utopy, but this is the primary goal of GParts - to make full GNOME-KDE interoperability not a dream but reality.
Having hard time reading GNOME and KDE whitepapers, mailing lists archives and hackers' blogs I saw that everyone is dreaming about an agreement between open source developers on what technologies to use in a free desktop, but sadly there is still a long way to go in this direction. GNOME has been my desktop of choice for the last two years, but when I decided to learn how to write GNOME applications I've found that there is no way to do it that everybody would agree to, and in contrast KDE developers have the feeling that they do things right and do not dispute too much on the subject, so it seems to me that KDE is a more attractive development platform at the moment. Trying to understand what is missing in GNOME that is already there in KDE I've came up with the idea of GParts, that I believe at least worths implementing.
