Re: [Tuxmath-devel] Patches & plans for tuxmath

[Tim H. <ho...@wu...>]

Hi again,

Oops, I guess I should have said:
mathcards.diff is to be applied to mathcards.c
tuxmath.diff applies to tuxmath.h
config.diff applies to config.c
setup.diff applies to setup.c

Surely there is a better way to do this, but I obviously haven't figured it 
out yet...sorry.

--Tim

On Monday 28 August 2006 10:23, Tim Holy wrote:
> Hi,
>
> First and foremost, thanks to all the people who have contributed to
> tuxmath, making it a great program that my family is benefitting from a
> lot. Particular thanks Bill Kendrick for creating tuxmath and GPLing it,
> and to David Bruce for all the enhancements he's given it.
>
> Because we're liking it so much, I thought I'd try to contribute a bit to
> the project. I'm new to contributing back to open source, so I'm probably
> not very sophisticated in my use of the tools.
>
> Attached are two tiny enhancements:
> 1. (trivial) Provide a bit more description of what the play_through_list
> mode does---I kept trying to supply a text file for the problem list until
> I looked at the source code. The relevant patch file is mathcards.diff.
> This patch also adds a comment on a point that I initially found confusing.
> 2. On some systems (e.g., older, or perhaps even current, KDE systems using
> aRTs), sound hardware can be temporarily unavailable, because aRTs
> didn't/doesn't share the sound resources nicely. In that case, sound gets
> turned off. The problem is that this then gets saved as the user's
> preference for the next session. This is fixed in the other 3 patch files:
> config.diff, setup.diff, tuxmath.diff. (Presumably if I knew what I was
> doing I could have made this a single patch file?) Note my use of "verbose
> = 2" seems a bit cheesy, at least if you ever had anything else planned for
> gradations in verbosity---feel free to change this.
>
> I'd also consider working on some more significant enhancements:
> 1. The options configuration screen doesn't reflect current reality all
> that well, especially with regards to the numerical ranges; my older
> daughter is working on her times table up to 10, and was briefly
> disconcerted to see "12" there even though I had manually edited the config
> file appropriately. The addition of the "speed" control is very nice; my
> daughters might also like to be able to control the game's acceleration
> (speedup_factor). So it might be nice to be able to give users more control
> over certain parameters.
>
> Conversely, tuxmath is clearly to the point of being useful for classroom
> purposes---but there, a teacher might want to be able to prevent students
> from changing the assignments to "plus" when they're supposed to be working
> on "times." So, some method for allowing someone to set, say by a
> configuration file, which options should be "locked" (and not even show up
> on the options screen) could be a useful feature. (Of course there might be
> other ways of accomplishing the same thing, say, by watching the kids while
> they play!)
>
> But if these thoughts make sense to others, it might be worth doing
> something of a general reworking of the options screen.
>
> 2. It strikes me that a good way to control the pace of the game might be
> through feedback. Many kids (in particular, mine) will probably have a
> comfort range: it's boring when it's too slow, and it's intimidating when
> it's too fast. Instead of controlling the speed directly, one might want to
> instead try to achieve a particular "adrenaline level." For example, one
> could specify in the configuration file that this kid loves the challenge
> when the problems frequently almost nuke the cities; another kid (using a
> different config file) might be more cautious and prefer it if the problems
> rarely get more than halfway down the screen. The game could adjust its
> speed to achieve, say, an average height at which the player zaps the
> problems. With braver players that level could be set lower (closer to
> smashing the cities), with more cautious players it could be set higher.
>
> While this might work well for some players, an easily-foreseeable problem
> is that if kids discover the feedback, some of them might try to take
> advantage of it---or, if they decide for fun to "wait until the last
> minute" before zapping a problem, in order to try to build a sense of
> excitement, then the game will slow down rather than speeding up, perhaps
> contrary to what the kid himself/herself would actually prefer.
>
> For that reason, one would of course want to be able to leave the current
> controls available, and have feedback only as an option. It might be
> especially good for the first-time user, to set the game to the appropriate
> level; one could choose to then fix the speed in the config file, for
> example.
>
> However, giving the users direct control over speed & speedup might be just
> as good, or better, for achieving these aims---so it's not obvious that
> this would be a desirable feature. Discussion?
>
>
>
> There are also a few other points I thought I should mention, but either I
> can't do anything about them or hesitate to do so without some input from
> those with more expertise:
>
> 1. Please, the tuxmath web page and the sourceforge page should both point
> to the current subversion tree. When I started hacking on it, I was going
> to use the CVS; but by chance I had first downloaded the sources from
> Debian unstable, and was surprised to see that these seemed newer and more
> featureful than the CVS. I then poked around and found the subversion tree,
> but it could have easily worked out differently, wasting a bunch of time.
>
> 2. Installing: the PREFIX=?? syntax doesn't work for me unless I take root
> privileges. It complains about the "chown" (here are the last 4 lines of
> output):
>
> cp tuxmath /home/tim/src/tuxmath/build/bin
> chown root:root /home/tim/src/tuxmath/build/bin/tuxmath
> chown: changing ownership of `/home/tim/src/tuxmath/build/bin/tuxmath':
> Operation not permitted
> make: *** [install] Error 1
>
> I edited the Makefile to allow me to set OWNER, and that works the first
> time. However, when I modify & recompile, then I get a different problem:
> it turns out that the install script also copies all the .svn directories
> (presumably, this is not actually desirable?) and on these directories I
> get permission errors (because these files are locked for writing even by
> the owner).
>
> Unfortunately, not being a C/C++ wiz I haven't had enough experience with
> Makefiles to solve this one easily myself. I tried putting in a
>      cp $(find . | grep -v ".svn") $(DATA_PREFIX)
> but I think make tries to interpret my shell command as a makefile
> variable. Anyone else know how to fix this? (Use rsync instead of cp? Or do
> some people not have that installed on their systems?)
>
> 3. In the configuration file, I've noticed that the ranges for subtraction
> are not specified as the complement of the addition problems---for that,
> one would specify "subtrahend" and "difference" rather than "minuend"
> and "subtrahend". This is in contrast with division, which is the
> complement of multiplication. One consequence is that kids get 121 addition
> problems if they go from 0 to 10, but many more subtraction problems that
> include 20-4=16 etc. This is not a bug, and may not even be bad, but it's
> something I noticed. I can try to help change it if that's desirable.
>
> Once again, thanks for a great program!
> --Tim Holy