[Kde-games-devel] Bugs (showstoppers?) in KGoldrunner

[Ian Wadham]

On Fri, 30 Nov 2007 08:57 am, Luciano Montanaro wrote:
> OK, I have found what really was that triggered the problem:
> I use top-level menus (mac-os like, if you prefer), and this seem to
> trigger both the problems I reported.
>
> You should be able to reproduce them by adding the lines
>     [KDE]
>     macStyle=true
> to your kdeglobals rc file.
>
Ye gods!  Well spotted, Luciano!  Now how did you find that?!?
I can now get just the same crash you did.

> Now, the option has always been hard to find, and it can't be set through a
> GUI in KDE4 yet... So it should not be a problem for now. But I still hope
> I will get it back fully working sooner or later, so the problem may
> present itself again. It is quite odd, however.
>
My observations and theory FWIW.  When macStyle=true and the first
resize event is acted upon, KGrGame::newGame (-1, -1) proceeds normally,
because the resize event has rendered and created the pixmap lists.

BUT **** there is NO second resize event ****, hence Luciano's crash,
when the first resize event was being ignored by KGoldrunner.

***** WARNING *****
This could definitely affect other games that are relying on that one-two
resize event pattern to postpone SVG rendering and avoid doubling up
the timing.  What is worse, the first (and only) resize event still comes
in with "pending" status in macStyle mode --- and that has been KDE
Games' criterion for skipping resize events, IIRC.

In macStyle mode, the main window comes up without a menu bar, as
you might expect, because it is supposed to be appearing at the top of the
screen.  It also looks as though *all* shortcut actions which would be in
the menu bar are inoperative --- including Ctrl+Q for example.

In normal mode, the second resize event subtracts about 26 pixels from
the height of the central widget, i.e. the height of the menu bar.  So I
imagine that is why the second resize does not occur in macStyle mode.

The short-term solution is to do nothing, as Luciano implies.

Long-term I think *NO* KDE Games programmers can rely on the type
and number of resize events coming out of KXmlGuiWindow and
QMainWindow during their initialisation processes.

Some other options are:

    1. Mauricio's idea of auto-initialising the rendered pixmaps whenever
        they first have to be painted (e.g. just before first game and level
        load) - and not to render them within resize events until after that
        (to avoid double or triple SVG rendering).

    2. Remember in KConfig some key parameters of the pixmap sizing,
        then do all the rendering in the game object's constructor and skip
        the first two resize events.  If one of those is a user-requested
        resize (in the macStyle case), hopefully the user will just try again.

    3. Help either of these options along by cacheing pixmaps between
        game sessions.  BTW, how is that done?

Obviously it is too late for any of these ideas now, but for 4.1 maybe?

Option 1 might require some architectural changes in KGoldrunner's
case, along the lines of tails wagging dogs.  So option 2 would be
easier to implement, though a bit hackish.

Cheers everybody, Ian W.