[Kde-pim] Mailreader status and RFC

[Ingo Klöcker]

On Friday 11 September 2009, Volker Krause wrote:
> On Thursday 10 September 2009 10:12:13 Andras Mantia wrote:
> > 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.

IMO MailViewer is way to generic as namespace. I suggest KDE::PIM::Mail. 
This namespace could/should also be used for other classes related to 
mail, e.g. the composer classes.

Furthermore, I suggest to call the main class MessageViewer instead of 
MailViewer (just as MessageComposer) since it's a viewer for a single 
message and not a viewer for all my mail. The library would then be 
called libmessageviewer.


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

I disagree. Maybe view message source fits in the library. But "save a 
message" really doesn't belong in a message viewer class.


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

That's the only solution that makes sense. The user of the library will 
have a bit more work, but he gains full flexibility.


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

Hmm, if anything then the third solution should just be added in 
addition to the second solution for the (lazy) users that do not need 
the flexibility of the second solution.


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

"might" is an understatement. IMHO the message viewer must not know 
anything about selected messages. His only concern is the single 
message he is viewing.


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

Yeah, that's definitely a better solution.


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

Hmm. Does the "MIME tree view" still exist? If yes, then I hope it's not 
part of the message viewer. If it's not part of the message viewer, 
then we are in the same situation as above with message viewer and 
message list. Also in the "MIME tree view" one can select multiple 
attachments. So I'd prefer to use a similar approach as the one Volker 
described above for the message-specific actions.


Regards,
Ingo
-------------- 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/20090911/7c071b87/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/