[Kde-pim] Extracting some code from KMail into a lib

[Thomas McGuire]

Hi Andras,

why not make MailCommon a singleton and let KMKernel be a subclass of it? That 
way, you could avoid passing it around all the time.
Otherwise I'm ok with this.

Regards,
Thomas

On Thursday 23 September 2010 12:20:21 Andras Mantia wrote:
>  last week I asked about ExpiryPropertiesDialog relicensing for moving
> it to kdepimlibs. If that'd be that easy... After getting the approvals
> (thanks to everyone!), I looked more into the job and I wasn't happy.
> The code depends on a lot of other KMail classes and most of them
> depended on KMMainWidget, KMKernel, KMCommands. It still felt wrong to
> me that I need to reimplement the same functionality again in mobile, so
> I started to reduce the dependcy of the needed classes on the above.
> I did some commits doing it, incremental refactoring, but last night I
> realized this is also not perfect, classes started to have big
> constructors with many arguments.
>  So I came up with a solution: move parts of KMKernel out of it into a
> separate class that is passed around instead of many other classes. I
> named this class MailCommon (better names are welcome).
> When KMKernel is created, it also creates a MailCommon class that has
> setters and getters. In KMail desktop it is actually and interface
> towards KMKernel internals, while in mobile it will be an interface
> towards the mobile version internals (there we don't have a global
> object like KMKernel).
>  The drawback of this refactoring is the need of passing the MailCommon
> object in contructors instead of just doing a
> KMKernel::self()->something() call, but it will allow us to create a
> shared lib between mobile and desktop.
>  Before comitting, I'd like to get some formal approval. If you don't
> like what I did at all, I will also revert my previous commits from
> yesterday (sorry for not asking for approval, I hoped it will be less
> invasive what I had to do).
>  I tested and seems that everything is still OK, after all this is why I
> did the refactoring in several steps. The job is not completely done,
> and I moved to MailCommon only what I needed ATM (some more things might
> be moved there). It is also not kdepimlibs ready, I imagine that the lib
> in short/mid term will be like messageviewer is inside kdepim. I also
> need to get rid of KMCommands in the ExpireJob, probably by using the
> akonadi standard mail action manager for the jobs.
>  Sorry also for not using the reviewboard it gave an 503 error when I
> tried to upload the diff.
> 
> Andras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100923/9386ba6b/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/