[Kde-games-devel] KMahjongg (almost) using SVG theme

[Mauricio Piacentini]

Hi, guys. It took more time than what I have predicted, thanks to 
several incompatibilities while trying to get my vectorial data into 
Inkscape, and exporting it in a way that could be rendered cleanly by Qt 
SVG. We had to basically redo everything... But I am almost done with 
the art and code to make KMahjongg use SVG to render the tileset and 
background. See a preliminar screenshot at

http://www.tabuleiro.com/mauricio/kmahjongg_svg.png

There are some issues that I need to solve regarding tile spacing (they 
need to be closer) and shadows, so this is not final yet. The old 
version (for comparison) uses a fixed pixmap tile size:

http://www.tabuleiro.com/mauricio/kmahjongg_old.png

I am happy with the results so far, and I hope I will be able to merge 
it into SVN in a couple of days. But I need some feedback from you guys, 
and Alberto specially, as he is listed as the current maintainer (and 
bug owner!)

The following bug (wish actually) will be addressed by the new code, as 
I am planning to make the window resizable, and scale the background and 
tiles accordingly:

http://bugs.kde.org/show_bug.cgi?id=121960

However, there is a decision to be made. Would we still support the 
older tilesets, unmodified? Supporting the backgrounds is easy, we could 
still accept any png, jpg or svg file, with the option to tile or scale 
accordingly. The screenshot above shows a SVG background, btw. Custom 
layouts will also still be supported without modification.

But there are some issues supporting the older tileset files as they 
are, specially because they assume a fixed tile size. They also do not 
support resizing easily, since the code uses a fixed color for 
transparency, and as a consequence the existing tileset graphics do not 
use antialias. We can of course compose first and then scale. Tiles will 
look crappy, however. The code that generates shadows is very good, but 
it is not very flexible, so it is difficult to adapt it to use tiles 
with round corners for example, or for tiles of different proportions.

I was hoping to clean up this older code, and start with a more flexible 
design, one that accepts png and svg, automatically using the alpha 
channel for transparency and shadows. I also plan to add spacing, aspect 
ratio and shadow information in an external .tileset file, where the 
name of the .svg or .png data will be listed along with geometry 
information. This would let the artist have more control over the shape 
of tiles and shadows. The code will also be easier to maintain, since we 
will switch to use QPainter for all blitting and will no longer be 
drawing shadows by setting pixel data in pixmap caches.

Of course, I would add code to detect if the user is trying to load an 
older tileset (specially in upgrade scenarios), and deal with it 
gracefully. But I would like your OK to go ahead with this plan before I 
rewrite the drawing code.

Also, there is an issue that can not be solved unless we ditch the 
current method and adopt a more flexible scheme for loading themes, 
tilesets and backgrounds. So this is one more reason to change it. 
Please read the bug at

http://bugs.kde.org/show_bug.cgi?id=129469

I don't know if it is possible to solve this issue completely, but my 
plan was to ship only a default (new) tileset with the new revision, and 
at the same time implement the KNewStuff framework. I do not know much 
about it yet, but it apparently supports localization of resources (or 
should!) Then I plan to get the current legacy tileset art (pirates and 
default) and maybe wrap them as KNewStuff packages, so people could 
still get them if they want to, and if they do not mind the scaling 
artifacts.

How does this plan sound?

BTW, I plan to give the same treatment to Shisen-sho next week, 
converting it to use this new SVG tileset and background. Maybe I can 
add custom tileset support to it as well in the future, with KNewStuff, 
and put the resources in a shared location for both games. Implementing 
KNewStuff seems like a good task for Akademy, as I would have the help 
of kdelib guys if needed.

Regards,
Mauricio