[Kde-games-devel] Moving first parts of Tagaro into kdegames for 4.6?

[Stefan Majewsky]

Hi folks,

[If you're short on time, skip the first three paragraphs which are just some 
motivation.]

as you might have noticed, we (mostly Brian) are stuck with the KBlocks port. 
Those games which are being ported from QGraphicsSvgItem to KGameRenderedItem 
actually become more complex because one has to add new code to determine the 
renderSize. It would be best if the items could automagically determine their 
renderSize.

My first approach was KGameRenderedObjectItem::primaryView, which uses paint 
events to determine its renderSize. This works somehow (e.g. in KDiamond and 
KSame), but is IMO not a clean solution and induces a considerable runtime 
overhead (which increases linearly with the number of item paint operations).

But don't fear! A proper solution is available now: Tagaro::SpriteObjectItem 
when managed by Tagaro::Board. (I think that, at this point, all of you are 
familiar with Project Tagaro [1].)

Long story short: I would like to hear your opinions on including first parts 
of libtagaro in the kdegames module during the 4.6 cycle. Because the API is 
in no way stable, libtagaro would be a private library for the 4.6 release 
(and probably also for 4.7). If this is done, this would probably also mean to 
remove KGameRenderer from libkdegames again, because the same functionality is 
provided by Tagaro::Renderer.

Benefits:
- Tagaro's API gets some real-life exposure, and we can determine areas in 
which Tagaro needs to be improved. (After all, it's not an academic project. I 
want Tagaro to solve the common programming problems in KDE games once and for 
all.)
- Visibility of Tagaro development improves.
- Code duplication between KGameRenderer and Tagaro::Renderer is reduced.
- The optional GluonAudio dependency of Granatier can be removed, because it 
can use TagaroAudio instead.

Possible disadvantages:
- Because Tagaro's API is not stable, we cannot install it for others to use 
it, and changes in Tagaro might mean to adjust usages in a dozen games.
- We get new dependencies on OpenAL and libsndfile, but I consider these easy 
deps which are packaged by all relevant distributions anyway. (One might be 
able to replace libsndfile by Phonon. The API does not expose which sound 
decoding lib is being used.)
- What else?

Another point which needs discussion is the review policy. I've no problem 
with the current Tagaro code being kdereviewed (is that a proper word?), but 
what happens with the code which we add to Tagaro after it has been included 
in kdegames? (This concerns e.g. the complete networking and canvas interface 
code.) Because the API is private at this point, this should not be a problem. 
(The situation is quite similar to libkcardgame IMO.)

Greetings
Stefan

[1] http://community.kde.org/User:Majewsky/Project_Tagaro

P.S. Tagaro::Renderer has one feature regression compared to KGameRenderer: It 
misses the customColors support because the used methodology is a ugly hack. 
I'm working towards a proper, albeit minimally more complicated, solution.

P.P.S. If you're looking at the Tagaro sources now, please be advised that the 
class graph under doc/ is heavily outdated. I'll try to update it this 
evening.