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

List:       kde-pim
Subject:    Re: [Kde-pim] Kaplan: The road ahead
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-09-19 8:51:45
[Download RAW message or body]

On Thursday 19 September 2002 10:41, Don Sanders wrote:
> 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.

Ok, these problems can be fixed, I suppose.

> Embedded apps need to use their normal rc files and their normal app
> data directories.

Perhaps we have to separate some config files. Some information is different 
for the Kaplan part and the stand-alone app, e.g. settings for the screen 
geometry and splitter settings.

> These are the things I would like to work on.

Great.

> 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.

That's right. We could introduce a KPimPart directly inherited from KPart 
which doesn't provide the document centric functions. Or we just don't use 
the document centric functions where it doesn't make sense.

For Korganizer e.g. a real ReadWrite part makes some sense, because you could 
have a real document in form of a iCalendar file. But if Korganizer uses a 
different backend for storing its data, it still makes sense to have a part 
providing all the actions that a ReadWrite part provides.

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

Yes. This automatically enables the same degree of integration when the apps 
are run stand-alone anf not within Kaplan.

> 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.

Wouldn't it be possible to use the new DCOPRef stuff Matthias posted on 
kde-core-devel a while ago? Then we wouldn't need the stubs anymore.

-- 
Cornelius Schumacher <schumacher@kde.org>

_______________________________________________
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]