Interview with KDE-PIM Hacker Cornelius Schumacher

Our final interview in this series with the hackers at the on-going Dutch KDE PIM meeting is with none other than KDE-PIM module project leader of Cornelius Schumacher. Enjoy the interview.

Cornelius at the KDE PIM Conference

Cornelius please tell us who you are and what your role is in the
KDE project.

I have been around for quite a while now. I recently found the first patch I
contributed to KDE when looking through old mails. It was a fix for the
development version of KOrganizer which made it not crash when starting
up. This was during the porting from KDE 1 to KDE 2. Funnily enough I
sent the patch to the KOrganizer mailing list exactly on this day six
years ago.

My main focus has been KDE PIM from the beginning, but I have also done
some stuff in the core libraries and other stuff like maintaining the
KDE Help Center.

As my day job I work for SuSE/Novell.

Can you
tell us a bit more about what you are currently working on? If you
could code 24h a day for six weeks in a row, what would be the thing
you would do?

I'm currently working on usability and collecting ideas for KDE 4. I'm
also experimenting with some new technology, e.g. Superkaramba. If I
could have a couple of weeks of unexpected extra spare time for coding
I would probably finish the Kontact port to Windows.

We have seen several developers in interviews and blogs talk about the KDE PIM event in the Netherlands and what they are planning to work on
during the meeting. Do you have any plans or ideas for this meeting?

There are two big goals I would like to achieve at the meeting. First,
creating a roadmap for KDE PIM 4. Second, relaunching the KDE-PIM web
pages with some fresh and rejuvenated content. But I'm sure there will
also come up some new ideas at the meeting.

I saw the attendance list of the PIM meeting and it seems that the people attending have had a tight relationship with each other for a while now. Would it good to have some fresh blood in the group?

We always had some people at the KDE PIM meetings which nobody has met
in person before. It's true that there is a fairly stable core of
people, but it's certainly possible to get fresh blood in the group.
This time we for example have Frank Osterfeld of Akregator fame, who
is a new member of KDE PIM.

We heard that some usability people are coming. What's their role
during the meeting?

That's part of the quest to deeply integrate usability work in the KDE
development process. We already had quite some success with it and I
think usability has never been as present in the mind of the KDE
developers as it is now.

We try to get usability feedback as early in the development process as
possible, so that it can really have the impact which is needed to
create high-quality user interfaces. Having around the usability people
when thinking about KDE PIM 4 will be a great asset. I'm sure that KDE
4 will be the most user friendly KDE ever.

What can we expect from KDE PIM in KDE4? Is there some roadmap?

There are lots of ideas floating around, but we haven't really started
the concrete discussion about KDE PIM 4 yet. I expect the we will come
up with a first roadmap at the meeting.

What's the status of the submitted RFC GroupDav, a protocol the PIM
people came up with during the last meeting together with hackers
from Opengroupware.org?

GroupDav is not a formal committee standard. It has been created from
the needs for standardization which arose from actually implementing
communication between OpenGroupware.org and Kontact. It's meant to be a
pragmatic standard, which makes it easy to implement, both on the
server side and on the client side without introducing much new
technology.

The beauty of GroupDav is that it makes extensive use of existing
standards and the existing development infrastructure, so that we can
take profit of having the excellent WebDav and HTTP kio slaves and our
iCalendar and vCard libraries.

GroupDav has been adopted surprisingly well. There is work going on to
add GroupDav support to Evolution and SunBird, the Mozilla calendar
project. With Citadel there also is a second server implementation.

Isn't groupware in OSS becoming difficult now that Hula groupware
server is supporting CalDav instead of the GroupDav protocol?

Quite the contrary. I think Hula is is a great thing for open source
groupware. It's not the first open source groupware server, but it puts
the focus on the right aspect, on creating a system which people love
to use. This can get the groupware thing out of the dark corporate
corner where it currently hides and annoys the people which are forced
to use it. To be fair I have to say that Hula is not the only system
which is trying to achieve that. Others are doing this as well.

About CalDav I would like to add, that there is no conflict between
GroupDav and CalDav. GroupDav can be seen as the continuation of
classical iCalendar over HTTP which KOrganizer has supported since version
2.0 (released almost five years ago) and what Apple has tried
to make proprietary with their "webcal" protocol. GroupDav is the pragmatic
approach to create a protocol which takes more advantage of having a
server, providing more fine-grained access and a solid base for syncing
and caching data by exploiting the lesser known features of HTTP 1.1.
CalDav is one more step. It adds more power, but on the other hand also
hasn't the scope of GroupDav, as it only targets calendar data.

Once Hula has usable CalDav support, Kontact will support it. KDE PIM
has a track record of implementing server access within days. Hula will
be no exception. Let's see how things evolve, but maybe the
Hula/Kontact combo will be the killer application which will bring
groupware to the common user.

Where do you think KDE PIM shines?

What I like most about KDE PIM is the community. There are lots of great
people and if you look at the commit digest KDE PIM usually is the most
active KDE core module. It's really fun to be part of this community.

Another aspect is the excellent technology which has emerged from KDE PIM. It
always has been a breeding ground for new KDE technology. For example
KConfig XT or KNewStuff were born in KDE PIM.

Finally, there is Kontact which is a real killer application. It's kind
of the essence of KDE PIM. I really enjoy all the nice comments and
good feedback about Kontact. The best thing about Kontact from a
developers perspective is that it has a very solid architecture. This
provides the potential to quickly adapt to whatever future requirement
will arise.

What part of KDE PIM needs some serious attention?

As a user I would put my attention on Kontact. That's where most of the
exciting stuff will happen.

If your question is asking which areas of KDE PIM I think needs work, I
would mention the KMail internals. Mail still is the heart of personal
information management and systems like Gmail show that there can be
quite some innovation in this area. Although it has improved
significantly recently, the core of KMail still needs some work
to make it as flexible as it could be, so that we can better focus on
providing a usable, innovative and polished user interface.

But all the developers of KMail are already working as hard as they
can, as far as I can judge. How do you see that is going to happen?

It's not about creating extra work. Cleaning up the code will quickly
save us work, because it allows us to implement new features with less
effort and do bug fixes faster and more reliable. Constant refactoring
is an essential part of open source development, especially in KDE. KDE
4 will provide us with the opportunity to do some of the stuff we havn't
dared to touch in the past because we will have to work on the code for
Qt4/KDE4 porting anyways.

What future do you see for KDE PIM?

Well, I don't have my crystal ball at hand, but I feel that the future
of KDE PIM will be bright ;-)

So another thing we heard is that you are leaving to go to GUADEC in
Germany. Could you tell us more about that? Any more KDE people going
to be there?

Some people have asked me, why are you going to GUADEC, aren't you a KDE guy? I tell them, yes, I'm a KDE guy and that's why I'm going to GUADEC. GNOME
and KDE are the dominant desktop projects on Linux and other Unix
systems. We have the same goals and there are lots of areas where we
can work together. We should jointly go for the 98 percent of Windows
desktops out there and not fight each other. A bit of healthy
competition is quite useful though.

I will meet some people on GUADEC to talk about cooperation and
standardization. One topic is a common documentation standard, another
is syncing. There certainly will be others.

There will be a number of other KDE people at GUADEC. Have a look at the
KDE Wiki for more details.

The KDE PIM Meeting Group Photo, see Fab Mous's blog entry for names.

More photos of the conference are available on kde.nl.

Dot Categories: 

Comments

by Gerd (not verified)

There always is a project participation entrance barrier. How can "truck numbers" be reduced. Translation should not be an easy task for average joe contributors, not require special skills such as CVS knowledge. I of am afraid of 80% translations of KDE main languages and it shall not become a bottleneck for KDE 4. Some premature web based contribution engines such as IRMA and pootle adress the important issue. However now the translation does not catch up quickly enough.

by Debian User (not verified)

Hello,

can you explain more why internationalisation must be quick?

Is it really going to be a disaster when it only catches up in 4.0.3?

I personally see no reason why i18n cannot be done only once the bugs are being ironed out...

That said, I often see wrong/unappropiate translations into my language. What I would love to have is a "tool" to run and submit the change proposal to some list of people who take it and put it to cvs.

Kay

by Nicolas Goutte (not verified)

It is one of the policy of KDE to release translations with the first stable version. (Yes, some other projects do otherwise.)

As for the "tool", you can use KDE Bugs: http://bugs.kde.org

Have a nice day!

by Anonymous (not verified)

> That said, I often see wrong/unappropiate translations into my language.

And how does that happen? Because some translators never run the application they translate or never the development version of it prior release. Those web translation interfaces intensify this effect additionally as translators may not even be interested in/run KDE. They get single strings presented and don't know how terms are translated elsewhere within the same application or elsewhere in KDE. And likely they don't even know the tools or lists/ways how to report ambiguous strings back to the developers of the for translation process aggregated projects.

> What I would love to have is a "tool" to run and submit the change proposal to some list of people who take it and put it to cvs.

http://bugs.kde.org exists: product="i18n", component=your language.

by Rinse (not verified)

For reporting bugs in the translation, the Dutch team uses a html-interface:
http://www.kde.nl/helpen/bugs.html

wich can be used besides bugs.kde.org

by Anonymous (not verified)

> Translation should not be an easy task for average joe contributors

No, I would prefer quality over quantity anytime.

> not require special skills such as CVS knowledge

You don't need CVS knowledge for KDE (anymore). :-)

by Nicolas Goutte (not verified)

Only the I18N/L10N team leader needs a SVN account. The others do not and as far as I know, some teams are working that way (by dispatching the work).

Have a nice day!

by ac (not verified)

>>There always is a project participation entrance barrier.
Which is mostly in the head of the people, I found that joining a team is quite easy, and that for every type of skill there is a job available.

>>Translation should not (not?) be an easy task for average joe contributors, not require special skills such as CVS knowledge.
Translating/localizing software does not require special skills that are too hard for joe user. For example, the Dutch translation is coordinated by a cook. How hard can it be if even someone with no link to ICT, like a cook, can handle it?

>Some premature web based contribution engines such as IRMA and pootle adress the important issue.
The problem with pootle and IRMA (AFIAK) is that it does not use a translation memory. If you have a large amount of applications translated, you can use those translations to translate new apps for about 40-60% (considering simple apps). This increases the consistency between apps and reduces workload for the translators.

> However now the translation does not catch up quickly enough.
KDE is shipped with 50 languages, which is quite a lot already.
The bottleneck in translating KDE is not the skills joe contributer should have in order to use the special tools for translating, it is the knowledge of the English/Native language, and the ability to figure out how a string is used in the application. Also, translation is very time consuming- not everyone has the time to participate in a translation project.

But anyone who prefers KDE in their own language should team up with their translation team. Even small contributions, like proofreading stuff or giving comments about the translation while using KDE, are more then welcome.

You can find your team on http://i18n.kde.org

by Anonymous (not verified)

What is its state? Anybody else working on it?

by ac (not verified)

http://nat.org/2005/may/

Red wine and a Rolex, I wanna work for Novell as well...

Maybe I should just go on an create a "Linux"-company, maybe it'll be aquired :-D

by me 2 ac (not verified)

Maybe one of the advantages of KDE people is that they are somehow more "free"
in their mind, and not under pressure of $10k+/month salaries and bound to
create "shareholder value", but more "desktop-user value"...

by Ralf Becker, eG... (not verified)

It's available in svn for the development branch and the stable 1.4 branch. We fully support now contacts, events and ToDos with full folder discovery for Kontact. It's planned to have a further folder hierarchy allowing to access the addressbooks and calendars of other users or groups (not yet implemented). The implementation has been tested with Kontact of cause and the Thunderbird GroupDAV addressbook pluging (aka SOGO connector from www.inverse.ca). For more information see http://www.egroupware.org/wiki/GroupDAV
Ralf