[Kde-pim] Mailreader status and RFC

[Andras Mantia]

Hi all,

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

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

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.

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?

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

Thanks for reading,
Andras


-------------- 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/20090910/71d0b27d/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/