Re: Hard-coded colors
- From: Misu Moldovan <dumol home ro>
- To: balsa-list gnome org
- Cc: Albrecht Dreß <albrecht dress arcor de>
- Subject: Re: Hard-coded colors
- Date: Sun, 7 Mar 2004 00:17:29 +0200
Thank you for your detailed explanation, but the most important issue
is about the hard coded colors and the fact that they look awful in
a dark theme. Is that fixable?
I see two solutions:
1) no colors for the messages in the headers, only for the icons
2) colors can be changed by the user in the preferences
--
MiÅŸu
În data de 06.03, ora 20:42, Albrecht Dreß a scris:
> Am 06.03.04 14:04 schrieb(en) Misu Moldovan:
> > But are these colors really needed? After all, the icons are colored
> > already and are pretty self-explanatory.
>
> The text in the message header space gives a little more detailed
> information about the signature status than the icon in the message list.
> I tried to implement something like a "traffic light": green is a fully
> trusted good signature, yellow a good signature with insufficient trust
> and/or validity, and red a bad signature, which can have a lot of
> different reasons. A blue (not from the traffic light; maybe steel? ;-)
> padlock in the message list indicates encryption.
>
> > Or even better, get rid of the extra line that informs you that
> > the signature is valid/invalid and rely on the icon alone. Or at
> > least give us back the full control over the displayed headers and
> > make it possible to disable that line.
>
> Well, you always have a detailed signature info for each signed part, and
> of course you can switch to the structure view tab to see more
> information, so in this respect you're right. On the other hand, the icon
> in the message list reflects a *combined* crypto status. Remember that a
> signed message may contain an other (e.g. forwarded) signed message with
> *different* crypto status. You may nest this over several levels, which
> makes things quite complicated. So the scheme for the message list is as
> follows:
>
> - a blue padlock says that the message is encrypted, but the signature may
> be bad;
> - a red one says that at least one signature of that message (if there is
> more than one) is bad, but others may be good;
> - a yellow one says that the message contains all good signatures, but at
> least one has insufficient trust/validity and
> - only if the icon is green, *all* signatures are good and trusted at
> least marginally.
>
> So in the end (and this was the reason for me to implement it this way) I
> think the combination of the padlock and the short status in the header
> gives a good clue about which parts of a message are trustworthy and which
> not, without the need to switch to the tree viev.
>
> Cheers,
> Albrecht.
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Albrecht Dreß - Johanna-Kirchner-Straße 13 - D-53123 Bonn (Germany)
> Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de
> _________________________________________________________________________
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]