On Thursday, 5 June 2014 08:39:58 CEST, Kevin Krammer wrote:
class Composer : public QObject { Q_OBJECT Q_PROPERTY(QString identity ....) Q_PROPERTY(ReceiverModel toModel .... CONSTANT) Q_PROPERTY(ReceiverModel ccModel .... CONSTANT) Q_PROPERTY(ReceiverModel bccModel ... CONSTANT) Q_PROPERTY(QString subject ....) Q_PROPERTY(QString body ....) Q_PROPERTY(AttachmentModel attachmentModel .... CONSTANT)public Q_SLOTS: void send(); void sendLater(); void saveAsDraft(); };
I think that this is a good idea, in general. The current MessageComposer is mainly tasked with producing full MIME messages based on some input data. Perhaps it would make sense to split the parts which operate on message headers into a standalone component. I'll think about that, thanks for this food for thought. As a nice added bonus, if this message building is properly split, then it would be even easier to add support for message bouncing/redirecting -- simply feed the submission engine another "content provider" and be done with it.
One thing which I'm unsure about is splitting the concept of recipients into three parts (To, Cc, Bcc). Maybe it would make more sense to use a two-column model, first column tracking the type of the recipient (to/cc/bcc), the other column storing the addresses. This might seem unintuitive at first; this order is not preserved during the MIME serialization, after all. However, it's how the DesktopGui works right now. Other UIs might present separate widgets (i.e. one for the To block, other one for the Cc block etc), but the DesktopGui shows just a single grid and user is free to mix the order in any way she wishes. And if there is just that single model, we can (and should) always offer proxies which would just simply publish all recipients of a particular type, and upon insert simply add them to the end of the list within the source model.
Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
