8:35 a.m.
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
Why? I think the opposite is true. When you use a bevel to
distinguish non-writable regions on the screen, you no longer
need to use a color change to distinguish them.
Yes, you need a color change. Let's say there are 2 kinds of user
interface: the ones consisting exclusively of widgets, and the ones consisting
of a working area (in which the user focuses 80% of his time) and some widgets
around. XEmacs belongs to the second category. If you look at an XEmacs frame,
you notice that the relative surface covered by widgets is small. In those
conditions, I can assure you that for the majority of people, the bevels
*only* (which are colors close to the original one anyway) are not a
sufficient clue. The situation might be different for apps in which you have
only widgets, although some of them like xv provide a different background
color for the container by default.
I find the "this looks ugly" arguments irrelevant, since
you can
customize specific colors to your liking after you affect a global
change.
If "this looks ugly" for the majority of people, then the argument becomes
relevant IMHO.
You can instead honor the user's global background/foreground
color
choice, which they may have made for a good reason, such as "reading
black on gray80 text hurts my eyes."
[...]
You cannot easily restore the ability to affect color changes globally
once it is gone. In fact, before the code changes I made, you could not
do it at all. That ability is what I'm trying to preserve.
I perfectly understood your goal. It's just that honoring the user's
request by simply using his -bg and -fg for widgets is totally bogus. When Joe
user says "-bg this -fg that", he means *before anything else* that he prefers
a dark background and a bright foreground instead of the opposite. And this,
maybe, should be respected by the widgets too. However, I can guarantee that
Joe will be surprised to see the widgets turn the same color as the text, and
we'll have tons of bug reports regarding this.
There might be a way to conciliate our views: something acceptable for
me would be that the widgets, by default, get a similar appearance to the
text, but brighter if the text background is dark, or darker otherwise. This
can be accomplished by computing new colors in a way similar to what is done
to compute shadow colors. Then the widgets will "honor" the user's
requests,
and will still be visually different.
This sounds possible for 21.1. But for 21.0, please, leave the widgets
alone. Outside of -bg and -fg.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr
/_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72
75634 Paris cedex 13 Fax. (33) 01 45 81 31 19
9:16 a.m.
New subject: toolbar picks up -bg
At 09:35 AM 6/16/98 +0200, Didier Verna wrote:
I perfectly understood your goal. It's just that honoring the
user's
request by simply using his -bg and -fg for widgets is totally bogus. When
Joe
user says "-bg this -fg that", he means *before anything
else* that he
prefers
a dark background and a bright foreground instead of the opposite. And
this,
maybe, should be respected by the widgets too. However, I can guarantee that
Joe will be surprised to see the widgets turn the same color as the text, and
we'll have tons of bug reports regarding this.
Now, bizarrely I'm going to side with Kyle on this. The argument we have
had to date has been that the widgets and default face should be different
colours. I always though Kyle opposed changes that set the modeline etc
colors to achieve this because he wanted the default face and modeline to
be the *same* color. But actually he wants -bg/-fg to set the
characteristics of the widgets (correct me if I'm wrong Kyle) and the fact
that the modeline is the same color as the default face is a by product of
his implementation.
Now I actually agree with Kyle that -bg/-fg should set the colors of the
widgets. I think this is what happens in other X apps, and makes things CDE
friendly, say. My latest fix makes the modeline (and other gui elements)
pick up -bg directly instead of inheriting from default. This has the
effect of preserving Kyles desired behaviour but also making the modeline
and default face look different if you set the default face background. I
think this is a step forward since it means people do not have to
specifically set the modeline face to resinstate the behaviour they want.
The outstanding issue now (as I see it) is that by default -bg affects the
default face as well. I agree with Didier on this, it should not look the
same as the widgets and IMHO we should therefore set the _default face
background_ to something sensible. This is different to my position 2 days
ago when I though we should set the modeline etc to be something sensible.
But I don't think we are going to resolve this for 21.0.
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
4:03 p.m.
New subject: toolbar picks up -bg
Andy Piper writes:
The outstanding issue now (as I see it) is that by default
-bg affects the default face as well. I agree with Didier
on this, it should not look the same as the widgets and
IMHO we should therefore set the _default face background_
to something sensible.
How different do you want it? White was deemed too bright, gray75
was deemed too dark. gray80 was the compromise color. I used
gray80 for the widgets so that the text in them would not be any
less readable than the rest of the frame. It was supposed to
avoid another holy war about the colors (haha, silly me).
We should be able to tint the widget colors slightly to get some
separation and still keep the brightness level the same. Would
that satisfy those of you who want to cleave my louse-bitten head?
4:27 p.m.
New subject: toolbar picks up -bg
At 11:03 AM 6/16/98 -0400, you wrote:
Andy Piper writes:
> The outstanding issue now (as I see it) is that by default
> -bg affects the default face as well. I agree with Didier
> on this, it should not look the same as the widgets and
> IMHO we should therefore set the _default face background_
> to something sensible.
How different do you want it?
Quite different ;)
White was deemed too bright, gray75
was deemed too dark. gray80 was the compromise color. I used
gray80 for the widgets so that the text in them would not be any
less readable than the rest of the frame. It was supposed to
avoid another holy war about the colors (haha, silly me).
Does this mean you agree with the rest of my mail? I personally would like
white - or if that's too bright something reminiscent of paper - e.g.
whitesmoke, cornsilk, oldlace, wheat.
We should be able to tint the widget colors slightly to get some
separation and still keep the brightness level the same. Would
that satisfy those of you who want to cleave my louse-bitten head?
I would favour tinting the default face background rather than the widgets
- but that's another holy war.
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
7:16 p.m.
New subject: toolbar picks up -bg
Andy Piper writes:
Kyle:
>White was deemed too bright, gray75 was deemed too dark.
>gray80 was the compromise color. I used gray80 for the
>widgets so that the text in them would not be any less
>readable than the rest of the frame. It was supposed to
>avoid another holy war about the colors (haha, silly me).
Does this mean you agree with the rest of my mail?
Yes.
I personally would like white - or if that's too bright
something reminiscent of paper - e.g. whitesmoke, cornsilk,
oldlace, wheat.
I don't agree with brightening the background. Here's what I
cooked up
>We should be able to tint the widget colors slightly to get some
>separation and still keep the brightness level the same. Would
>that satisfy those of you who want to cleave my louse-bitten head?
I would favour tinting the default face background rather than
the widgets - but that's another holy war.
I'm not worried about the war, I'm worried about breaking the
code at this late stage. That's why I'd recommend leaving things
as they are. But I have to admit, I don't have much faith in the
stability of this release, so maybe it doesn't matter. Dot-oh
releases usually suck, might as well get it over with.
9:31 p.m.
New subject: toolbar picks up -bg
At 07:16 PM 6/16/98 +0100, Kyle Jones wrote:
Andy Piper writes:
> Does this mean you agree with the rest of my mail?
Yes.
Hallelujah!
I don't agree with brightening the background. Here's what I
cooked up
The color tones look different. The widgets aren't grey enough (too
purple). However, I'm now going to get religious if you are now suggesting
that setting backgournd actually gives widgets that are a *different* color
to what you have specified. Surely this means that if you have a CDE color
scheme (say) XEmacs will look slightly different to everything else. This
seems bad to me. What about darkening the default face background instead?
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
11:17 p.m.
New subject: toolbar picks up -bg
Andy Piper writes:
At 07:16 PM 6/16/98 +0100, Kyle Jones wrote:
>Andy Piper writes:
> > Does this mean you agree with the rest of my mail?
>
>Yes.
Hallelujah!
>I don't agree with brightening the background. Here's what I
>cooked up
The color tones look different. The widgets aren't grey
enough (too purple).
Well, yeah. The idea is to use a different color, since that's
what those brandishing the axes are clamoring for. The pale blue
is at about the same brightness level as gray80 and so should be
about as readable. We can use pale pink instead on odd numbered
releases, for equal gender representation, if that's desired. :)
However, I'm now going to get religious if you are now
suggesting that setting backgournd actually gives widgets that
are a *different* color to what you have specified.
No, I thought we were just talking about the defaults. If -bg is
specified, all the widgets follow along. But if -bg/*background
isn't specified, then you get the pale blue widgets and gray80
writable area.
This seems bad to me. What about darkening the default face
background instead?
Since we already have a compromise on that, I'd like not to get
the wolves howling again. So I'm experimenting with mild color
changes.
Hrvoje likes gray75 for the widgets. Seems readable with our
modeline colors. It doesn't look different enough from gray80 to
have much value, I think. Here's a picture.
3:13 a.m.
New subject: toolbar picks up -bg
>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
Kyle> Hrvoje likes gray75 for the widgets. Seems readable with
Kyle> our modeline colors. It doesn't look different enough from
Kyle> gray80 to have much value, I think. Here's a picture.
This (gray80/gray75) is noticable to me. It does look better to me
than no differentiation. I don't think most users not tuned in to
this discussion would consciously notice the difference between the
widget and text backgrounds. I suspect many would not be able to tell
exactly what the difference was between an 80/80 frame and an 80/75
frame if displayed side-by-side, but that they would express a
definite preference. I suspect the preference would be for the
differentiated frame.
I prefer 80/75 to a tinted differentiation (the pink alternative
sounds wretched).
Having seen a few proposals, I have no opinion on the best default
among them (the comment about "wreteched pink" comes from too much
Aerosmith on Japanese radio, perhaps).
FWIW
8:48 a.m.
New subject: toolbar picks up -bg
At 11:17 PM 6/16/98 +0100, Kyle Jones wrote:
Well, yeah. The idea is to use a different color, since that's
what those brandishing the axes are clamoring for. The pale blue
is at about the same brightness level as gray80 and so should be
about as readable. We can use pale pink instead on odd numbered
releases, for equal gender representation, if that's desired. :)
Yuck.
No, I thought we were just talking about the defaults. If -bg is
specified, all the widgets follow along. But if -bg/*background
isn't specified, then you get the pale blue widgets and gray80
writable area.
Ok with me.
Hrvoje likes gray75 for the widgets. Seems readable with our
modeline colors. It doesn't look different enough from gray80 to
have much value, I think. Here's a picture.
It looks better than the previous one to me - but hey what do I care I use
mswindows.
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
4:24 p.m.
New subject: toolbar picks up -bg
At 11:17 PM 6/16/98 +0100, Kyle Jones wrote:
Well, yeah. The idea is to use a different color, since that's
what those brandishing the axes are clamoring for. The pale blue
is at about the same brightness level as gray80 and so should be
about as readable. We can use pale pink instead on odd numbered
releases, for equal gender representation, if that's desired. :)
Color discrimination varies widely between individuals. Some people
are colorblind. I've read that it's considered poor interface design
to distinguish interface elements by color alone - there should also
be a difference in absolute brightness level. I've seen this pointed
out in books on human-factors engineering for interface design (sorry,
no references handy) - try setting your display to monochrome to see
what might be confusing for colorblind users.
8:48 p.m.
New subject: toolbar picks up -bg
At 11:17 PM 6/16/98 +0100, Kyle Jones wrote:
>Well, yeah. The idea is to use a different color, since that's
>what those brandishing the axes are clamoring for. The pale blue
>is at about the same brightness level as gray80 and so should be
>about as readable. We can use pale pink instead on odd numbered
>releases, for equal gender representation, if that's desired. :)
Color discrimination varies widely between individuals. Some people
are colorblind. I've read that it's considered poor interface design
to distinguish interface elements by color alone - there should also
be a difference in absolute brightness level. I've seen this pointed
out in books on human-factors engineering for interface design (sorry,
no references handy) - try setting your display to monochrome to see
what might be confusing for colorblind users.
On the oder hand color contrast tends
to be *much* less strain for the
non impaired eye than brightness contrast.
On the gripping hand perhaps we should provide ready-to-go color "themes"
from which to chose.
To the casual user even *Customize Faces* buffer might be overwhelming
(and that doesen't include widgets at all).
Letting him chose between a few color themes would be easier.
To have 5-10 color setup should be enough to bootstrap everyone (while
letting us have what we are used to without further customization), joe
user can then fine-tune colors to his liking (though I bet most will
amble along with the standard ones).
Just my .02$
Best Regards
Mauro Condarelli
9658
days inactive
9659
days old
10 comments
6 participants
participants (6)
-
Andy Piper -
Charles G Waldman -
Didier Verna -
Kyle Jones -
Mauro Condarelli -
Stephen J. Turnbull