[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [Patch] kmail template facility
From:       "Jonathan Marten" <jjm () keelhaul ! demon ! co ! uk>
Date:       2005-09-29 16:40:03
Message-ID: ovfyrnomjg.fsf () keelhaul ! local
[Download RAW message or body]

Many thanks Ingo for looking at the patch.  I'll certainly start to
adapt it for KDE 4 (I assume that it will not be eligible for KDE 3.5
or any further of the KDE 3 series, although I will probably update
the patch for that just so that it doesn't get too out of date).  I'll
get set up for developing from SVN as soon as kdepim is buildable...

Much of the code is straight copy-and-paste from the drafts
implementation, so please excuse any anomalies or needless
duplication.

Detailed comments below...


Ingo Klöcker <kloecker@kde.org> writes:
> I think something like
>
> File
> ->New Message from Template
>   ->some template
>     another template
>
> would be better than having to switch to the Templates folder in order 
> to create a new message from a template. But of course for editting 
> templates the above drafts-like functionality still makes sense.

Agreed; will keep the existing folder interface for managing
templates, and add a composer menu option listing all the available
templates.  Any opinions on what the double-click action on a template
message should be - edit the message as currently happens for drafts,
or compose a new message from that template?

>> A template can also be used to insert text into a message being
>> composed, via the 'Message - Insert Template Text' menu option.  This
>
> I'm not sure whether this is such a good idea because the user will 
> clutter his Template folder with two different types of things, namely 
> with message templates and with standard text blocks.

Accept that this may cause complication and confusion; still believe
that such a facility (to insert boilerplate text in the composer)
would be a useful facility, but I will consider other ways of
implementing it.

> Templates folder on the IMAP server will definitely be needed. I'm not 
> sure how useful identity specific templates folders are.

Noted;  will implement that.

>> I also haven't tested this facility with HTML 
>> messages, but see no reason why it shouldn't work...
>
> Famous last words. :-)

I must admit I'd never tested that, and it doesn't work!  Will address in update.

>> -- patch starts

>> +  newMsg->setStatus(msg->status());
>
> Why do you copy the status of the template?

Wasn't sure whether this was necessary, so copied from the drafts code.

>> +  KMComposeWin *win = new KMComposeWin();
>> +  msg->setTransferInProgress(false); // From here on on, the
>> composer owns the message. 
>
> The above line should be unnecessary.

Same reason as above.

>> +void KMComposeWin::doSend(int aSendNow, bool saveInDrafts, bool
>> saveInTemplates) {
>
> This code has changed quite a bit since KDE 3.4. It would really be 
> better if you'd develop against the development version. Also I don't 
> like the usage of another bool parameter. Using an enum would be much 
> better.

Agreed that would be the better solution for KDE 4; will do that.

> The below duplication of the equivalent code for drafts is not nice. 
> Please try to come up with a way to avoid the code duplication.

Will merge the two cases into a helper function.

> But as I already wrote above I don't like this 
> solution that much. I'd prefer a separate solution for inserting, 
> saving and managing text blocks.

Will remove this completely, and investigate a possible replacement.

>> +  mUseAction = new KAction( i18n("&Use Template"), "edit", Key_U,
>> this, 
>
> I think something like "New Message from Template" would be better.

No problem will that; will change the text.

> Since I don't think the Insert Template Text functionality is a good 
> solution I skipped the implementation of the template selection dialog. 
> If you take out this functionality and address the other issues I 
> raised then the patch will be included in the next version of KMail. 
> Please note, that you will most likely have to adapt your patch to Qt 4 
> since the next version of KMail will be based on Qt 4.

I will start work on that, and look forward eagerly to KDE 4!

Regards
  Jonathan

-- 
Jonathan Marten                           work:  currently looking
http://www.keelhaul.demon.co.uk/          play:  jjm@keelhaul.demon.co.uk
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel

[prev in list] [next in list] [prev in thread] [next in thread]