Re: [Evolution-hackers] Attachment UI

[Not Zed <notzed ximian com>]

On Fri, 2005-07-01 at 09:29 +0530, Srinivasa Ragavan wrote:
> On Thu, 2005-06-30 at 22:15 +0800, Not Zed wrote:
> > On Wed, 2005-06-29 at 10:29 +0530, Srinivasa Ragavan wrote:
> > > Hey guys,
> > > 
> > > I have done some improvements to the attachment view and i have attached
> > > the screenshot of that. 
> > > 
> > > http://gnomebangalore.org/~sragavan/Screenshot-am1.png (unfolded view)
> > > http://gnomebangalore.org/~sragavan/Screenshot-am2.png (default view)
> > > 
> > > In a mime tree, it picks up the leaf parts that are pure attachments,
> > > and not data/txt/message.
> > 
> > How does it do this?  Does it pre-scan the message tree?  This wont
> > work; many parts can be synthesised during the message scan stage and
> > don't exist in the original message (inline content, encrypted parts,
> > etc).
> > It would need to hook into the attachment adding code somehow (i.e.
> > em-format-html-display.c:handle_attachment).
> 
> Notzed, i had two stuffs in mind, either go the save-attachments plug-in
> way and instead of tree view of all, just display the leaf to-be-shown
> parts in the bar. Other is exactly the way you say. I thought of adding
> it somewhere in format_attachment. But it has a dis adv that, the
> unexpanded mail's attachments cant be picked up. Anyway notzed, ill try

Every attachment goes through there - thats the code that adds the
expander ...

> hook somewhere to get the attachments. If you have some idea in mind,
> can you please pop it out?

Add a holder widget in the right place (<OBJECT ...>) somewhere at the
top of the message, then add to it in format_attachment.  It should
probably contain the buttons as well - i presume gtkhtml will resize
properly if you resize widgets inside of it.

> > How does 'save all' work?  You're not guaranteed to get unique or even
> > usable filenames with attachments.
> 
> I thought of appending (1) (2) the filenames or subject or some context
> information, so that its no confusing. Okie, for every attachment, i
> have the mimepart and thus the bar has the list of parts, and its just
> save all the listed parts.

Well the design should specify what happens with: missing filenames,
duplicated filenames, etc.  Design isn't just pictures, this changes the
behaviour of the code, and all the special cases need to be handled
appropriately.

> > How is encrypted or signed content displayed?
> some sort of encryption/sign emblems on the bar is what i have thought.

Well it should be included in the design.  Even if it is just to say
'nothing'.

> > > It just consumes a single line of space, in the folded mode and it is
> > > the default, which has a "Save All" button, which also displays the
> > > number of attachments. (Currently the screenshot shows a hard coded
> > > string). The slideshow can just be another button next to this.
> > 
> > Slideshow seems a bit of bloat, evolution is mostly a mail programme,
> > not an interactive video application.
> > 
> That was another req in the ui enhancement. Probably we can rethink on
> that.

Maybe we can open it in a slideshow program.  Adding one inside
evolution is insane.

> > Do we really need the awful icons?  They don't seem to add much - except
> > wasting so much space that you can't display the names usefully.  What
> > happens when you have more than will fit in a row?  Scrollbar, or resize
> > to fit?
> > 
> Notzed, we need those icons specially, when a user wants to do DnD, its
> really easy to do the icons, that just the names which appear like in

Umm, it is no different.

> list view. Also icons reach users more appealing. I thought of making it
> with out a scroll bar and resize it.

Can't they at least be smaller than these duplo-sized childrens play
pictures?  Or is that some stupid hig requirement - "must look like a 3
year old normally uses it, therefore it must be easy to use"?

The fact the filenames are so truncated makes the meaningless icons even
less meaningful.

If it must be these fat icons, at least make sure you're using the same
re-usable widget in composer/calendar and mail - a third copy of the
code should be avoided.

> > Well I guess it's one sort of reasonably workable solution.  That is
> > still one bulky extra line wasted though.  i.e. your screenshots should
> > also show how it works if you're using the inline mail display.
> > 
> > 
> it displays exactly the same way, probably i can put a screenshot of
> that as well. I have some more coding left on this, like how to hook on
> etc, once things are done,i can probably give out the patch for this.

Of course it displays the same way - only - there may be no room left
for any content.  Which I think could considered to be quite a usability
concern ...