On Fri, 2005-06-03 at 14:21 -0600, Srinivasa Ragavan wrote:
> > 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
>
> why? and according to your explanation below, you actually don't intend
> to do this fully anyway. so I fail to see why we're even considering
> changing anything if we're still going to have to have buttons
> "sometimes".
>
Fejj, lemme re-correct. Im trying to place icons for buttons for each
attachment. That doesnt means that i shouldnt have "HIDE or '__' " button on
top of the preview to hide the inline view. Im trying to depict each attachment
as a icon, instead of being placed as button.
> > - Make "Save All Attachments" easier to access
>
> this is quite possibly the only thing I've ever heard people complain
> about with the current UI and solving this doesn't depend on an icon
> list.
>
> > - Keep inline display of Images, text/patches, vcards, appointments
>
> if all these will be displayed inline and they will still have buttons,
> what then, have we really solved? You certainly haven't solved the first
> item you listed. all you've done is to add more clutter.
>
fejj, what im meaning is they are not placed as buttons. They are placed as
icons. But you have a hide or '_" button on top of the inline view to hide it.
Hope im clear.
> > - Scale down images to fit within the display area better
>
> sure, but this doesn't depend on an icon-list (in fact quite the
> opposite)
>
Agreed :-)
> > - 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 :)
>
> why not start with what we have currently and solve whatever issues
> exist against that instead of coming up with a whole ne UI where we
> wander into no-man's land with no idea how many problems we'll end up
> having?
>
> the current solution can't be that bad, I rarely ever see anyone
> complain about it.
>
> >
> > > >
> > > > 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.
>
> seems a rather unintuitive approach...
>
> >
> > 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.
>
> *shrug* I guess. honestly though, I really don't see this UI scaling
> very well at all if there are more than 4 or 5 mime parts in the
> message. it certainly won't scale to much more than that.
>
> I dont think it would be difficult. The user can use the scroll bar.
with your solution, users would have to manually map which icons control
> which sections of the message in the display and if some of them aren't
> actually displayed in the gtkhtml display area, it just makes it even
> more confusing.
>
> >
> > > 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.
> >
>
> seems rather cumbersome.
>
> > > 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.
>
> why don't you try it? my point is that you can't accurately depict how
> things were signed together in your proposal. the best you could do
> would be to pretend each icon in the icon-list was signed individually
> and give it a good/bad status but this loses information.
>
> >
> Thx fejj, i learnt a few on this. Fine, i agree with you, i can show only the
> status of the signature. But the grouping info may be lost, but we can think
> of a way to implement it.
Fejj, thanks to your comments, i was looking at how Mac displays attachments.
They too display attachments as icons. But put them in a tree view model. Like
Attachments:
ABC.TXT
> Message Attachment1
v Message Attachment2
xyz.txt
xyz.txt
All of them show as a typical icon with names at the bottom.
Are you suggesting something like that. It solves most of the problems that you
were conveying me :-).
> > 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.
>
> I suggest you try it.
>
Hmm Nice, for a encrypted mail, if i dont give the passphrase to decrypt, it
displays 2 attachments
1. the signature
2. encrypted message.
It couldbe difficult to convey which sign makes to what message.
But the above tree view sort can do it?
> > > 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?
>
> my suggestion to you would be to test some of these things out in
> evolution so that you have a clear understanding of how things work now.
>
> but yes, what you'd see i some text, under that would be a button with a
> description next to it describing what the part is, and then followed by
> the second block of text.
>
> > If thatz so i agree its a loss.
>
> indeed.
>
> > 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
>
> but it's not really an unknown mime type, it's simply one we don't
> support displaying inline as there has not yet been a renderer
> implemented for it. that said, I suppose using some placeholder image in
> the gtkhtml rendering of the message could suffice.
>
>
Sorry i conveyed wrong. What i meant was a icon to convey that cant show
inline. But wrongly phrased it :-(.
>
> > > 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.
>
>
> Jeff
>
>
-Srini.
_______________________________________________
> evolution maillist - [email protected]
> http://lists.ximian.com/mailman/listinfo/evolution
_______________________________________________
evolution maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/evolution
