[Kde-pim] Mailreader status and RFC

[Volker Krause]

On Thursday 10 September 2009 10:12:13 Andras Mantia 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.

nice work :)

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

libkdepim has to die, we should not put new stuff in there IMHO. Without a 
user outside of kdepim I would keep it where it is for now. There are quite 
some ideas for extensive changes to it, such as an acutally useful BPF plugin 
interface or even a port to Grantlee. Doing that in a BC way is next to 
impossible.

There is another possible approach for sharing it though: Make it a KPart. 
Would also enable us to view email messages in konqueror etc.

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

As the others already pointed out, GPL is fine.

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

MailViewer sounds good to me.

> 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 problem I see there is that most of the message-specific actions are not 
only used in the viewer, but also in eg. the header list context menu, ie. in 
other parts of the application as well. The mail viewer might not even know 
which messages are selected there.

Of course, sharing actions makes a lot of sense. An approach like 
Akonadi::StandardActionManager might be better here, ie. making the actions 
independent of the actual view and just operate on selection models.

Attachment-specific actions are different though, they aren't used anywhere 
else, so having them created by the mail viewer should be ok.

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

Right, porting KMail is the next step now, now that we have its main viewer 
components extracted and ported to Akonadi/KMime.

We should maybe talk about the approach for that a bit while we are at it, we 
see two options so far:
- port KMail "in-place" by #ifdef'ing it until it builds with the new 
component and then enable and port piece by piece
- rebuild KMail based on eg. the Akonadi mailreader demo by copying in and 
porting feature by feature 

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/a5e593b0/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/