A never ending story.

[Michael Reiher]

Dirk Mueller wrote:
> 
> On Sam, 28 Sep 2002, Michael Reiher wrote:
> 
> > rendering/render_form.cpp
> > - Fix for a fix by Dirk to restore the normal widget palette on the lost of
> > focus. Use viewport palette instead widget class default palette(i.e.
> > application palette).
> 
> Not sure why you call that a fix.. there is no guarantee that the viewport
> palette is the right palette for the widget.
> 
...because your fix broke my patch:) The point is that widgets which don't get
an explicit color are simply colored in the parents palette. So I changed the
viewports palette, and thus all those widgets are in the "right" color now. And
the widget class palette is not usable as it is usually the app palette, and
thus "wrong". I guess the possible problem is that a certain widget class might
not want to follow the common colors(allthough, I can't imagine such a case).
So the only way would be to recalculate the widget class defaults to follow the
"right" palette. But no clue how.

> Basically, thats why I hate messing around with the palette. What was the
> purpose of your patch? make the colors configurable or to use the expected
> colorscheme for html rendering?
The overall purpose is to get readable webpages with inverted widget colors.
The only _real_solution_  I see is to let khtml run in an own color environment
where all colors(text, background, widgets, links) match. And the IMHO easiest
and most flexible way, from the users POV, is to use existing colorschemes. The
ideal solution would be an extension of our KDE wide schemes, as the
readability of web pages is directly coupled to the KDE colors. So to sum it
up:

a) a different set of colors
b) a configurable set

How this is achieved in detail I'm pretty open. I don't claim my patch to be
_the_ solution. My knowledge of KHTML is too limited. I just know that it works
very fine for me. And all I tried until now with CSS ended up in more mess than
before.

> 
> because the latter is much simpler to achieve. and even in a way that is
> compatible to the CSS requirements, which are pretty much broken with your
> patch.
No idea:) What did I break regarding CSS requirements?

Greets

Michael