[Kde-pim] Mailreader status and RFC

[Volker Krause]

On Thursday 10 September 2009 12:48:46 Thomas McGuire wrote:
> On Thursday 10 September 2009 10:12:13 you wrote:
> >  in the past weeks I extracted the code from KMail that shown a message
> > in a widget and moved it in its own lib. This will enable using the same
> > mail rendering widget in different PIM applications. The code was also
> > ported from mimelib to KMime and it is Akonadi enabled, in a sense that
> > it can show right a way the content of an akonadi item, if that item is
> > a mail message. The code is in the branches/work/akonadi-
> > ports/kdepim/libmailreader branch.
> >  Although not perfect yet, and with some FIXME and TODO's here and there
> > (mostly related to on-demand loading of attachment and context menus of
> > attachments in the mail header), I think it is time to decide the next
> > step. Decision that  I don't want to make alone. :)
> >
> > 1) Where to put the code? The possibilites are: libkdepim, kdepimlibs or
> > remains where it is in kdepim. I think the best would be to move to
> > kdepimlibs in mid-term, but see 2).
>
> This question is also relevant for the other parts ripped out of KMail,
> like the message composer, the message list and eventually the template
> stuff. The message composer is generic enough to be useful for other
> applications and can therefore be moved to kdepimlibs, while the message
> list and the template stuff are too specific.
> I am not sure about the mailreader. Tom, do you think it would be useful
> for Mailody?
>
> About the other components which got ripped out of KMail: I'd like to see
> some cleanups in the directory structure at some point. The kdepim
> directory is now filled with stuff, IMHO we should have:
>
> kdepim
>   apps
>     kmail
>     kaddressbook
>     ...
>   libs
>     libkdepim (we could rename that to libpimdumpingground ;)
>     libkleo
>     mail
>       libmessagelist
>       libtemplate
>       libmailreader (or in kdepimlibs?)
>       etc

Don't forget the runtime folder, which makes the libs part a bit more 
tricky...

Personally, I don't like deep folder structures much since it reuqires that I 
know where stuff is (which is not always unambiguous), especially with stuff 
I don't look at every day (eg. in kdelibs or Qt). However, since I'm using 
KDevelop most of the time nowaday and its quickopen feature finds the stuff 
whereever it is, I don't care much anymore.

> The very big downside of this is that it makes merging a nightmare, maybe
> Git can improve this?

Unless we have Git and have confirmed that it solves our problem I would use 
the following rules for moving/renaming:
- do it ASAP for new stuff before it even is in more than one branch
- wait for a minimal active branch count (that is branches the affected 
component is actively changed in, ideally there is only one) for existing 
stuff, that especially means here to wait until akonadi-ports has been merged

> Also, some stuff of the mailreader has to be used by other libs/apps, like
> the objecttreeparser, which is needed in various places in KMail, and the
> stringutils functions.
> Any idea what to do with those two? Dump to libkdepim? Keep in
> libmailreader, but make it public? Dump to libs/mail as discussed above?
>
> > 2) The code is GPL licensed as it mostly comes from KMail. This means we
> > cannot move to kdepimlibs as it is. Do you think it makes sense to hunt
> > for the authors and ask for relicensing? Luckily many of them are still
> > active contributors (even if not coding, they are around KDE). There are
> > some persons I don't know personally though: Patrick Audley, Stefan
> > Taferner, Markus Wuebben .
>
> I think the decision was to allow GPL licensed code in kdepimlibs, as
> eventually we might want to move libkleo there. The mailreader even depends
> on libkleo. Re-licensing libkleo to LGPL was not an option, therefore
> mailreader has to be GPL too.

That is not entirely correct, KDE has been LGPL while Qt was GPL, so libkleo 
is not blocking mailviewer from becoming LGPL. Of course that doesn't change 
much in the end for the applications using it, it still has to be GPL 
compatible.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090911/03c0663d/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/