< KDE PIM | Meetings From January 2rd to 5th 2004, KDE PIM developers met in Osnabrück again to discuss about and hack on the KDE PIM application family. The results of the discussions and the hacking can be found below. Contents 1 Kolab Client 2 Release Planning 2.1 Versioning scheme for separate kdepim release 2.2 Maintance of the 3.2.x branch 2.3 Other issues and conclusion 3 Individual reports 3.1 Reinhold 3.2 Daniel 3.3 Tobias 3.4 Till 3.5 Bo 3.6 David 3.7 Adriaan 3.8 Ingo 3.9 Cornelius 4 Summary of the Hacking 4.1 General 4.2 KAddressBook 4.3 KMail 4.4 Kontact 4.5 KOrganizer 4.6 KPilot 4.7 KResources 4.8 libkcal 4.9 libkdepim 5 Experience with Icecream Kolab Client In the "Kolab client" session the status of the different Kolab client parts in Kontactwas presented. Marc also gave a short overview of the work currently done in the Aegypten branch. We identified as main missing parts: Invitation handling Move iCalendar parsing from KMail to KOrganizer Plugin interface in KMail for handling display of special mime types (like iCalendar for invitations) Configuration Move KMail to KConfig XT Port KMail configuration dialog to use KControl modules Centralize identity and account configuration Kolab Configuration Wizard (To be addressed by generic configuration wizard framework based on KConfig XT) Free/Busy Handling in KOrganizer KPilot integration in Kontact Work was done on all of these topics during the meeting. A lot of code went to osnabrueck_branch and some of the tasks from the list are already completed. Release Planning Even before the meeting there was consensus within the kdepim team that a separate release of kdepim shortly after 3.2 would be useful to deliver the features which weren't completely ready for 3.2. There was a session to discuss this release at the meeting, followed by an IRC meeting including some of the people not present in Osnabrück. Cornelius presented a proposal for a release plan: At Osnabrueck we discussed the next kdepim release after 3.2. There was a wide agreement that it makes sense to do a separate release of kdepim soon after 3.2 idependently of the rest of KDE to deliver the features which were almost ready for 3.2 but finally didn't make it into 3.2. Key features we would like to include in the separate kdepim release are: - Kolab client - KitchenSync (Syncing calendar and addressbook between desktops) - HTML mail composing - KPilot integration into Kontact - Client-side IMAP filtering - Connection of Kontact to eGroupware The propsal is to make this a feature-driven release by starting the release cycle when four of the six key features are implemented. The estimated time frame for this would be end of February. The release cycle would look like this: x: Start of release cycle triggered by completion of four of six key features x + 2 weeks: feature freeze, branch, alpha release x + 5 weeks: beta 1 x + 7 weeks: rc1, message freeze x + 9 weeks: stable release, documentation freeze, merge to HEAD x + 13 weeks: i18n release + critical bug fixes If required we can add additional betas or release candidates delaying the subsequent steps. If all goes well, the release would happen somewhen in May. To make it possible to release in the proposed way we need some additional policies. All the people in Osnabrueck agreed on that: - kdepim has to compile and run with the released stable 3.2 kdelibs, no dependencies on changes in the kdelibs HEAD branch later than 3.2. - kdepim has to be kept stable enough to be ready for an alpha release two weeks after the feature completion criteria is met, that means no experiments which will need a lot of time to become stable, but keeping the kdepim HEAD branch in a usable state. David proposed me to be the release coordinator for the separate kdepim release, there were no objections to the proposal and I'm willing to do this job. Two questions were discussed in depth: Versioning scheme for separate kdepim release One proposal was to name it kdepim-3.3. In favour of this scheme is that it speaks for itself, it clearly indicates that the release is an update with new features, it fits to the way kdepim releases were done in the past and it would make packaging straight-forward. Another proposal was to use a completely different name like Kontact 1.0. This would have made it clear that it is a separate release. It might also be better suited to avoid confusion of people looking for (non-existing) kdelibs-3.3 packages fitting to kdepim-3.3 packages. The concrete Kontact 1.0 name wouldn't be appropriate for all parts of kdepim, though. We also discussed putting the new features in the 3.2.x branch, but this has the severe problems that it would break feature and message freeze in the stable branch, would introduce new bugs into the branch, would have a misleading versioning scheme (the minor release isn't used for feature updates up to now) and would eliminate the option to maintain a stable 3.2.x branch without the new features. The conclusion and agreement was to go with the kdepim-3.3 name Maintance of the 3.2.x branch With a kdepim-3.3 release another branch is introduced which needs additional resources. The question came up if the 3.2.x would still be maintained under these conditions. There are several reasons for maintaining the 3.2.x branch. This would be the more stable branch. Maintaining it wouldn't force people to upgrade to kdepim-3.3 with the new features (and new bugs). Some packagers will take up the official stable 3.2.x branch. Against maintaining the branch speaks that it would be less effort to not do so and that packagers would have a clear recommendation what branch to use. The conclusion and general feeling was that kdepim-3.3 development should happen in a separate branch in order to keep all options. How much effort is required to do that depends on who picks up which branch and how stability of the 3.3 branch develops. Other issues and conclusion Adriaan proposed to offer some "Janitor" jobs for things like providing screenshots for documentation and volunteered to follow up on this proposal after the meeting. During the IRC meeting we discussed some aspects of the release in some more detail. General consensus was to follow the proposals. As result the kdepim-3.3 release plan was set up. This hopefully will result in a Kontact 1.0 release in May 2004. Individual reports These are the individual reports of the participants of the meeting. Reinhold First, I started off fixing some smaller korganizer bugs and discussing some patches with Lutz. Later I merged the two kpilot config dilogs to one, so that we'll only have one kcm module for kpilot. The rest of the time was spent on trying to convert all of kpilot to KConfig XT (only partly finished) and writing the kontact plugin (showing kpilot's current state and config in the summary view and making the config available in the menu). The latter is more or less finished already, but not yet commited, the KConfig XT is under way (and still needs a lot of work to fix the config sync issue, as we have two processes working on the same config at the same time), and the KCMification of KPilot's setup dialog is also done but not commited yet. To sum up, what's finished: -) combine the two kpilot setup dialogs to one -) make kcm for setup dialog -) write kontact plugin to show the status of kpilot and make the kcm available in the config dlg What's halfway done: -) Moving all conduits and the kpilot and kpilotDaemon apps to KConfig XT (yes, that's the boring and time-consuming monkey-work on the one hand, and on the other hand I have to redesign the whole config stuff framework in kpilot, which was already quite sophisticated by passing on the global config object to the conduits and making sure that the config loaded in kpilot and in kpilotDaemon stay in sync -- at least most of the time ;-) ) Still missing: -) Config sync issue of kpilot and kpilotDaemon -) add a dcop signal to kpilotDaemon to indicate a config and/or status change, so the plugin can connect to that signal and doesn't have to poll the daemon ever few seconds to update the status. -) Simple "Wizard" to setup KPilot and its conduits for kontact Daniel I started by looking through the bugreports and looking for ready-to-apply patches. I was lucky and found one by Volker Krause who fixed the problem with KNode not honoring the statusbar extension. With that patch the KNode part does no longer permanently occupy the statusbar after being launched. Then I fixed icon loading in KOrganizer when running as part and investigated a nasty crash that was caused by a dangling pointer and that was eventually fixed and committed. Inbetween, I stopped PIM hacking to investigate issues with icecream, the new cool tool distcc-derived tool that we used for distributed compilation. I ported the scheduler and server over to use getopts() for commandline parameter handling and added a README. In osnabrueck_branch, I fulfilled some minor wishlist items, such as renaming items which is currently not possible anymore due to string freeze. Finally I went through the Kontact Settings menu and tried to ensure constant menus. XMLGUI is tricky, but with David's help, I was able to get a consistant menu structure without too much hassle. Aside of that, I had some interesting discussions with Lutz about syncing and available applications and libraries. I assisted David to fix the nasty KUniqueApplication issues. Finally I cleaned up the bug database Tobias At first I applyed some patches from my harddisc which hadn't been reviewed and did manly the following stuff Kontact: - using 'Configure Summary View...' as action name #70466 - show this configure action only when kcms are available #71326 - let the knotes part and summary widget using CalendarResources - a small gui improvement by using grey bars as headlines - add configUpdate() method to Kontact::Plugin KAddressBook: - made VCardTool a private class and port all apps to VCardConverter - removed wrongly added picture #71852 KOrganizer: - add multi day selection to osnabrueck_branch - fixed issue with missing actions of the plugins when embedded in kontact Furthermore I reworked the contact editor in KAddressBook, it's now extensible via plugins. During the last days my main actions were bugfixing and adding new cool stuff, see the next cvs digest for more info ;) Till I did some dimap fixes, reworked its status handling to upload locally changed flags and share more code with online imap. Then I started on porting the kmail configure dialogs to kcms and the kmail config backend to KConfigXT for easier integration in Kontact and the overall greater good. Inbetween I spent time discussing details of the mimetypehandler plugin design with Marc and Ingo. Bo Work quite a lot on dIMAP. It's now as good as it gets for 3.2, and it is a lot faster and much better. Thanks to Till for helping me out here. I have now gotten the IMAP resource for KAddressBook in shape. Most of this work was done during the meeting, some of it by Tobias (thanks). KMail now no longer links to ktnef or libkcal - a process that was started during the meeting and just finished. This is the first step in having a plugin for showing invitations. I also made the first step towards having invitations handled in kroupware_branch style again. This will be finished during the upcoming week. And finally the IMAP interface of KMail was completed. David Speedup loading of files with many events by a factor of 7 (this helps with karm and korganizer startup times). Fixed karm so that it doesn't create an event every time the autosave timer fired. This was the reason for the huge number of events in karm's .ics file. Improve integration between standalone apps and kontact. This means one can launch "kmail", "kmail [email protected]", "korganizer", "kaddressbook --new-contact", "knode news://server/group" while kontact is running, and kontact will answer that call the right way (switching to the part if no argument was given, or handling the command lines arguments). In all cases the kontact window is also activated (brought to the front). Also wrote a test plan (in uniqueapphandler.cpp) to make sure to test all cases. Technical description of the above: * kontact plugins provide a DCOPObject to handle newInstance calls. In order to parse command-line options it needs to call something in the part - which it does using an in-process DCOP call, since it doesn't link to it. * the above isn't done if standalone app was already running when kontact starts. In such a case the plugin has to watch for the moment when the standalone app terminates, using the DCOPClient signal. Then it can create the above. Note that once this happens, kontact "takes over", the standalone app can't be launched anymore. * This required two changes in kdelibs (new method in DCOPClient, and a way to reset KCmdLineArgs in order to redefine a complete new set of arguments). Adriaan The only thing I really did was make the KPilot KNotes conduit mostly work. With Reinhold, we re-did the configuration of KPilot yet again, and started a move to kconfigXT (and discovered all of its limitations). Reinhold made a kontact summary plugin for kpilot, so that the first steps to visibly integrating kpilot with kontact have been made. Ingo I did the following at Osnabrück: - Discussed with Marc the body part formatter plugins (which will be used for handling invitations) and started the implementation. - Fixed bugs, handled bug reports, reviewed patches. Cornelius - Generic framework for configuration wizards based on KConfig XT. This currently consists of two classes (KConfigPropagator and KConfigWizard) and a small test program in libkdepim. The goal is to describe configuration wizards by some propagation rules for configuration options added to a KConfig XT XML file and some simple widgets to be put in into a standard wizard-like dialog. This should solve the problem of the Kolab client configuration which needs a lot of settings in the individual applications to be set based on only a small set of information like address and account information of the Kolab server etc. - Release planning for kdepim-3.3 - Discussions, patch reviewing, organization Summary of the Hacking These are the most relevant things which were done during the hacking sessions on the CVS branch which was created for this meeting (osnabrueck_branch): General Move iCal handling from KMail to KOrganizer (Bo) Implement IMAP resource for KAddressBook (Bo) Fix problems with menu order in Kontact (Daniel) Improve integration between standalone applications and Kontact (David) KAddressBook Plugin interface for additional contact editor pages (Tobias) KMail IMAP/dIMAP fixes, especially message status handling (Till, Bo) View all contacts of an attached vCard instead of only the first one (Andreas) Spam Filter Setup Wizard (Andreas) Make invitation handling work as in the Kroupware project (Bo) Kontact "New Article" for Newsgroups component (Daniel) New KNotes part (Tobias) Add todo summary view (Tobias) KPilot plugin for Kontact (Reinhold) KOrganizer Multi day selection (Tobias) Bug fixes (Tobias, Reinhold, Cornelius) KPilot Bug fixes (Adriaan, Reinhold, Daniel, Tobias) Configuration dialog changes (Reinhold) KResources Add xmlrpc (eGroupware) resources (Tobias) Finish KABC-IMAP resource (Bo, Tobias) IMAP resource fixes (Bo) libkcal Speed up loading of calendar (David) libkdepim Added PluginLoader template (Marc) Experience with Icecream During the hacking sessions we used a new tool called icecream for distributed compiling. This is similar to Teambuilder and distcc. General experience was quite positive. Some improvements on icecream itself were done during the meeting. Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Meetings/Osnabrueck_2&oldid=997" This page was last edited on 17 January 2010, at 16:38. Content is available under Creative Commons License SA 4.0 unless otherwise noted.