[Kde-games-devel] KMines SVG

[Mark A. Taff]

On Friday 09 February 2007 11:36:22 Mauricio Piacentini wrote:
> This is something I am still unsure of how to handle in code. While it
> is definately possible to style a SVG using an external .css file and
> QSVGRenderer, I did not get an answer yet (on IRC) on how to do this
> programatically, without the external style file. Of course, the program
> could parse and re-write the .css included with the theme, but this has
> several issues, like lack of privileges, etc. Does anyone here know how
> if it is possible to style the CSS from code without too much hacking?
> Maybe we will have to load the SVG as XML, add elements to it, and feed
> the result to KSVGRenderer. It looks cumbersome. Suggestions?

In the case of KMines, transforming the svg in memory using DOM and then 
feeding it to KSVGRenderer doesn't sound too bad, as it only needs to happen 
on game load, or on setting change, as opposed to other games where it might 
be required on every redraw.

Perhaps KSVGRenderer needs to be modified to permit developers to modify the 
svg tree before it gets rendered?  That seens the most elegant solution 
(without even having read the code ;-) ) to me.  Certainly now is the right 
time to make sure we have a KSVGRenderer that we can live with for the next 
five years.

For that matter, using KProccess and a sh/perl/python/ruby/sed regex to change 
the flag and number colors wouldn't be that hard either, though I think not 
as elegant, and maybe less portable.

> A complementary question: do we really want to expose this level of
> customization in the configuration options? Does anyone actually
> configure the color types for each numeral in the current KMines? Or
> simply having the option to switch themes is enough, as we can include
> one for accessibility, another with a classic look, etc. ?

Since it will all be svg (and perhaps some CSS), I'm not sure if there is much 
value in exposing that level of configurability in the gui, expescially if we 
provide, a "classic", "oxygen", and "hi-contrast" themes.  If we give people 
good base themes to start hacking from, the kde-look crowd will be able to 
innovate new themes that are required/desired.  This implies potentially 
adding KGetNewStuff to KMines in the future, if themeing KMines becomes 
popular.

> Yes, that is my initial feeling. But on the other hand, the default font
> sometimes looks ugly, and it is a bit more difficult to get perfect
> alignment for all face types, depending on the metrics. So it is
> something we need to consider as well. Ultimately I am not against
> including number shapes in the theme, as this can lead to very
> interesting themes imo. Think about a medieval theme, or a Japanese one,
> where the numerals would match the current style. The oxygen theme could
> have its typical shading in the numbers as well. Having always the same
> system font for all of the themes start to look non-optimal if you
> consider these scenarios. hum...

Again, you make good points.  I like the creative freedom and precision that 
using svg for the numbers brings.  I wonder how we could do that yet still 
use the default font as an option to cover those cases where language-glyph 
specific theme variations don't exist?

Perhaps each theme could have internal variations, so chinese or cryillic 
numbers could be in the same file?  So we use #nine or #nine.chinese or 
#nine.cryillic?  So we try to use the number according to KDE's localization 
setting, and if not found we default to arabic?

> Lots of options to choose from, it is nice to have this conversation so
> we can consider all of them.

It is indeed nice.

Regards,

Mark