[Kde-games-devel] Summer cleaning

[Stefan Majewsky]

Hi,

you might know spring cleaning, but this is summer cleaning: I have started a 
personal work branch [1] in which I'm cleaning the code all over the kdegames 
module.

This will include:
1. Krazy fixes
2. removing usage of deprecated API, and making use of new API where 
appropriate
3. simplification of unnecessarily complicated code

The changes will only be so small that I can be 99.9% sure that no regressions 
are introduced. For example, point 3 includes stuff like

> if (cond) { val = true; } else { val = false; }
> //becomes val = cond;

An example for point 2: Several QGraphicsItem subclasses implemented an 
"opacity" property which was just applied to the QPainter in the paint() 
method before calling into the baseclass paint() implementation. This can 
safely be replaced by QGraphicsItem::setOpacity, which has the same effect 
(but which was not available when this code was written).

The main reason why I'm occupying myself with this, is the inactivity in our 
module. As maintainers go away, the remaining devs have to occupy themselves 
with maintaining the other games (remember how Ian fixed Kolf for 4.4?). 
Because this includes me, I should get myself familiar with the code of the 
other games rather sooner than later to be ready when maintenance is needed.

So there is this growing set of small, but numerous changes. How do we go 
about reviewing it? Do we at all? If yes, is ReviewBoard really the right 
tool? I mean, this might turn into a mess esp. if the changes are not 
separated from each other. I won't occupy myself with posting dozens of 
patches to Reviewboard if no one reviews them.

Greetings
Stefan

[1] http://git.bethselamin.de/?p=kdegames-work.git;a=summary
    (then choose branch "summer-cleaning-2010" at the bottom)