9 Sep
2010
9 Sep
'10
12:38 a.m.
Excerpts from Arnold Krille's message of 2010-09-08 22:46:52 +0200:
On Wednesday 08 September 2010 22:19:50 Philipp
Überbacher wrote:
That's still very gtk/qt or even kde/gnome centric. There's a lot more
out there. Those might be the prevalent toolkits but certainly not the
only ones. That's the gnome/kde bubble so many seem to be stuck in and
not being able to see beyond.
Excerpts from Arnold Krille's message of
2010-09-08 22:02:10 +0200:
I don't know of any way to set a system wide color scheme of any sort. I
know of different toolkits using their specific settings, and that's as
close to a system color theme as I'm aware of. I did switch to a dark
theme and managed to get qt use the GTK theme, but that still leaves a
lot of programs out of the equation. Note that Desktop-Environments in
the sense of gnome/kde is something I despise, mainly because of their
current understanding of 'integration', which in practice means to
almost force users to use certain programs and an unbelievable
dependency hell. They each create their very specific ecosystem in which
they attempt to 'integrate' everything else, which just means to make
stuff dependent on more and more of the ecosystems specific subsystems.
/rant
Well, I don't know how to achieve anything like a system color scheme in
the foreseeable future.
You don't have to use the desktop-environment to use the toolkit. And the
toolkits have become good enough to support/respect each others style and
colors. At least here on my kde systems the gtk apps (apart from ardour:) use
the system-wide colors I set in kde's systemsettings. Hi,
On Wednesday 08 September 2010 21:06:29 Philipp Überbacher wrote:
I was talking about controls in general, which means there might not be
any dB or mute or anything like that, it might be anything, and there
might be special cases/settings where you want a special color, agreed.
Excerpts from Arnold Krille's message of
2010-09-08 19:18:54 +0200:
> On Wednesday 08 September 2010 16:35:31 Andrew Bryant wrote:
> > Previously:
> > > That's actually a neat idea, color for immediate visual feedback.
> > > I imagine the problem is the colors. What would be sane? I guess
> > > three basic colors and interpolate between them?
> > > low = blue
> > > middle = yellow
> > > high = top
> > >
> > > It needs to be rather intuitive. I guess the more colors the less
> > > intuitive it will become. Maybe two are enough.
> > > I wonder which color would best represent 'low' or
'bottom'.
> > > Blue, black?
> >
> > I suggest you keep it simple, i.e. only two colours if possible,
> > but make them configurable for the benefit of those with visual
> > disabilities.
>
> Two colors simply isn't enough. You need a color for low, a color for
> middle and a value for high. And then you haven't even looked at a
> fourth color for mute/off.
> And fading from green directly/linear to red gives an ugly brown in
> the middle. It looks much nicer to go across yellow. And then you
> can really use that third color to stand for a special step, not
> just "in the middle of the slider".
If all you want is 'middle' and that doesn't need to be well defined,
then two colors will do. I suggested blue because of the ugly brown you
get between green and red. With blue the middle will likely be some
kind of purple, which may or may not be optimal. Maybe black to red
would be nicer, it just gives you an increasingly bright red.
I don't want 'a' middle, I want a special middle. Like 0dB between -48dB
and +12dB (the middle doesn't have to be in the geometrical middle). And
I want to know when that special middle value is reached by looking at
the color.
Mute/off, if required, would be the same as the
lowest setting.
There is a difference between mute/off and the lowest setting. At least
there can be.
Software-mixers might not make that discrete step between off and almost
silent. But some hardware mixers in devices do make that difference. And
there it will make a difference to your ear whether the signal is
attenuated by 36dB or muted. > If
these colors are taken from the color-scheme the user has chosen,
> I feel confident, that these are suitable for all kinds of
> color-blindness (otherwise the color-scheme is chosen wrongly). But
> I don't know (yet) which color roles to use from the
> color-schemes...
To what kind of user chosen color scheme do you refer to?
The one the user choose for his desktop. Which is the only real way to
compensate for visually impaired people (if thats the political correct
name). I don't like this every-app-chooses-its-own-colors at all. Though
I do understand that sometimes you need more colors, but that still is
different from "I define my apps colors on my own because I think that
is cool". The later results in apps with black text on dark-gray
background in an otherwise very light desktop-environment => bad. Or in
apps with white window background while the rest of the desktop is
optimized for on-stage-in-the-dark with black background and red
foreground => bad. Or it results with using two collors to "distinguish"
which half visually impaired people can't discriminate => bad.
Thats why I really advocate using the systems color-scheme as much as
possible (and a bit more) every time the discussion regarding colors
comes up. And even if you personally don't use a DE, the
users of your app will. And
they will a) like it more if it blends in and b) ditch it if its colors/fonts
don't respect system-defaults that are set because of visual imperfections.
Have fun,
Arnold
I think b) is total bollocks, because there are no system-defaults, only
gnome/kde defaults (and apparently X defaults no one uses) and because
users won't ditch an app just because they don't blend in visually.
There are a lot more and a lot more important reasons to choose one
program over another.
PS: No, we don't need another ColorSchemeKit and a
GlobalFontKit;-)
Agreed.
(Written from a *kit-free system)
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan