[Kde-pim] Mailreader status and RFC

[Thomas McGuire]

Hi,

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


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

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.
 
> 3) Decide about the name of the library. Now it is libmailreader, but I
> like libmailviewer better.  I even named the main class MailViewer. :) I
> think the main purpose is to show/render mails, not to read them (from
> akonadi).

I like libmailviewer better as well.
Or we could give it silly names like Avlekete, which is the sister-in-law of 
the goddess Akonadi, but I prefer not to do that :)
(The family of the goddess is big, we would have enough names for other 
components as well then, though)

> 4) Decide about the main class name and namespace. I removed all the
> KMail namespace it was used, and now the main class is MailViewer and
> the other public class is AttachmentStrategy (HeaderStrategy will
> follow). Suggestion/preference about the naming? Note that the main file
> name is kmreaderwin.*, I will rename as soon as we decide about the final
> name.

As written above, the objecttreeparser also needs to be public, but not 
necessarily in libmailreader.
I think the namespace should be the same as the name of the lib, e.g. 
MailViewer.

> 5) We have to decide how much functionality do we want in the viewer,
> mainly about the actions there. I think it is nice to have things like
> attachment showing, view mail source, save a mail, etc. there. The
> question is if we want to have default actions created in the library -
> so the library user doesn't need to anything, still V will show the
> message source - or we want just to have entry points (methods/slots) to
> the library and actions have to be created by the user of the lib.
> A third solution is to have the entry points and convenience methods,
> like "createViewSourceAction" that returns a KAction with the default
> shortcuts/icons connected to the corresponding slot (and gives away the
> ownership of the action). Suggestions?

For krichtextwidget in kdelibs, the user passes an actioncollection, and 
krichtextwidget simply creates and adds the actions to there. krichtextwidget 
has means to control which actions are created.
Not sure how to best handle context menus though, since the applications 
likely want to customize them, like the "Forward" action in KMail, which is 
KMail specific.
I think applications should build the context menu themselves, and 
libmailreader should provide getters for the common actions so they can be 
plugged in easily.

> The code still needs at least an API review and will probably need some
> additions to the public API once we start to port the applications to
> use it (which I'd like to see soon, as it is a pain to keep trunk kmail
> features in synch with the lib).

I think the next Akonadi meeting would be a good time to do an API review.

> Thanks for reading,
Thanks for coding :)

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090910/28e0f386/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/