Jump to content

KDE PIM/Meetings/Osnabrueck 2

From KDE Community Wiki

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.


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"