Re: 2.1.3 Discussion Points

[Steffen Klemer <masterofheap gmx net>]

Am 2004.06.04 20:39 schrieb(en) Albrecht DreÃ:
> Am 04.06.04 19:23 schrieb(en) Peter Bloomfield:
> > I'm not sure what widgets we could use to implement that.  `Content'  
> > and `Message Parts' (which might need to be renamed something like  
> > `Message Structure', to avoid confusion with `Attachments') are  
> > notebook tabs, and I don't believe we can mix notebook tabs and  
> > comboboxes in the same patch of screen.  Perhaps a third notebook tab  
> > that reveals a flat list of the attachments?
>
> I think it's possible to add the combo to the notebook tab, but this  
> will look quite ugly, at least with some themes. But what about a combo  
> box inserted above or below (or inside? Doesn't Gtk support this?) the  
> top-level headers box? I am afraid the flat attachment list will not  
> necessarily improve the situation.

Yes that is exactly the way I wold promote ;)

I would either like an attachment-clip-icon on the right side of the  
header-box or a line of icons directly below the header-box

I'm sure both will be possible with gtk2 ;)

> > -----------------------------------------------------
> > | Warning! This message refers to content at          |
> > | http://some.spam.com/some/image.jpg.  Balsa can     |
> > | retrieve it, but doing so may alert the sender that |
> > | you are viewing this material.                      |
> > |       --------------         --------------         |
> > |      |   Retrieve   |       |Don't retrieve|        |
> > |       --------------         --------------         |
> > |              [X] Don't ask me again.                |
> > -----------------------------------------------------
>
> Sounds like a really good solution to me. However, what will we do if  
> the message points to more than one external link, each of which may be  
> located at different locations? Do we get a new dialog for each link, or  
> for each host?
>
> An other problem might be that we should (?) provide some kind of  
> caching. If the user decides to download the stuff, deselects the  
> message and later selects it again, it would be great if this does not  
> trigger the download again. Many pitfalls there...

I see 2 possibilities to solve this:

1) a per-server-config (like the cookies, popup and images-dialogues in  
galeon and mozilla) (with a warning like the one from Peter) (but the  
checkbox has to be above the buttons and their order has to be changed (if  
we want to follow the HIG) ;)

2) (like evo I think) "[X] Allow fetching of online-content from people  
living in my address book"

In the 2nd case the user should get a warning if the message has online- 
content but the sender is not in the great address book

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

Attachment: signature.asc
Description: PGP signature