Temporary KColorScheme change - hard-code some state colors

[Jos Poortvliet]

On 9/16/07, Luciano Montanaro <mikelima at gmail.com> wrote:
> Il Sunday 16 September 2007 12:52:03 Jos Poortvliet ha scritto:
> > On 9/15/07, Luciano Montanaro <mikelima at gmail.com> wrote:
> > > > I'm not that opposed to what happens in my current build: the text and
> > > > widgets become more gray, but the background stays the same.
> > > > - the window doesn't flash
> > > > - the window is still readable
> > > > - yet it is clear which window is active and which is not
> > > >
> > > > Now, who can tell me what is wrong with that?
> > >
> > > What's wrong is that large parts of the screen have to be redrawn for no
> > > real good reason...
> > >
> > > That means that
> > > - Laptops will use more power
> > > - Network sessions will be even more sluggish
> > > - Slower machines will perform badly
> > >
> > > In the end, it would give substance to the bloated KDE meme.
> >
> > Do you have any idea how substantial this is? I mean, Mac OS X does
> > it, is that the reason Mac OS X is so slow?
>
> Mac OS X Windowing system is quite different, the needed operations are
> properly accelerated, and in fact, the effect is quite different, I think.
> The entire window text is probably affected. With Qt, the effect is applied
> even to some of the widgets in the same window, probably because they
> gain/lose keyboard focus.

I guess that's a bug?

> Did you actually try some applications using the new palette-changing code?

Yeah, I tried them.

> I can see the color propagating through widget groups...
>
> > In many cases, not much
> > would change, nothing if you go from one full-screen window to
> > another, and if you have several visible, only the one you switch from
> > to another will change (and the one becoming active, of course).
>
> Not really. See above. That may be what the intended effect is, but it's not
> what happens in reality.
>
> The problem is that it happens regardless of the theme in use, so people
> cannot just switch theme to be able to ignore the problem.

Look, it's lovely to see what's wrong with it now. But more important
is: can it be fixed? Is it possible to only change some widgets (eg
scrollbars) and not have everything redraw at heavy cpu and bandwith
cost? Technically?

> > If
> > this helps usability (and that's the reason we do this), I'd say it's
> > a small price to pay.
>
> But does it help usability? Are usability experts reviewed the design for
> pitfall or usability problems?

Being able to see which window is active seems pretty important to me.
We can't change the color of the window decoration anymore, as that
would visually really suck. The theme simply isn't made for that. So
we can do something else (which Matthew here is trying) or rewrite
Oxygen again.

> The problem is that I see a great emphasis on the look, but technical hurdles
> or usability problems seem of no concern to the style developers. I hope I'm
> wrong.

Well, if it isn't possible, the artists can't do much about it - and
if it's hard, they need developers help them, fix it. How can they
know how hard this is, technically? I know I can't... It seems not to
difficult to me, but hey, I have trouble with HTML. And don't say
Pinheiro doesn't listen, he tried to make different mockups etc
already.

> Luciano


Anyway, I hear a lot of problems. But I know you guys a little (been
annoying you for a few years now) and I've seen some pretty cool stuff
been done. So I think if you (all) come out of 'this sucks' mode, this
can be fixed. Properly. It's not December yet.


/hug