On Tuesday, 5 August 2014 19:45:19 CEST, Karan Luthra wrote:
I like this hack because it re-uses GUI code, and allows
creation of the redirection widget to be grouped with creation
of composer widget for other purposes (new, draft, reply,
forward, etc). But let me know if this is a bad way to go about
it.
IMHO these three parts should be reused for the redirection dialog:
- sender/from handling,
- recipients list,
- the logic which takes care about the submission process and its GUI
visualization
Also, if I stick with this approach, then I will have to
differentiate the functionality of send() for the redirection
case from the normal behaviour of send().
The actual problem is in ComposeWidget::buildMessageData where the code
passes stuff to the underlying MessageComposer.
The "redirect message" or "resent message" is a special feature; its
purpose is to "forward" the message as-is, with no modifications but those
specified in http://tools.ietf.org/html/rfc5322#section-3.6.6 . This means
that the current MessageComposer is not quite up to this task. The purpose
of the MessageComposer is to *build* a MIME message; that's, however, a
task which is no longer needed when resending an existing message. Apart
from this message building, that class is also used in a "read-only manner"
by the Submission class for determining what to send, i.e. after the
MessageComposer is done with what it's doing, the resulting data is queried
for by the Submission and used as-is.
I think that a best way forward is making this difference obvious. Let's
prepare an abstract class Composer::MessageData defining this read-only
API. The let the MessageComposer implement that interface. Also create
another class implementing this Composer::MessageData, for example a
RedirectedMessageComposer.
Before you do this, note that right now the MessageComposer is instantiated
by the Submission, and that the ComposeWidget calls the
Submission::composer() quite a lot. This should be changed; let the
Submission's constructor require a MessageComposer* passed from outside,
and change the ComposeWidget's code so that it asks its own copy of that
pointer whenever it previously called m_submission->composer(). This is
needed because the Submission's composer will be any subclass which
implements that new Composer::MessageData interface, while the
ComposeWidget will still need an instance of MessageComposer.
So when this is all done, there's still a ComposeWidget which is limited to
working with (an equivalent of) MessageComposer, i.e. it still cannot use
the new RedirectingMessageComposer. There are multiple ways to fix this.
The first possibility is also refactoring the ComposeWidget by separating
out handling of sender and recipients to another file. I like this idea,
but it isn't all. If you go this route, it means that there will be another
QWidget subclass encapuslating the From label/combo and the to/cc/...
recipients list. This new class will then be used by the (new)
ResendMessageWidget. The ResendMessageWidget would still have to
reimplement bits like askForPassword(), send() etc.
The second option is hacking the ComposeWidget to work in two modes --
first one as-is, and the second one for message redirection. If you go this
route, the logic will become more complicated as you now have to
distinguish between calling the existing buildMessageData (in case this is
a newly-composed message) and a new function such as
buildResentMessageData, which will have to reference the new
RedirectingMessageComposer.
Which one do you like? Which one would be better for Trojita, long-term?
Either way, I think that doing the refactoring of the recipient handling
into another widget makes sense. Would you like to do it?
Finally, the recipients should change from the usual To/Cc/Bcc to include
the "Resent-" prefixes, IMHO.
This is all that I have right now.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
