Kontact the world! ================== Daniel Molkentin What is KDE Kontact? -------------------- KDE Kontact is both an integrated PIM (Personal Information Management) suite for standalone home desktops as well as a full featured groupware client that can be used with different groupware server solutions (such as the Kolab server or Microsoft Exchange 2000). Kontact's strengths are is its modularity based on the well-known KParts technology (it reuses components of well-known KDE-PIM applications such as KMail or KOrganizer). Secondly it profits from its independence of the data origin. The so called KResource framework abstracts Kontact and its Parts from where and how the calendar data is located. The KResource framework will be described more in Detail later in this talk. The most fascinating aspect about Kontact is that the GUI Framework itself is pretty "dumb". The core consists of less than ten classes. That's because - just as Konqueror - the Kontact Framework (GUI, KParts, KResource) enables the individual parts and thus the Kontact core can be considered a nest or a canvas. As a consequence, the technology is integrated in the components - and in the respective apps consequently. This means that all apps can also run standalone and will still behave integrated. This was a request from many people when we initially thought about the design. Motivations for a unified PIM solution -------------------------------------- So why did we start with a major effort like Kontact? Demand for a visually integrated app was increasing. On the other hand we wanted a flexible framework with maximal extensibility. We also wanted to avoid building a monolithic application. So how does it work? Architecture ------------ Kontact uses KParts provided by the respective apps. But KParts are of course not enough. There are many things to know before the part is actually loaded. Therefore, we introduced KontactPlugins, which provide further information and helper functions. On demand, the part gets loaded. Before all PIM applications were moved to the KDEPIM module, we needed a way to extend KParts in a way that allows us to do it without creating a KPart subclass. The reason is that we would have to store it somewhere. That would have either produced ugly dependencies between kdenetwork and kdepim or it would have added another class to kdelibs. So Kontact got a whole series of so called KParts extensions. Those are classes instantiated as child's of the part. On runtime, they will be found by name using the object tree of the KPart. This is of course quite hacky, even though it works nicely :) We will probably drop this in favor of a KPimPart in the future. So you might wonder how interaction between parts is supposed to work. This is especially interesting given the constrains we had to meet: It needs to work when the applications run standalone and we must not rely on specific parts, i.e. the KMail Part should be drop-in replaceable by another mail client. So our solution was to establish well-defined DCOP interfaces for every possible task and then have applications who implement them. Those applications are known to have those interfaces (indicated by a field in their desktop files). So what we now do is go and ask ktrader to come up with the preferred application or part that provides this specific interface and query the returned application. This way, we completely abstracted the communication between parts. To give the magic a name, it's called KDCOPServiceStarter. The next problem was to abstract the resources, for example for the location of the calendar or your contacts. Therefore, Cornelius Schumacher wrote KResources. This framework provides other libs, such as libkabc and libkcal with the ability to abstract their the sources and format of the resources. The application using those lib doesn't need to care. ### Of bouse there have been a lot of improvements in KMail, KOrganizer and KAddressbook. The most important step was to turn KMail into a KPart, which was what Don Sanders did. There were also some improvements and cleanups for the KOrganizer and KAddressbook parts. KMail got a lot of features, cleanups and speed improvements that Kontact benefits from. Adjustments and Enhancements ----------------------------- The authors and contributors of all participating applications where very helpful. A lot of great and very cool improvements were made so I will only name those associated with Kontact KMail - Turned into a KPart - Use improved KDockWidgets again (TODO) - Independed Configuration options (TODO) KNode - Turned into a KPart - Independed Configuration options (TODO) KAddressbook - Turned into a KPart - Independed Configuration options (TODO) - Use KResource framework KOrganizer - Improved KPart - Use KResource framework Additionally, a summaryview was added to enable the user to monitor all important aspects of PIM and deliver some extra information ("at your fingertips" ;) Configuration -------------- For configuration of an application that holds several parts, we had to go a new way. The main problem is that the application needs to know about all configuration options of the parts. The problem was solved thanks to Matthias Kretz, who extended the KCModule principle invented for KOrganizer to work with KTrader. Thus, an application can query for its parts and get all required configuration dialogs it has to take care of. Of course, this will not crowd KControl with new entries. Server bindings --------------- Today, a PIM Client is nothing without a groupware server that makes it part of a groupware solution. Hence we aim for compatibility with a broad amount of servers. For the 1.0 release, we will specifically target on two popular systems. The first one is the Kolab client which was created as a result of the Kroupware project. The code for that even already exists! The contract from the BSI says code must flow back into regular KDE development and KDAB's Bo Torsen was thus cool enough to help with Kontact even beyong this scope. Kontact will therefore become the official successor of the Kolab Client. The second platform we will target is Exchange 2000. You might wonder why we chose Exchange. The protocols are said to be binary, complicated and undocumented. There must be a reason why Ximian sells this Outlook connector, isn't there? Interestingly enough, it's quite trivial to support Exchange 2000. The reason is that Exchange can talk IMAP (for the mails) and WebDav (for contacts and calendar). KOrganizer already supports this, so all an official "supported" stamp would take is a bit of intensive testing and integration, i.e. adding a setup wizard for it. That's why Kontact will provide Exchange 2000 bindings for free. Of course there is a catch. It needs intensive testing and a really, really well working implementation (and who owns a copy of Exchange we could test it with?). Future ------ It would be nice to see bindings for more groupware servers. As you can see, adding new ones is not really magic. Nice to see would be bindings for SuSE Linux Enterprise Server, OpenGroupware.org or Samsung Contact, but we belive that we convered the two most important ones for now. Corporate and worldwide instant messaging would be definately nice to have. In addition we could support customized workflow via kjsembed and a well defined access to the server. This might be a pretty cool, but definately beyond 1.0. We consider to make Kontact independed of KDE with regards to release cycles after KDE 3.2 is out - just as we do with KOffice. Summary ------- As you can see, Kontact is a mighty effort and it still needs a lot of work for it's initial release which we hope to get out right along with KDE 3.2. Another very important aspect is that it's not only the Kontact team who makes this software shine, but especially the authors of the applications that we use. Without their help, we would have have a pretty long and stony way. Thanks!