[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Kaplan: The road ahead
From:       Don Sanders <sanders () kde ! org>
Date:       2002-09-19 8:41:13
[Download RAW message or body]

I'm using Kaplan as my primary email client now and there are several 
things I see that need to be done.

When using KMail embedded in Kaplan.
Menu items are missing in the composer
Kaplan hangs when I attempt to cut text in the composer.
Kaplan needs a KMail like status bar with a mini progress bar in it.
Kaplan needs to be a KUniqueApp.
Embedded apps need to use their normal rc files and their normal app 
data directories.

These are the things I would like to work on.

more text follows...

On Thursday 19 September 2002 08:30, Cornelius Schumacher wrote:
> On Wednesday 18 September 2002 21:42, Daniel Molkentin wrote:
> > 1) Kaplans general design
> >
> > At the moment Kaplan bases on an abstraction through plugins,
> > that get loaded on startup and hold some information about the
> > Part to be loaded. I would prefer if we could get rid of this
> > cruft. All information we need can be put in header files AFAICS.
>
> I think the main point about Kaplan is that it achieves integration
> of PIM/Groupware apps without creating dependencies on each other
> in the application code and without sacrifying the ability to run
> them stand-alone.

I agree with Cornelius (IAWC)

> The plugin concept was inspired by the gideon. There might be
> better solutions, e.g. a special KPimPart derived form KPart
> providing the necessary infrastructure for communication between
> parts. But this doesn't matter much. As long as the tasks of
> integration is kept in the Kaplan framework and the task of
> providing the functionality is left to the application code we are
> on the safe side. Changing either of them will affect the other
> components.

IAWC

> Another important concept is that most communication is done via
> DCOP. This allows for both, interprocess communication between
> stand-alone apps and efficient in-process communication between
> KPart based components.

IAWC

> By doing the integration with plugins/Kparts and DCOP we minimise
> compile time dependencies, make use of the existent mechanisms to
> resolve run-time dependencies and cleanly separate the integration
> code from the actual functionality. This is a good thing and I'm
> happy to see that almost all of us agree on that.

IAWC

> > 2) Kaplans name
> >
> > I agree with you that Kaplan is not a real good name for a
> > consumer product. I agreed with Don to call it Kontact. We will
> > switch the name at some point but I consider other (design)
> > decitions to have precedence.
>
> I don't think that this is of any importance right now. Both names
> are fine, but currently we should concentrate on the code I think.

Not right now but later I would like to rename kaplan to kontact.

> > 4) Kroupware integration
> >
> > - Handling of incoming VCal Events and:
> > Cornelius should probably comment on that. Anyone?
>
> I still think that a plugin interface for filtering mime objects in
> KMail would be the right way to pass iMIP requests to KOrganizer.
> You register a plugin for the mime type text/calendar and when
> KMail sees a mail containing an object of this type it decodes it
> and passes the information to the plugin by native C++ calls. The
> plugin
> implementation (which could be anything from a simple program just
> passing the data to the iMIP incoming directory of KOrganizer to a
> full KOrganizer providing dialogs and preview) does the further
> processing.

No comment.

> Sending events from Korganizer to KMail via DCOP is fine with any
> way of integrating the programs.

Better than fine, preferred.

> And once again: It's not vCal events, it's iMIP, which is an
> implementation of iTIP using email as transport layer based on the
> iCalendar format. vCalendar is an old format which isn't used for
> group scheduling. There already have been confusions about the
> kroupware project using obsolete technology because of this, so
> please get the terms right.

No comment as I'm not educated in this field.

> > - The KOrganizer side:
> > Looks like we won't need to change too much, I am currently
> > trying to get kroupware_branch working to get an impression.
>
> KOrganizer has to provide all its actions in the KPart used by
> Kaplan. At the moment it only provides the actions needed for a
> read-only part. Kroupware creates the missing actions in the KMail
> code. This should be changed to be reuse the code within KOrganizer
> by making it a bit more modular.

First of all I've seen people talk about the need for RW KMail and 
KOrganizer KParts. But as far as I can tell the KPart RW concept is 
for saving a document like a word processor KPart would do. It 
doesn't make sense for KMail.

I agree that we need to extend the dcop interfaces of the various 
kaplan parts to allow what ever inter-part-communication is 
necessary.

We do have a problem in that kaplan needs to be able to find the kmail 
dcop interface stub, I would like to copy the interface stub into the 
kaplan directory for now (ie duplicate it), and later solve the 
problem by moving KMail (libkdenetwork and mimelib) into kde-pim.

> > - KAddressbook: Any strong feelings on the integration of the
> > addressbook (other than showing it?)
>
> Most integration work is alread done by using libkabc as common
> library. In adition to that we have drag&drop and some DCOP calls.
> In my opinion KAddressbook proves that the Kaplan concept really
> works. With almost no work we got it intgerated with the other apps
> in a way very similar to Outlook and its clones.
>
> > 5) Myself and my involvement.
> > I will again start to activlely develop on Kaplan. The Problem is
> > that university starts by the beginning of next month and I will
> > have to concentrate on that for the next time. I think we can
> > find an interim maintainer for that time. Just tell me if you
> > want to step in when the time comes...
>
> I'm tired of maintainer discussions. I vote for collective
> ownership of code. We have a common goal and if all involved people
> do their contributions in a responsible way there shouldn't be any
> problem.

I don't want to enter into another maintainership discussion now.

Don.

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]