Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference
Total Page：16
File Type：pdf, Size：1020Kb
USENIX Association Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference Boston, MA, USA June 27–July 2, 2004 © 2004 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. KDE Kontact: An Application Integration Framework PIM Components Get Together David Faure Ingo Klock¨ er Tobias Konig¨ Daniel Molkentin KDE Project KDE Project KDE Project KDE Project [email protected] [email protected] [email protected] [email protected] Zack Rusin Don Sanders Cornelius Schumacher KDE Project KDE Project KDE Project [email protected] [email protected] [email protected] Abstract Kontact (section 4). It will discuss the importance of open standards (section 5), give an insight into Kontact Kontact is the new integrated KDE personal informa- as project (section 6) and will conclude with informa- tion management application. Well, it seems new, but tion about the availability of Kontact (section 7), final in fact only the shiny surface is new. Under the hood remarks (section 8) and some information about the au- well-known time-honored KDE applications like KMail, thors of Kontact (section 9). KOrganizer, KAddressBook, KNotes and KNode do their work. This paper describes how KDE component 2 Components vs. Monolithism technologies like KParts, DCOP or XMLGUI enable Why bother with integrating originally disparate appli- embedding of applications to create something which is cations? Why not build a monolithic integrated appli- more than the sum of the parts. cation from ground up with all its parts fitting together 1 Introduction from the beginning? The technical advantages are that a loose coupling Kontact [1] is a new KDE [2] application for managing forces modularization and cleaner interface definitions. personal information like mail, appointments, todo lists This leads to a better factored architecture which is in- and contacts. It is based on existing KDE applications herently easier to maintain and leverages reuse of exist- which are embedded into a container framework by us- ing code. ing KDE component technology and extending it where On an economical side this kind of reuse saves the required. Figure 7 shows a screenshot of the organizer investments, in particular of time and effort of the open component in Kontact. source community, in the already existing applications. The functionality of Kontact emerges from integration All the components integrated into Kontact have a long of the components on the application level. It doesn’t history as independent applications and provide a stable compromise the ability of the components to run as in- and feature-rich base for the integrated framework. dividual stand-alone applications. The user retains the There are also social reasons. Each of the different choice whether to use the components as one applica- Kontact component applications have their own healthy tion aggregating all the functionality or to use some or developer communities. By providing a technical in- all parts as separate applications. tegration framework on the top of those applications KDE is one of the major desktop environments for the developers also get integrated. They still main- Linux and Unix systems. it is based on the Qt toolkit tain their application development environment but gain [29] and mostly written in C++. It consists of a frame- a new sense of community on a higher level. The work providing the desktop infrastructure and a wide Kontact experience shows that this works surprisingly range of applications, from web browser and mail client, well and gives room for new synergies. The mono- through music players, games and educational software lithic approaches we have seen in the past in this area to text editor and integrated development environment. have suffered from the not-invented-here syndrome and Kontact is part of the kdepim module of KDE which reinvention-of-the-wheel scenarios. There are several contains tools for personal information management. projects which tried to write a monolithic application After a short discussion about components and mono- comparable to Kontact and failed because of these rea- lithism (section 2) this paper will give an introduction sons. into the Kontact component model (section 3) and a de- On a philosophical level the integration of GUI desk- tailed overview of the integration technologies used in top applications as done by Kontact can also be seen as interesting parallel to the classic philosophy of UNIX office suite KOffice [15]. Kontact constitutes the integra- commands, single-purpose commands which can be as- tion on the highest level - the level of complete applica- sembled to complex and powerful aggregations to ful- tions. fill almost any task imaginable. By combining single- This section will present the KDE component tech- purpose applications in an integrated suite for personal nology KParts (section 4.1), the desktop communication information management this philosophy is raised to the protocol DCOP (section 4.2), the user interface descrip- application level. tion framework XMLGUI (section 4.3), the integrated configuration framework (section 4.4), and the KDE re- 3 The Kontact Component Model sources framework KResources (section 4.5). The Kontact framework acts as a container for plugging in other applications as components. It provides the 4.1 KParts standard environment like main window, menu, tool and KParts is the KDE component technology introduced status bars as well as a navigation bar to control the em- with Konqueror and KOffice. A KPart is a dynamically bedded components. Applications to be embedded into loadable module which provides an embeddable doc- this environment have to be accompanied by a Kontact ument or control view including associated menu and plugin. The plugin acts as mediator between the frame- toolbar actions. A broker returns KPart objects for cer- work and the application. It exposes the functionality of tain data or service types to the requesting application. the application which is being integrated by implement- KParts are for example used for embedding an image ing the Kontact Plugin API and interacts with the Kon- viewer into the web browser or for embedding a spread tact Framework by using the Kontact Core API. All this sheet object into the word processor. is done in-process. Communication between the compo- KPart instrumentation of an application is a low-effort nents is done via DCOP through clearly defined standard task, because all the technologies used are usually al- interfaces. Figure 1 shows the component model. ready utilized in the existing code. There are no new The plugin API specifies functions which have to be programming languages, external processes or protocols implemented by concrete plugins for providing access to involved. It basically boils down to the implementation the corresponding KPart object, the summary view and of a specific C++ interface. Kontact components all have options how the component appears and is handled in the a KPartification history of heroic one-weekend or even framework application. This includes title labels, icons one-afternoon hacks. and hints about the position in the navigation bar. In ad- dition to that it provides functions to control the compo- 4.1.1 What’s a KPart? nent behavior, starting and selecting of a component, re- KParts consist of a view object embeddable in a user in- questing if the component runs embedded or stand-alone terface frame, associated actions like menus items and and access to the interfaces of the underlying component toolbar buttons and optional extension objects for han- technologies. Finally the plugin API provides functions dling the status bar or special functionality like the for- for handling of drag and drop functionality and user in- ward, backward and history functions of a browser. They terface actions. are accompanied by metadata like author and copyright The framework core API which gives the plugins ac- information and service types the KPart provides. The cess to the framework mainly deals with loading and se- metadata is provided as files adhering to the Desktop lecting of plugins belonging to other components. Inter- Entry Standard [35]. This standard, hosted by freedesk- component communication is done by using the DCOP top.org, is used in many other places in KDE and other interfaces of the individual components. desktop environments, e.g. GNOME [3], to store meta- A Kontact plugin can provide an application or doc- data. ument main view, a summary view and some specific The view object provided by KParts is a standard user functionality and data like menu and toolbar actions, interface component which is usually embedded as main configuration, ”about” data and more. If an application component into the main window of the embedding ap- already provides a KPart as part of its interface adding plication. It represents the view or main work area of the a Kontact plugin in order to integrate it into Kontact is functionality provided by the KPart. only a few lines of code. In addition to the view the KPart provides user inter- face actions which correspond to menu items or tool- 4 Application Integration Technologies bar buttons. The menus and toolbars of KParts are com- The KDE framework provides a rich variety of integra- bined with the menus and toolbars of the main window tion technologies [5]. They have been used on a com- or other components. The actions are described and cre- ponent level for applications like the KDE web browser ated based on an XML descriptions of the available ac- Konqueror [14] and on a slightly higher level in the KDE tions.