[Kde-games-devel] KGameRenderer Porting Experience

[Matthew Woehlke]

Parker Coates wrote:
> On Tue, Aug 3, 2010 at 04:01, Stefan Majewsky wrote:
>> On Monday 02 August 2010 18:22:01 Aaron J. Seigo wrote:
>> That reminds me: Someone asked me if and how KGameRenderer can
>> make use of style-aware colors. (I think Amarok uses that for their
>> interface, to match the system color scheme.) The concrete usecase is a
>> sprite of a player avatar in which the player's color can be inserted.
>>
>> Do you know how to do that, which code to read, or whom to talk to?
>
> One potential way would be to edit the SVG as a XML file before
> loading. I think SVG allows one to define named colours and use them
> elsewhere. So if those definitions where altered just prior to loading
> the SVG, you could swap out various colours "as the artist intended".
> Of course, then that QSvgRenderer would only be good for a certain
> colour combination and you would have to reedit and load the SVG every
> time you wanted to make a change. Actually the more I describe this,
> the more I think this might not be the best way, as it would probably
> require hand editing the SVG.

I've given though to this previously as well, more for plasma themes 
than games, but the same principles apply. The idea I had was to leave 
the SVG alone, but define a replacement table that would take 
pre-defined colors and replace them with something from the system 
scheme. This has the disadvantage that you can't use certain colors in 
inkscape except for intending them to be replaced, but doesn't require 
hand-editing the SVG. The downside is mitigated by allowing what color 
will be remapped to be specified by the artist.

The tricky part is how to specify the replacement color, since a 
pre-defined list may not be sufficient (especially I think for plasma 
themes; for games it may not be as problematic). The idea I had was to 
implement a simple RPN/Forth parser, so some replacement rules could 
look something like this:

#445566 => $WFNo $WFNe 0.5 tint 0.3 darken
#445567 => $WBNo dark

So, the first one says 'Window Normal Foreground, tinted 50% with Window 
Negative Foreground, then darkened 30%'. The second one says 'Window 
Normal Background, take the scheme-defined dark shade.'

Such a parser would be extremely flexible (and would, to some extent, 
keep the number of pre-defined colors to something reasonable), and is 
actually quite simple to write.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
ENOWIT: .sig file temporarily unavailable