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

[David B. <db...@ta...>]

Hi Tim,

On Monday 28 August 2006 11: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.

Thanks.

> 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.

Thanks - I have added these clarifications.  This just points up the ongoing 
need for better documentation, and the value of more eyeballs to point out 
things that are not clear.

> 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.

I had also noticed this and fixed it in a slightly different way in the code 
currently on my computer.  Briefly, I also added another flag to the 
game_options struct which I called sound_available, which is not read or 
written to the config file.  I then added a brief accessor function, 
opts_using_sound(), which returns true only if both flags are true.  The rest 
of the program now uses this function instead of looking directly at 
game_options->use_sound.  It will be in the next svn commit.
>
> I'd also consider working on some more significant enhancements:
> 1. The options configuration screen doesn't reflect current reality all
> that well,

Agreed.  Once I get the config file reading and writing into a more general 
and flexible form, the options screen is due for a major overhaul.  It will 
be a lot of work to write an in-game options system capable of controlling 
every setting in the config file without some sort of widget set (e.g.Qt).  
The rewrite of 'options' will likely be a compromise.  After that, a Qt-based 
tuxmath-config standalone program might be on the agenda.
>
> 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.

In progress.

>
> 2. It strikes me that a good way to control the pace of the game might be
> through feedback.

Sounds like a good idea.  Currently, the game offers several settings related 
to speed and the number of comets.  The default is for both to increase 
progressively, but this can be turned off by setting "allow_speedup" to 
false.  There is also "slow_after_wrong", which turns the speed and comet 
number down to the starting values if a comet hits a city.  Certainly, more 
dynamic or fine-grained adjustments could be implemented.


> 1. Please, the tuxmath web page and the sourceforge page should both point
> to the current subversion tree.

Definitely.  I've really only worked on the coding aspect, but I will try to 
contact these sites and fix this.

> 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):

> 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?)

As others have pointed out, the make install target could be improved.  At 
least for now, I also don't know enough to feel very comfortable changing it.  
(I am a middle-aged surgeon and dad who is nearly completely self-taught with 
regard to programming - my last formal computer course was used Algol on 
punchcards in 1981).
>
> 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.

I see - setting the same operand ranges for addition and subtraction does not 
yield the same "math fact families", to us a term from my kid's text.
>
> Once again, thanks for a great program!
> --Tim Holy

Thanks for your detailed and thoughtful feedback!
-- 
David Bruce