Last year in January, Intevation invited the KDE PIM team to a meeting for a hackfest to their offices at Osnabrueck. This was such a great success, that everyone was glad Intevation invited several European KDE PIM team members a second time exactly one year later to polish and fix up Kontact and its components for the upcoming KDE 3.2 release. Last year the big decision was to make Kontact the successor to KolabClient. This year the plan was to make a a roadmap for future KDE-PIM Development. The developers took the opportunity to discuss complicated issues in detail and sit together for brainstorming or in order to fight evil bugs.
Meanwhile, Cies Breijs revamped the Kontact homepage. It's now back with a new design and more content and will be updated more frequently now. Thanks a lot Cies! Other thanks are due to Bernhard Reiter and Jan-Oliver Wagner and the rest of the Intevation
staff for hosting the meeting.
Kontact most of all has seen a lot of polishing to make sure it shines in its initial release. Several bugs have been tackled, KNode is now a true Kontact part, Kontact replaces all PIM applications seamlessly when running. Furthermore work has been put into speed improvements with ICal and IMAP and stability. GUI consistency fixes were not, of course, forgotten.
In order to be able to commit new features and ideas that arose during the meeting, osnabueck_branch was created. This branch will be merged back to to main development line ("HEAD") after the freeze for 3.2 is over. Improvements in this branch include the port of many config dialogs to KConfigXT and KCModules to allow for a smoother integration of config options in the next version of Kontact. KPilot integrates into Kontact and wishlist items have been implemented. For those interested in details, the developers summed up their activities during the meeting.
The developers decided on a seperate release for the KDE PIM applications. Cornelius Schumacher of KOrganizer and KitchenSync fame will act as release coordinator for KDE PIM 3.3. The developers agreed on a set of features (HTML composing, KitchenSync integration, Kolab and eGroupware Integration and Client-side IMAP filtering) as well as on a release schedule. Of course, features not listed on the release plan can also be added if they are mature enough.
To speed up compiling, Stephan Kulow and Michael Matz from SUSE generously provided an early version of icecream, a distcc-based tool for centralized distributed compiling which proved to be really helpful.
The KDE PIM Team will meet again in March at the Chemnitzer Linux-Tag 2004 for a meeting with developers of groupware server projects to discuss and implement Kontact integration to enable you to make Kontact the best-connected groupware client available!
Comments
My employer uses MS Exchange (which seems to be very popular at least in the USA). Unfortunately I am unable to schedule meetings with KOrganizer in KDE 3.1.4 (although I have been able to download my calender from the Exchange serve! Great Job!), nor have I been able to use The Exchange Server's Global Address Book.
Does anyone know the state Exchange/webDAV support in 3.2, is anything being planned for 3.3? Currently Evolution + Connector seem to be the only option.
Thanks. You guys are doing a great job!
for what I've read, there is partial Exchange support, but it will be disabled in 3.2. coming for 3.3, probably.
Yaaay! I can't wait to finally ditch Mozilla mail. I don't care if it's off by default, as long as it's an option!
Also: I'm assuming it'll send multipart/alternative with plaintext. Much as I like HTML mail, HTML mail without a plaintext fallback is evil.
Your assumption is correct. KMail will never send HTML only messages.
What about displaying incoming HTML messages with embedded images?
KDE technology makes it reasonably easy, I think, I guess it's just a kioslave that ask Kmail for the MIMEd image in the message and gives it back to the KHTML viewer part...
It's on our todo list. It's more likely that we'll simply change the cid: URLs in the DOM tree to local file: URLs than that we'll solve this with a kioslave.
Will this feature use the HTML WYSIWYG editor being developped for Quanta (I don't remember its name... Kafka ?) ?
No. At least not at first. A new Komposer framework is in development which will allow to plug several editor parts into the composer.
> Last year the big decision was to make KolabClient the successor to Kontact.
Do you not mean Kontact the successor to KolabClient? :-)
And maybe
> invited the KDE PIM team to a meeting
should have been some of the European members of the KDE PIM team.
Note that we had to pay all our expenses (travel, accommodation) ourselves. Also note that members of the KDE PIM team came up with the idea for this meeting and just asked Intevation to host it (because of the good experiences of the first meeting in Osnabrück). So you could say that we invited ourselves. ;-) Intevation generously agreed to host the meeting and I take this opportunity to thank them for this.
So it's not Intevation that excluded anyone from the meeting. Instead the organizers of the meeting (maybe falsely) assumed that non-European members of the KDE PIM team wouldn't have had the resources (money, vacation from work) to participate.
The kdepim team of course consists of many more people than those present at the Osnabrueck meeting and we actually did ask some key non-european kdepim developers if they would like and be able to join us.
One of the great things about KDE is that it is a working virtual community which brings together people from all over the world. As nice and useful personal meetings are, we shouldn't forget that this is only one small piece of what makes KDE successful.
Sounds reasonable to me.
Even more precise:
Kontact will be enabled to act as a Kolab Client.
Will the separate PIM release really be called KDE PIM 3.3? IMHO that's a bad idea. If the PIM apps will still be released with KDE, then when KDE 3.3 comes out there could be version confusion ("Are you using KDE PIM 3.3 or KDE 3.3 PIM?"). If they will no longer be a part of normal KDE releases, then they should take their own version numbers and not try to stay in sync with KDE's.
It's unfortunately the best of the bad cases. If we chose anything else, it would be a problem to later decide we would come back into the KDE release cycle. It's also possible that we decide to keep releasing kdepim separately from the other KDE parts.
It's quite uncertain wether there will be a KDE 3.3 release or it will be 4.0, so it might not be a problem at all. Should there be a KDE 3.3 release in, say, august, kdepim will most likely not be released with it.
Bo.
Why not merge the KDEPIM 3.3 stuff into kde 3.2.1 and then you don't have to call it anything?
The naming issue will be very confusing. Waiting a month or 2 won't kill anyone and will allow it to settle in.
Read http://pim.kde.org/development/meetings/20040102/release.php (especially "Versioning scheme for separate kdepim release").
Also we are talking about 4-5 month, not about 1 or 2 month.
Why not 3.2b ?
> Also we are talking about 4-5 month, not about 1 or 2 month.
So why not wait some more and release it with kde 3.3?
btw, a shorter release-cycle for kde, about 6-9 month, would be nice!
One year is soooooooo long...
KE should have a release cycle no longer than 6-7 months for intermediate releases. Only big point releases like 4.0 should take a year.
We don't want to release in 6-9 months and KDE 3.2 is still not released after almost 12 months. Currently nobody knows when KDE 3.3 will be released (if ever because maybe we directly go for KDE 4.0).
Then why not 3.2.01? Then when KDE 3.2.1 is released kdepim can still release 3.2.1 which will just be a more stable 3.2.01 and wont confuse people. Besides there is nothing more fun then a very minor version bump that has major functionality. It is like winning free stuff for a user.
You mean winning free bugs, don't you?
My opinion is that KDE 3.3 will turn into KDE 4 like you suggest, so I agree it probably won't be a problem. It could still be confusing anyway, but I guess your reasoning makes sense. As long as people realize it could be a problem, that's fine.
I'm glad knode will be integrated. I would love to be able to mix and match my mail folders and news folders. Even if this is not in this release, it will likely push it towards that capability.
I just got an iPaq. I've been kicking around trying to get it to sync (I don't own a Windows machine - just various *nix). Raki, the KDE sync tool for SynCE almost works, but it would be ideal if it was built right into KDE PIM. Any idea if there has been any work on syncing Windows PocketPCs?
If there hasn't, I'm likely going to be installing Linux on it soon... :)
I'm also a owner of a Windows Mobile 2003 pocket pc (Dell Axim X5).
There is only one f#cking need, to keep windows xp running on my system!
I need MS Outlook to sync my:
Emails,
Calender,
Todo
and Notes
with Palm.
Okay, I also use the mobile favorites (which are setup via Internet Explorere) and Avantgo (a port of avantgo would also be nice!)
Is there any plan or at least motivations, to integrate Pocket PCs also into KDEPIM ?
same here, the only reason i have a windoze box now is to sync my pocketpc that i use all day long at work :)
i've yet to get it to sync with my fedora core 4 box
- jim
if anyone succeeds, please email me!
Can I upload my KOrganizer schedule/calender to KPilot to my Palm and vice versa?
Yes, with kpilot, were you can active and configure the KO rganizer Calendar and Todo conduits. It's working fine with me.
I got to know that a parallel event, the LinuxInfoTage(?) in Wilhelmshafen will be videoconferencing with Chemnitz.
Can someone tell me the differences between Kolab & Kroupware ?
What about Kontact & KDEPIM ?
These apps look the same to me, but have different websites. If they ARE the same, why have different name ?
Kolab is the new name for Kroupware since it was criticized before. KDEPIM is the respective module in KDE CVS which includes all the PIM applications like KMail, Korganizer etc. and Kontact. Kontact is a shell integrating many of the stand alone PIM applications.
Kroupware was the name for work done under a (now finished) contract
by Intevation, Erfrakon and Klarälvdalens Datakonsult.
Kolab is the Free Software project which came out of it.
It has a server and a client component.
Some KDE's PIM applications can act as a Kolab Client.
Kolab is the groupware server. Kroupware was the name of the project to write a KDE client for Kolab based on the existing applications from the kdepim CVS module (KMail, KOrganizer, KAddressBook). The result of this project is in the kroupware_branch in CVS. It never got released as part of KDE.
With KDE 3.2 kdepim will include Kontact which integrates KMail, KOrganizer, KAddressBook and more into a single application. In the next release Kontact will include the Kolab client functionality.
Kolab is the name of the Free Software project.
There are implementations of the server and clients.
Kontact will become the KDE Kolab Client.
Get it while its HOT :)
Really liked the new KOffice icons