[Tuxmath-devel] Migration chugging along nicely

[Brendan L. <che...@gm...>]

Hi all,

After migrating (hopefully) the last few duplicate functions in TuxMath,
I've jumped into the more messy work. I've been bringing in Wenyuan's
work--by hand, unfortunately, since I don't see a way to apply diffs from
one repo into the other, and if there were, it probably wouldn't work
correctly anyway. Basically, I'm reading through his diffs in TuxMath and
making appropriate changes in libt4k_common. Wenyuan, would you mind looking
through my recent commits[0] and making sure I didn't miss something of
yours?

As I work through the SVG stuff, I'm adapting things here and there and
fixing some small issues I come across. The bigger issues, I'm not even
touching. One such big issue (I don't remember whether I've mentioned
before) is the fact that T4K_RunMenu handles the event loop and resolution
switches, but allows the game to affect the run via several callbacks, such
as drawing and handling events. What's missing is a callback for when
resolution changes--for now, there's a hack in the event callback that
checks for a F_10 keypress, assumes (correctly) that the switch is taken
care of already, and proceeds to recalculate the size and position for Tux
and other game-specific things.

I'm thick into testing at this moment. Everything behaves on Ubuntu; On
Fedora, gdb reports that something is funky with relocation, but is able to
recover; under MinGW, there are a whole bunch of unpredictable behaviors
that I believe stem from extern'd variables that are defined in both the
library and TuxMath--for example, the infamous "SDL_Surface* screen". So
TuxMath-centric code may accidentally access libt4k_common variables, and
vice versa. This is particularly hard to debug because AFAIK there's no way
to tell which module a symbol is coming from, other than educated guesses.
I'm trying not to be too invasive with my changes in TuxMath, but I fear in
order to do this "the right way" most of the variables in question will have
to be removed from TuxMath and the routines that use them largely rewritten.
More on this story as it develops.

As soon as it's stable, I'd like to do one more testing push before focusing
on merging. I don't want to recklessly jump into it, but at the same time,
I'm anxious (even with git) that the longer it waits, the more painful it
will be.

One thing I'd forgotten is that after the dust has settled, I wanted to put
some sort of utility in place to automate factoring out functions into the
library The rationale is that down the road, even if we're no longer sharing
code directly between TM and TT, it might be too easy to let duplicate
functionality build up if it's a chore to add new exciting things to
libt4k_common. Then whenever someone does undertake to do the refactoring,
things break and there is weeping and gnashing of teeth.

Phew! Sorry for the long-winded rambling, but it's been a busy few days. If
any of this is unclear, I'll happily elucidate. I'm just excited to be
actually coding again :)

[0] http://git.debian.org/?p=tux4kids/t4kcommon.git;a=summary