On Mon, 2004-09-13 at 12:35 -0700, Eric Ewanco wrote:
> --- Jeffrey Stedfast <fejj ximian com> wrote:
>
> > the rationale is:
> >
> > - if it's not sent by you, then you shouldn't be
> > editing it
>
> Hmmm. Ok, I'm trying to understand the concerns here.
> Now, obviously, you'd want to use the (new) sender's
> outgoing address -- we are not talking about forging a
> message. What we're basically talking about is like
> an inline forward, only without including the headers,
> and with the destination filled in with the original
> destination (and no "[Fwd:]" prepended to the
> subject). You can accomplish mostly the same thing by
> dropping a copy of the message into the Drafts folder
> and bringing it up, or cut and pasting (and
> saving/reattaching the attachments) (although the
> latter may lose formatting).
> Would you have an objection to doing any of these
> things as well? I guess I'm still not understanding
> why it is "wrong" to use a message you've received
> from someone else as a template for a new message,
> especially when it's not hard to do without "Edit As
> New", just more inconvenient.
this is what "Redirect" is for.
>
> > - evolution's composer is not capable of handling
> > all mime structures
> > (it's an impossible task)
>
> Ok, that sounds like a fairly compelling reason. I
> can understand that someone might have decided a while
> ago, "We don't have the resources to handle this
> properly in all cases, therefore we will only edit
> messages which we composed" (although, there is the
> hole of copying a message to the drafts folder).
>
> Maybe I just need to make sure Evolution gracefully
> ignores mime types it can't handle.
*sigh*. it has nothing to do with mime-types and everything to do with
structure
Evolution's composer can only create the following structures:
text/plain
multipart/alternative
text/plain
text/html
multipart/mixed
text/plain
application/octet-stream
...
multipart/mixed
multipart/alternative
text/plain
text/html
application/octet-stream
...
it can also generate any of the above 4 wrapped inside
multipart/encrypted and/or multipart/signed
however, it cannot represent (for example):
multipart/mixed
multipart/alternative
text/plain
text/html
multipart/mixed
multipart/mixed
text/x-patch
application/octet-stream
image/png
multipart/signed
multipart/mixed
text/plain
message/rfc822
application/pgp-signature
are you starting to grasp what I mean?
Evolution's composer can pretty much only handle:
- a message body
- attachments
- with the option to sign/encrypt only the entire message
it cannot handle nested multiparts (with the exception of the few cases
listed above)
>
> > also, there exists an option
> > Actions->Forward->Redirect for at least
> > some of the needs you brought up.
>
> Yeah but it won't let you change it, which, in many
> cases, is the whole point.
I feel you are approaching this problem from the wrong direction then.
this is precisely what the Drafts/Templates (not-yet-implemented)
folders are for.
I suggest you implement Template folders instead.
Jeff
--
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature