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. _______________________________________________ evolution maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution
