It has been a long time dream of theKDE PIM team to be able to integrate the different PIM applications into one common interface shell that would permit the creation of an Outlook-like application and provide a fully integrated personal information management system. Development of such an application is in fact rapidly picking up steam. In particular, theKroupware Project, part of a full-blown open-source groupware solution for KDE and commissioned by the German government, was pre-announced and has already generated a flow of ideas and code. Karl-Heinz Zimmer showed a prototype of KOrganizer embedded in KMail:kroupware1,kroupware2.

But Don Sanders, KMail hacker, went one step further. He managed to transform KMail into a KPart and demonstrated how the different PIM components can be embedded in the pre-existing framework by Matthias Hoelzer-Kluepfel and Daniel Molkentin known as Kaplan:kaplan1,kaplan2,kaplan3.
Great work that proves, once again, that the KPart architecture is sound and gives tangible results. Expect the first official results of the Kroupware project on October 15th.

Comments

Please, please, please let us users choose how we want our windows. KNode lets you do this and it is great.

I want to have my message window tall (as high as the screen) and the folder-list and the message-list on a side.

Since most lines are wrapped at 80 characters, this is the only layout that makes sense to me. Having an Outlook-like wide message window that is always half-empty is not efficient. KNode features these "sub-windows" which can be arranged how you like it, if Kaplan will support this, this feature alone will put it far ahead of current KMail.

I was worried when I looked over Kroupware, as I'm working on a non-folder based alternate email/messaging/contact application for KDE. It would plug into Kaplan quite nicely (or run as a seperate application), but Kroupware looks like you're locked into it's variant of KMail. Moving to a large monolithic application that does a whole bunch of stuff (like Outlook) prevents you from picking and choosing components - your favorite addressbook with your favorite email application.

(As an aside: Yeah - that's right, non-folder based. But not flat. It's a relational message database with a novel (I think) UI that is pretty nifty. No clue if I can climb it up to version 1.0, right now I have pages of notes, a KWord document full of documentation, and a dozen PyQt files that semi-work as a bad text editor that saves to a mailbox format, and makes little icons of people pop up when I create files. :) If you're interested in discussing some interesting alternative concepts about how to build a communication interface, which I've dubbed KIM (KDE Integrated Messaging), feel free to email me. I'm hoping it might debut around the time KDE 4.0 is released).

--
Evan (been awake over 24 hours now - please excuse any run on or fragment sentences - now, back to work).

This is wonderful! The german government is doing a great service to Open Source by funding the Kroupware/Kolab project like this. Fingers crossed till Oct 15. This is a greatly compressed schedule, and if they pull it off, it will be thanks to the pre-existing work of the KDE project. Everybody wins.

actually 1.0 is just about ready, we took a few months off to port it to the Sharp Zaurus and that project is in final beta. It uses some really cool technology to deal with plug ins and components in a multi-platform fashion, which I understand is a goal of kroupware (croup by the way means horses ass or bad cough, both are valid definitions. The word comes from the French actually which in turn is based on old German). I don't know why no one wanted to talk to us, we've put forward this proposal many times, oh well.

Since it looks like they want the final product to be native to KDE, I image they want to use KParts for components. Maybe there would even be some interest in using your component model as well. The ability to use a KPart as an Athera component or vice-versa could be a useful addition to both projects I would think.

Aethera use to use KParts, but those weren't multi-platform, which is the same problem that Kroupware is going to run in to. We switched to TINO (our OLE type tool) to replace it, and that is multi-platform and lightweight.

The CVS is open only for people who really want to develop (help) the Aethera project. Since the project is pretty big I want to be carefull with the code.
I am opened for anyone who wants to help, I will give him a CVS access and lot of info about the design.
My email is: eug@thekompany.com

Hey. KDE should learn from the GNOME project and assign a kick ass name to the project *first*. And when I say *first*, I mean before any code has been written down at all. Seriously. Eliminate these half-assed temporary names! ;-)

The problem is that when the project fails you have one name less to chose.. and it is always emberassing to donate even more vapourware to the world. But the Gnome have some experience with this as well...

Of course, it's pretty much a given that the kind of people who use terms like Winblows, Linsucks and MSTurd (instead of MSWord), will immediately dub it Foreskin. Ah, the 3rd grade potty humor that has become accepted practice on the net. What a planet. :)

Great idea. This name sounds a lot more professional than the ones with a "K" inside. Maybe the KDE team will get sued by K-Mart if it continues to use this letter in the names of their applications...

I don't see why the letter K should be avoided. Many programs for KDE start with a K and many programs for Gnome start with a G. Users can easily identify the origin of a program along these lines.

I'd like to see a word that is present in many languages, has the same or an equal meaning in those languages and expresses a concept related to the program. Since most european languages share a lot of latinisms, I think the most obvious denominator should be a word derived from latin.

Which brings me to my proposal. How about "Koalition"? It seems that the meaning is about equal in german, english, french, spanish and a few other languages. The meaning, according to my ethymological dictionary, coming from late-latin (coalitus), new-english (coalition) and french (coalition), is "union, unification" and goes back to latin (coalescere, coalitum) where it meant "to unite, to grow together". While it used to be a chemical terminus (< 18th century), it was soon adopted in international relations (mostly a coalition _against_ somebody or something). In modern german it means "alliance within a government" (hope I translated that one about right).

Since the purpose of a groupware is to work together, the meaning (grow together) is not far from the purpose. It is some sort of coalition against the established closed source groupware solutions, so in this respect it is equally descriptive. And since it is contract work for the government the modern meaning is also there.

True.... exactly! The user should get an informative and pleasing name, and the packages could be whatever. The only problem with that is... should the user know the package name too? (For reasons like: support calls, download updates, etc.) If so, then does it help much? I'm not sure, but I think so.

But, I still think it is worthwhile to please the user a little better than we're doing now. Konqueror or Kontour can come across as a miss-spelling and an annoyance to english-speaking purists. K-mail & K-word, though, may not be as bad because its obviously branding like MS Word, or whatever.

So... my thought was totally in agreement with yours. If the K-menu had a hook to the language-preferences, such that what you see is the "whatever program name" for your language it would be a lot easier to get names that please people. But the package name is what it is: K-mail, or Konqueror or whatever.

Stof, you're an idiot and a troll who never dies. GNOME2 stole this tactic from KDE. KDE has been displaying the generic name in the menu *forever*. Matthias Ettrich was the first to suggest this from the very beginning.