Re: [Evolution] Proposal: Evolution Attachment UI

["Srinivasa Ragavan" <sragavan novell com>]

Fejj,

My replies are below.
dobey:  probably you can add in your thoughts, and point out 
things to the rit direction.

On Sat, 2005-06-04 at 01:16 +0530, Srinivasa Ragavan wrote:
On Fri, 2005-06-03 at 12:02 -0600, Srinivasa Ragavan wrote:
> > fejj,
> >
> > First let me clear one thing.
> > Im not trying to solve."inline attachment proposal".
>
> I know.
>
> > What i meant was 'a proposal for UI Attachment', continuing the
> discussions from the proposals from dobey.
>
> by definition, your proposal must be trying to solve a problem. if the
> changes you propose are not meant to solve a problem, then why change
> anything? :)
>
> you can't solve a problem without first defining what the problem is.
>
> :-). Fejj, i defined the problem i gueess. One of the main objective is to replace the buttons with a 
> better approach. To explain that only i said i continue from dobey's proposal.

> > Im wasnt discussing about "Content-Disposition: inline" in this mail.
> > Im discussing about files, that are attached. 
>
> I don't think you understand MIME.
>
> Fejj, Its possible that im not understanding it fully. Im not a mailer expert. But what im trying to say, 
> is, what you display as a button, it tries to put as a button. If you remeber the intial proposal from 
> dobey it said that keep the inline display of images, text, patches, vcards, apppointments. Just keep them 
> inline and rest post as attachments in the attachment area.

Quoting it from a earlier mail.

"Display
  - Use attachment icon list area for display instead of buttons
  - Make "Save All Attachments" easier to access
  - Keep inline display of Images, text/patches, vcards, appointments
  - Scale down images to fit within the display area better
  - Add slideshow support (Mail.app in Tiger has this)"

> > What you have specified is one specifc problem, that if the two
> attachments in that case has same name. We can look at that case
> specifcally.
>
> the case I listed is just scratching the surface. there are likely
> numerous problems with the flat list approach.
Sure we'll try solve them :)

> > I agree that i could be confusing to put two files with same name. But
> how many ocassion is that scenario gonna occur. We can have a work
> around to have a string/some context info appended to the file name for
> display purpose or something else to avoid the confusion. I have
> specially spoken about the similiar scenarios, but not assumed the same
> file name every where.
> > I feel it may not be worth to ignore this idea, for a problem that of
> how to display what if we have two attachments of same name.
>
> but that's not the only problem.
>
>
> allow me to list a few more problems:
>
> Lemme try answer them.

1. what qualifies a part to be displayed in the icon list rather than
> the gtkhtml message display if not the Content-Disposition?
>
> Every single attachment will be in attachment area. Some of them will be shown if inline, with a hide 
> option to hide it. The attachment bar icon knows that if the image/text is inline, of course you can hide 
> it either by hiding it from the display or the attachment bar. 

Please correct me if my understanding is wrong.

2. for parts shown inline in the mail-display (lets pretend that we've
> already established a means for qualifying what MIME parts are shown
> inline and which are shown in the icon list; which, afaict, has not
> actually yet been established), how will a user save said part? or hide
> said part? If there's no button, then you are removing current
> functionality.
>
> The user can ofcourse save it from the attachment area. Hide/view from the same place.

3. for any part that ends up in the icon-list through whatever
> preconceived qualifications, how would a user request that they be shown
> inline? what would happen when they did? would the icon be removed from
> the list? how would it be shown in the message? the user won't know
> where in the message they'd appear, etc etc etc.
>
> The icon will be there, with the state being marked shown. So ofcourse you can hide it from there.

4. when message parts are signed, how would this be presented to the
> user? Remember that multiparts can also be signed, not just leaf-node
> mime parts. if we have the following:
>
> multipart/mixed
>  text/plain
>  multipart/signed
>    multipart/mixed
>      text/plain
>      image/jpeg
>      application/octet-stream
>    application/pgp-signature
>  multipart/signed
>    multipart/mixed
>      text/plain
>      audio/wav
>    application/pgp-signature
>  multipart/signed
>    video/mpeg
>    application/pgp-signature
>
> How would this be displayed? How would a user know which attachment was
> signed along with what else?
> Sorry, Im not sure, how evoltion handles/ displays this. If you could just explain me on this, i can tell 
> you clearly. Im not a expert here.

5. Encrypted mime parts... until a multipart/encrypted part is
> decrypted, we can't know what it contains. It may contain a single mime
> part or it may contain a multipart with any number of subparts (other
> messages and multiparts (possibly even signed or encrypted) included).
> How would this be handled?
> >
Could you explain how evo displays this. I can tell you how my proposal
can take care on this.

>
One of the great things about the way Evolution currently displays
> messages is that even in cases where Evo cannot render some mime-type
> inline in the display (yet) for whatever reason, the user can clearly
> see where the item was meant to appear. Take the following MIME snippet
> for example:
>
> Content-Type: multipart/mixed; boundary="foo"
>
> --foo
> Content-Type: text/plain
>
> Senator,
>
> ...our current battle plan for dealing with aformentioned problem is as
> follows:
> --foo
> Content-Type: application/x-sw-flash; name="deathstar.swf"
> Content-Description: reach out and touch someone
> Content-Disposition: inline; filename="deathstar.swf"
> Content-Transfer-Encoding: base64
>
> <base64 encoded blob>
> --foo
> Content-Type: text/plain
>
> ...as you can see, this method is quite effective.
>
> Yours truely,
>
> D.V.
> --foo--
>
>
> You'll note in the above example MIME structure that the user has used
> MIME to insert a shockwave flash animation between 2 parts of a text
> message. By displaying this mesage as 1 continuous block of text and
> moving the sw-flash attachment into an icon-list, you destroy the
> presentation of the original authors message. to me, this is
> unacceptable.
Sorry, again im dont know how evo displays this. Is it like it shows a button here, with these text? If thatz 
so i agree its a loss.
Pro'll ill try to think more on this aspect on . Probably we can think of a UNKNOWN MIME TYPE ICON as a place 
holder to be displayed instead of the actual shockwave display. Its just a thought.

However, the current Evo mail-display implementation would show the suer
> that the original author intended for there to be a sw-flash animation
> between the 2 text parts even tho Evolution is currently unable to
> actually render the sw-flash animation.
>
> This type of thing is very important to me.
>
> Jeff
I understand fejj, few things are more important. Thatz y i consult the ideas and try to get a best solution, 
to make things better.:-)

-Srini.