GNOME.org
 

Re: [Evolution] Proposal: Evolution Attachment UI

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".


  - 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.


  - 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)


  - 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.

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.




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.


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.




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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]