Re: Some thoughts on the new message parts UI (long!)

[Steffen Klemer <masterofheap gmx net>]

Am 2003.08.22 13:37 schrieb(en) Albrecht Dreß:
> Am 21.08.03 13:11 schrieb(en) Steffen Klemer:
>>> the tree can be quite long. remeber, people sometime do receive 
>>> pictures.
> 
> The tree can also be quite wide, as we now (in the cvs) have additional 
> information for some mime types, e.g. the sender and subject for 
> embedded message/rfc822 parts, and (in my local playground, to be 
> released when gpgme 0.4.3 is ready) the overall signature status for 
> application/pgp-
> signature. We could think about more... So there *will* be a horizontal 
> scrollbar if the message contains such parts.

Have thrown this already away :)

>> But I like the other idea more with tabs for each attachment the tree 
>> on the 2nd tab rigth after "content".
> 
> IMHO adding tabs for each attachment (== mime part?) is NOT a good idea 
> as messages tend to be increasingly complicated. Think of multipart/
> mixed, containing a multipart/alternative (as mua's sending html and 
> plain parts *are* reality, unfortunately!) plus some attachments, of 
> which one is a message/rfc822 with the same structure, everything put 
> into a multipart/
> signed container with the application/pgp-signature (e.g. see the 
> *simple* example). This all is perfectly standard-compliant, but having 
> 10 or 15 tabs just breaks usability. The separated tree view has been an 
> attempt to show all text (plain or html, as you like) parts and headers 
> immediately, and to keep an overwiev of the structure and attachments 
> separately.

Yes, but in former days the icon view also only had the real content shown 
in it.

I proposed this to simplify the whole thing for not that advanced users. 
So the experts have the tree on the 2nd tab and everybody else has the 
real content (images, patches, programs) and not multipart/alternative or 
the gpg-container. In case of an attached msg just the text with headers 
and all the relevant attachments.

And a normally a msg doesn't have 10 attachments, or? Otherwise the tabs 
are srcrollable (does gtk supports this, or is galeon a hack?) and you 
still have the tree...

As an opt-out list for what shouldn't been show I would propose
message/rfc822
multipart/alternatives (like txt-versions of shown html (or the other way 
round :)
all this gpg-container-stuff (it should always be shown under the msg it 
depends (like it is done today) that way there is no need for a tab... 
(but never mind, the tree still shows it)

>> Then tabs on the rigth side should be the best solution (or better: a 
>> config-option for right, left, top or bottom tabs ;)
> 
> Right-side might be nice if we could rotate the label strings. I'm not 
> sure if pango can do that; maybe we had to render it into a pixmap. 
> Hmmm... But *please* do not add a config option for label positioning! 
> That dialog is crowded already.

OK, not option :)
But the rotated label is not necessary -> a 8 chars wide tab fits on every 
screen, or? Together with the mime-picture it should be clear what type of 
file with the first letters of the filename (the whole one will be shown 
together with the content and in the tree view...)

> Just my ¤ 0.01...

I'm still no prgrammer so all this can only be a proposal :(
Perhaps with a little bit more thoughts it can ease the use of Balsa much. 
(not everybody likes to know the whole msg-structure and overlooks the 
important attachments...)
And it's fast for the dayly use (a mail from my grandpa has pictures but 
not gpg-sig, no attached msg and and and ;)

cu
/Steffen

-- 
  /"\
  \ /  ASCII Ribbon Campaign    |  "The best way to predict
   X  * NO HTML/RTF in e-mail   | the future is to invent it."
  / \ * NO MSWord docs in e-mail|                -- Alan Kay

PGP signature