KParts is the KDE component technology introduced with Konqueror and KOffice. A KPart is a dynamically loadable module which provides an embeddable document or control view including associated menu and toolbar actions. A broker returns KPart objects for certain data or service types to the requesting application. KParts are for example used for embedding an image viewer into the web browser or for embedding a spread sheet object into the word processor.
KPart instrumentation of an application is a low-effort task, because all the technologies used are usually already utilized in the existing code. There are no new programming languages, external processes or protocols involved. It basically boils down to the implementation of a specific C++ interface. Kontact components all have a KPartification history of heroic one-weekend or even one-afternoon hacks.
KParts consist of a view object embeddable in a user interface frame, associated actions like menus items and toolbar buttons and optional extension objects for handling the status bar or special functionality like the forward, backward and history functions of a browser. They are accompanied by metadata like author and copyright information and service types the KPart provides. The metadata is provided as files adhering to the Desktop Entry Standard [35]. This standard, hosted by freedesktop.org, is used in many other places in KDE and other desktop environments, e.g. GNOME [3], to store metadata.
The view object provided by KParts is a standard user interface component which is usually embedded as main component into the main window of the embedding application. It represents the view or main work area of the functionality provided by the KPart.
In addition to the view the KPart provides user interface actions which correspond to menu items or toolbar buttons. The menus and toolbars of KParts are combined with the menus and toolbars of the main window or other components. The actions are described and created based on an XML descriptions of the available actions. This mechanism is known as XMLGUI. It is described in more detail in section 4.3.
Special functionality of the embedding application for use by the KPart can be provided by extension objects which are created by the KPart and made externally visible. One example is the status bar extension which gives KParts access to the status bar of the main window of the embedding application. The KPart sends the messages to be shown in the status bar to the extension and the embedding application takes care of showing them and synchronizing the status bar information when different KParts are activated.
KParts are loaded as dynamically loadable modules at run-time. A trader mechanism based on the service types provided by the KParts is used to select the KPart which fits best to the data or application to be handled and the preferences of the user. For example in Kontact this mechanism is used to find the applications which provide the Kontact integration, and in Konqueror it is used to find appropriate viewer and editor parts for handling documents of specific MIME types.
The actual KPart API basically consists of the functions to select, load and find the desired KPart instance. Specific functionality of the KPart instances is realized by subclassing. The document handling KParts used in applications like Konqueror, for example, provide an interface to load and save documents in a network-transparent way in the classes ReadOnlyPart and ReadWritePart [7].
Communication between KParts is done via the Desktop Communication Protocol (see section 4.2). This extends the API of the specific KParts by functions not only available to the embedding framework but also available to other components within or out of the process of the embedding application.
The KPart interfaces don't include remote function calls, unlike many other component technology frameworks like DCOM [8] from Microsoft, UNO [10] from OpenOffice.org or Bonobo [11] from GNOME. Historically the predecessor of the KParts framework which was based on CORBA [9] from The Open Group did so, but due to its complexity it wasn't accepted by application developers and it was eventually replaced by the current combination of KParts and DCOP which provides a simpler framework for use within a desktop environment. For a more detailed description of the KParts component architecture including a comparison with other models, especially CORBA based models see [6].
The classical KParts model originates from document-oriented views in KOffice and Konqueror. The difference in Kontact is that the KPart instances are not associated to specific documents, but represent views to more global objects, like the user's mails, calendar or contact data. Kontact doesn't subclass the KPart's API, but uses DCOP calls to access the specific functionality of the embedded applications.
Kontact loads a KPart object for each application it embeds. The KPart provides the main view which is usually used in the main window of the stand-alone version of the application. Loading is done on demand, so that only those objects consume memory and affect startup time which are actually used. Unlike in purely document-oriented user interfaces multiple KPart instances are loaded in parallel and communicate with each other, reflecting the situation of multiple applications running in parallel and working together. Concerning the user interface there still is a primary KPart instance which is active. This means that its view is shown in the main window and its part-specific actions are merged into the applications menus and toolbars.