tuxmath-devel — TuxMath developer's mailing list.

[Tuxmath-devel] New Tuxmath commit (Re: New icons for tuxmath)

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

Hi Time and everyone,

On Tuesday 23 January 2007 23:17, Tim Holy wrote:
> Hi all,
>
> My third-grader wondered when the igloos and penguins were coming to
> tuxmath. When I told her that somebody had to make them first, she
> enthusiastically volunteered. Thus begins the next generation of
> open-source contributers...

Cool - I think your third-grade daughter should meet my third-grade daughter!

>
> So, with a wee bit of help from dad, she's produced some candidate icons
> for replacing the exploding cities.

They will certainly be used, as will your Mac build contributions.  It'll just 
take me a while to get to them.

I just commited revision 69 to svn - the menu overhaul is coming along pretty 
well, time permitting.  Feel free to have a look.  Highlights:

- lots of new space-themed graphics, courtesy of the "cosmos" backgrounds 
bundled with Gnome.
- "Math Command Training Academy", basically a way to choose from a series of 
pre-defined option files bundled with Tuxmath.  I think I have 10 "lessons" 
so far - the only limit on the number of lessons is a compiler constant that 
I have arbitrarily set at 100.  The lessons use Tim's feedback code and are 
not intended to speed up very much.
- "Arcade" mode - the original mode where the game keeps speeding up until all 
of the cities are destroyed and players go for a high score.  There are four 
difficulty levels (Space Cadet, Scout, Ranger, Ace) - eventually these will 
be used for high score tables.

The actual options() code is not yet changed, but the above will remove a lot 
of the reason for players/teachers/parents to want to adjust settings.

The code is still, well, a big mess, but improving. 

-- 
David Bruce

[Tuxmath-devel] New icons for tuxmath

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

Hi all,

My third-grader wondered when the igloos and penguins were coming to tuxmath. 
When I told her that somebody had to make them first, she enthusiastically 
volunteered. Thus begins the next generation of open-source contributers...

So, with a wee bit of help from dad, she's produced some candidate icons for 
replacing the exploding cities. There are a few samples attached, as png 
files. The originals are SVGs we created with Inkscape, which seems to be one 
heck of a drawing program. (I'm attaching the SVG file too---improvements 
welcome!) The penguin was based on some clip art by "Anita" submitted to the 
Open Clip Art gallery. And we were inspired by the tuxpaint igloo stamp, 
although our drawing is from scratch.

The attached PNG files represent 3 combination icons that we would envision 
fleshing out with additional samples (some of which are already drawn, as you 
can see in the SVG file): the happy penguin inside its intact igloo would 
occasionally flap its wings; the penguin does a "duck and cover" whenever a 
comet is about to hit (as seen in the "incoming.png" file); steam goes up at 
the moment of impact (there, I suspect our drawing needs work...). We've also 
wondered about stealing the "running penguin" from tuxtype and having the 
penguin run off-stage when its igloo is completely destroyed. (That was my 
daughter's idea, which I like because that way the penguin itself doesn't get 
hit by any comets.) And finally, an enhancement to the arcade mode play: 
after the player clears a wave, one destroyed igloo gets subjected to a "snow 
storm" that partially (or completely?) rebuilds it. The penguin happily 
reoccupies its igloo. This would basically provide "extra lives," which seem 
so effective in maintaining kids' interest in other arcade games.

Anyway, all these ideas would take some effort yet to implement, but we 
thought it best to share our work in progress with the rest of you to see how 
you like it, and how to proceed from here.

Best wishes,
--Tim & Kendra

[Tuxmath-devel] Tux Math website

[Bill K. <nb...@so...>]

So any word on an updated TuxMath website?  Something I can direct people
to when they visit the NewBreedSoftware.com pages, or email me for help
or with suggestions...?

Thanks & happy new year!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxmath-devel] Mac build files

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

Hi David,

Today I was able to test my most recent build of tuxmath on a second Mac, and 
it now seems that everything works (on OS 10.4; I don't expect this to work 
on any earlier release of the Mac OS). I did the build on a PPC Mac and 
tested on an Intel Mac, so even the universal binary part seems to be 
working. Martin Fuhrer was quite helpful; the issue turned out to be knowing 
how to properly set DATA_PREFIX in a way that the Mac Finder's conventions 
get the overall path to the data (icons, sounds, missions) set properly.

Attached are two files: a revised INSTALL.txt and a tar archive of a new 
directory, "macosx" (mimicking the naming for tuxpaint) that should be at the 
top level inside of "trunk". You can revert all my previous commits on Mac 
builds, they are not useful any more. Sorry for the schizophrenic progress 
here.

I can also post the disk image somewhere if you like; however, some of the 
code (and artwork, hopefully?) currently in progress would certainly be 
attractive to include in any "official" build. But if there is demand for the 
disk image "as-is" I'm happy to provide it.

Best,
--Tim

[Tuxmath-devel] Relocatable Linux application?

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

Hi tuxmathers,

My experience in building for the Mac led me to consider an unusual build 
target: might there be some demand for a Linux package of tuxmath that is 
relocatable? I myself am of two minds about this. On the "don't do it" side, 
the Debian packaging (for example) is probably the best possible way to 
handle installs on user's machines, in particular because it provides such a 
sweet way of getting updates (security and otherwise). Any relocatable 
package basically breaks this mechanism, at least as far as I can see.

On the other hand, not all distros have a Holger Levson to take such good care 
of their users (thanks, Holger). A possible advantage of a relocatable target 
is that perhaps we could provide a linux "binary package" (independent of 
distro?) much like for other OSes. And in a school situation in which the 
application might be installed only on the server, the exported volume would 
have to be the server's /usr/local unless the administrator builds tuxmath 
him/herself in the appropriate location, setting the prefix 
during ./configure accordingly. (Not that this is particularly hard...) But a 
relocatable package would allow the kids to just click on the icon and run 
the program no matter how it is installed.

If we wanted to do this, here's what the package could look like:
   tuxmath (the application)
   tuxmath-support (contains the data directory, any libs like SDL etc; or 
perhaps these could be statically linked? I know, blah. But they're not that 
huge...)

For a relocatable build, DATA_PREFIX would be set to tuxmath-support/data. 
Then, the main() function in tuxmath would be modified to parse the argv[0] 
input to determine the location of the tuxmath binary. It would then change 
to make this the working directory, and then "presto!" the requisite data 
would be in the path. (I didn't do all this for the Mac build; there I relied 
on the fact that the user will hopefully not rename the application....)

These two items (tuxmath + tuxmath-support) could exist on the server, and 
thereby not require any tweaking of the client machines (well, perhaps 
setting the client's PATH variable, if tuxmath will be launched from the 
command line...). We could also presumably distribute it as a 
distro-independent package that users could just download? Or would glibc 
issues make this impractical?

I don't know if this is (a) a good idea, or (b) worth the trouble (perhaps not 
even of writing this message!), but I thought I'd mention it while it was 
fresh on my mind.

Best,
--Tim

[Tuxmath-devel] Igloos in tuxmath

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

On Wednesday 13 December 2006 06:31, Holger Levsen wrote:
> Hi,
>
> On Wednesday 13 December 2006 09:44, Bill Kendrick wrote:
> > Anyway, here's an idea I just had.  Replace cities with igloos.
> > As they get hit, more of them get destroyed, into it's just a shell with
> > an annoy looking penguin inside.
> >
> > Or maybe instead of being destroyed in chunks, have bits of the igloo
> > melt away...?
>
> Great idea!! Much more kids and humans friendly. No need to destroy cities
> at all!

On my machine, KDE includes a very nice 128 x 128 igloo icon (see attachment).  
The city png images are 70 x 85 - it would not be too hard to adapt the igloo 
icon for this purpose, and there should not be any licensing problems.

I, for one, welcome our igloo-dwelling penguin overlords!


-- 
David Bruce

Re: [Tuxmath-devel] Tuxmath & schools

[Holger L. <de...@la...>]

Hi,

On Wednesday 13 December 2006 09:44, Bill Kendrick wrote:
> Anyway, here's an idea I just had.  Replace cities with igloos.
> As they get hit, more of them get destroyed, into it's just a shell with
> an annoy looking penguin inside.
>
> Or maybe instead of being destroyed in chunks, have bits of the igloo melt
> away...?

Great idea!! Much more kids and humans friendly. No need to destroy cities =
at=20
all!


regards,
	Holger

Re: [Tuxmath-devel] Tuxmath & schools

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

Hi Bill,

On Wednesday 13 December 2006 02:44, Bill Kendrick wrote:
> > I think we should have some sort of option to turn off the explosion
> > sound and graphics.
>
> Anyway, here's an idea I just had.  Replace cities with igloos.
> As they get hit, more of them get destroyed, into it's just a shell with
> an annoy looking penguin inside.
>
> Or maybe instead of being destroyed in chunks, have bits of the igloo melt
> away...?

Wow. I like those ideas. Not being artistically-talented, I doubt I could do 
that well myself, but I'd applaud anyone who could!

On a related note: the icon for tuxmath is at 40x40 resolution, but for the 
Mac it would be nice to have one up to resolution 128x128 (the scaled 40x40 
looks a bit grainy at that resolution). I have no idea how these were 
produced, but if it was using a vector-drawing program, would it be possible 
to write one out at higher resolution? If this is not easy, it's obviously 
not a pressing problem...

--Tim

>
> Gotta run...
>
> -bill!
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _________________________________hormones and behavior______________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel

Re: [Tuxmath-devel] Tuxmath & schools

[Bill K. <nb...@so...>]

On Mon, Dec 11, 2006 at 06:00:56AM -0500, David Bruce wrote:
> > 3. Similar to what David indicated in the TODO list from Nov. 18, the
> > "blowing up" of the cities could present a problem. In the teacher's words,
> > "it only takes one parent to complain."
> 
> I think we should have some sort of option to turn off the explosion sound and 
> graphics.

First alpha of TuxMath came out literally days before the 9/11 attack. <:^(
That was quite a blow to me, and was probably one of the main things that
kept me from /really/ getting back into TuxMath.

(And, admittedly, Tux Paint is a bit more fun to work on, and to see kids use
;^) )

Anyway, here's an idea I just had.  Replace cities with igloos.
As they get hit, more of them get destroyed, into it's just a shell with
an annoy looking penguin inside.

Or maybe instead of being destroyed in chunks, have bits of the igloo melt
away...?

Gotta run...

-bill!

[Tuxmath-devel] Mac OS X build of tuxmath

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

Dear Martin,

Bill Kendrick suggested that you might be able to provide a bit of advice on 
producing a Mac build of tuxmath, one of the other tux4kids projects. I'm 
working on this because my daughters' school expressed interest in the 
program, and their computers are all Macs. I thought "how hard could it be?" 
and borrowed a Mac. Now I've discovered that "easy to use" = "whatever you're 
already familiar with" (which for me is Linux + KDE). If Macs didn't have a 
console, I'd be doomed. :-)

I've played with 2 ways of getting this build to work: the traditional Unix 
way (configure && make, etc) and using the Xcode IDE. While the Unix way 
_almost_ works, I've run into problems with both:

1. The Unix build works (I can get the application to run fine on the machine 
that it's compiled on), but my attempts to create a portable disk image 
(.dmg) have not yet worked---I can create the disk image, but it doesn't run 
when I try it on another computer. I _think_ I've now traced the core problem 
down to "Resources." tuxmath (like tuxpaint) loads a lot of files using a 
DATA_PREFIX macro, which by default gets set to /usr/local/share in the 
configure script. Do you know how one can get it to point to the Resources 
directory?

In preparation to create a universal binary, I have also switched to using the 
SDL "Framework" rather than the unix build of SDL. This has caused a problem 
in the configure script not being able to detect SDL. Since the sdl-config 
binary doesn't seem to be in the SDL.framework, I wonder if this will prove 
to be a fundamental problem?

2. Using Xcode, I set a bunch of flags (like the Library path, even though I 
imported the SDL Frameworks into the project, and DATA_PREFIX='"data"', which 
probably won't work but it's a hack to get it to compile). Eventually I got 
it to compile. Unfortunately, it just says "Bus error" when I run it from the 
shell (and nothing even as useful when I run it within Xcode).

While I've spent some time looking at your Xcode project, I can't see how you 
got this working: your Xcode project doesn't seem to set any of these flags, 
yet it (almost) compiles on my machine. (It can't find a file "trans/af.mo".)

Can you offer me any advice? I'm not sure which of these approaches is most 
likely to be profitable.

--Tim

Re: [Tuxmath-devel] Tuxmath & schools

[Holger L. <de...@la...>]

Hi,

On Monday 11 December 2006 12:00, David Bruce wrote:
> I thought we could have the installer put in a symlink under
> ./data/missions that could point to a network location with more options
> files.  However, I don't think Windows has real symlinks.  Specifically, I
> don't know if one can use fopen() on a Windows shortcut and get it to
> traverse the "link" to the target file.

at least Windows XP still has no links, dunno about vista.


regards,
	Holger

Re: [Tuxmath-devel] Tuxmath & schools

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

Hello everyone,

On Friday 08 December 2006 18:09, Tim Holy wrote:
> Hi tuxmathers,
>

> 1. First, David's work on the options/menu code is clearly a good thing;

At least it may be when I actually get it working!

> What sounds necessary is basically a set of options files that
> one could use ("Kindergarten", "First grade", etc?) in a menu of choices.

This is exactly what I want to do after the new menu is working.  That's why I 
called the directory for the global options file "missions" (I thought 
of "lessons" originally, but I thought any kid who saw that might think it 
too boring).  

> Perhaps a school's computer teacher could tweak the files, but the typical
> classroom teacher apparently won't.

Although my third grader certainly will!
>
> 2. Packaging may be something worth thinking more about; the typical school
> environment might want to have this installed on the server and not on all
> the computers individually.

I thought we could have the installer put in a symlink under ./data/missions 
that could point to a network location with more options files.  However, I 
don't think Windows has real symlinks.  Specifically, I don't know if one can 
use fopen() on a Windows shortcut and get it to traverse the "link" to the 
target file.
>
> 3. Similar to what David indicated in the TODO list from Nov. 18, the
> "blowing up" of the cities could present a problem. In the teacher's words,
> "it only takes one parent to complain."

I think we should have some sort of option to turn off the explosion sound and 
graphics.
>
> 4. Our school, at least, seems to be moving to try to collect more
> performance data from the programs. He indicated that it would be fine if
> it doesn't report back, but that reporting data would be a big plus.
> Tuxmath already does that, but perhaps not in a way that (our) school could
> take advantage of: at my daughters' school every kid logs in with the
> username "student," so there's nothing about the /home directory that gives
> any indication about the kid's identity. He showed me a couple of
> educational programs that implement a pull-down menu with the names of all
> kids in the class, and kids have to select their own name to get the
> program running. (Apparently kids are usually honest about these things...)

I agree - my wife and daughter are now used to having their own login at the 
computers at our house, but the school treats all of the ordinary users as a 
single user.  I have thought about having a sign-in at the start of the 
program for the purpose of a high score table.  It would not really be 
secure, of course, but it could address the above issues.

>
> 5. He was somewhat concerned about the diversity of performance levels
> within a class with regards to the speed settings. I'll tentatively suggest
> that perhaps one way to handle this is to make "feedback" be the default
> mode? (Disclaimer: since I wrote that code, I'm probably biased...)

OK with me.
>
> 6. Sadly, the Mac OS X version does _not_ transfer well from one machine to
> another. So, I haven't got that disk image working correctly yet (sorry
> everyone)---as of now only compiling from scratch works. I'll spend more
> time looking at the other tux4kids programs to see how they do it---thanks
> to Bill for a helpful email about that (wish I'd remembered it earlier...)
> some time ago.

Well, it's still a step forward.  There was some discussion on the SDL mailing 
list recently about building MacOSX universal binaries that may be relevant.

Cheers,
-- 
David Bruce

[Tuxmath-devel] Tuxmath & schools

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

Hi tuxmathers,

I had an interesting meeting with my daughters' computer teacher, who may 
coordinate giving tuxmath a try in their school. I thought that it might be 
worthwhile sharing his observations with others on the list.

1. First, David's work on the options/menu code is clearly a good thing; 
apparently your typical teacher won't edit a config file. (I just updated and 
haven't yet had a chance to see what's happening in detail, but it sounds 
like a good direction to go in. I'm excited to see how this evolves.)
 What sounds necessary is basically a set of options files that one could use 
("Kindergarten", "First grade", etc?) in a menu of choices. Perhaps a 
school's computer teacher could tweak the files, but the typical classroom 
teacher apparently won't.

2. Packaging may be something worth thinking more about; the typical school 
environment might want to have this installed on the server and not on all 
the computers individually. I haven't personally thought a lot about how one 
handles things like the placement of the options files---presumably this 
could be handled by having the tuxmath "binary" actually be a shell script 
that launches the true binary and but also specifies the location of the 
options files? (the point being that the shell script is of course editable 
by whoever installs on the school's server, so that person can change the 
location.) Others may already know the right answer here (and maybe it's even 
already implemented...) Maybe we need some kind of "installer" that asks this 
question?

3. Similar to what David indicated in the TODO list from Nov. 18, the "blowing 
up" of the cities could present a problem. In the teacher's words, "it only 
takes one parent to complain." This may be more relevant for young kids than 
older kids (both I and my third grader like it that they blow up, and I 
imagine that many others might too, so I'm not arguing for complete 
elimination). He suggested having an option to have the cities _not_ explode 
as perhaps the simplest thing to do. (Shields could disappear, but nothing 
worse happens? Or maybe an "ouch" or "rats" sound or something, but nothing 
more violent?) Anyway, something to think about.

4. Our school, at least, seems to be moving to try to collect more performance 
data from the programs. He indicated that it would be fine if it doesn't 
report back, but that reporting data would be a big plus. Tuxmath already 
does that, but perhaps not in a way that (our) school could take advantage 
of: at my daughters' school every kid logs in with the username "student," so 
there's nothing about the /home directory that gives any indication about the 
kid's identity. He showed me a couple of educational programs that implement 
a pull-down menu with the names of all kids in the class, and kids have to 
select their own name to get the program running. (Apparently kids are 
usually honest about these things...)

5. He was somewhat concerned about the diversity of performance levels within 
a class with regards to the speed settings. I'll tentatively suggest that 
perhaps one way to handle this is to make "feedback" be the default mode? 
(Disclaimer: since I wrote that code, I'm probably biased...)

6. Sadly, the Mac OS X version does _not_ transfer well from one machine to 
another. So, I haven't got that disk image working correctly yet (sorry 
everyone)---as of now only compiling from scratch works. I'll spend more time 
looking at the other tux4kids programs to see how they do it---thanks to Bill 
for a helpful email about that (wish I'd remembered it earlier...) some time 
ago.

Best,
--Tim

Re: [Tuxmath-devel] Sorry about multiple messages

[Holger L. <de...@la...>]

Hi David,

On Friday 08 December 2006 12:19, David Bruce wrote:
> I just got my computer put back together after migrating to different dis=
ks
> and filesystems and the settings for my mail client were lost - I didn't
> think the first three messages were sent.

This list is so low traffic (and spam is so much more annoying anway) that =
I=20
dont think anyone will be bothered.

Thanks for the progress update and good luck with it :)=20

tuxmath 1.0.1-1 is now in etch, so I dont think I will upload anything, unt=
il=20
you declare a new stable version. So feel free to commit any intermediate=20
steps you have sitting on your harddiscs. (For backup in svn or for others =
to=20
look at..)

And btw, I filed a wishlist-bug against tuxtype about the nonfree music, so=
 by=20
now all issues in tuxtype I'm aware of are documented at=20
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=3Dtuxtype;dist=3Dunstable=
=20


regards,
	Holger=20

[Tuxmath-devel] Sorry about multiple messages

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

I just got my computer put back together after migrating to different disks 
and filesystems and the settings for my mail client were lost - I didn't 
think the first three messages were sent.
-- 
David Bruce

[Tuxmath-devel] Tuxmath compiles again

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

Work continues on merging in the menu system code from tuxtype.
Tuxmath builds and runs properly again.  Note that the new code is not 
called - it will take a bit of work to make the new menu system operational.

Build now requires SDL_ttf (in addition to SDL, SDL_image, and SDL_mixer).

Cheers,

David Bruce

[Tuxmath-devel] Tuxmath builds again

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

I'm working on merging in the menu system code from tuxtype to overhaul the 
titlescreen and menu system (of tuxmath, that is).

At least the program now compiles again, although the new code is not 
functional.  SDL_ttf is now needed to build tuxmath.

Cheers,


-- 
David Bruce

[Tuxmath-devel] Tuxmath builds and runs again.

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

Hello everyone,

I've moved in several files from tuxtype for the menu system.  After some 
hacking, the program again builds without errors (note that I did not say 
without warnings!) and appears to run properly.  Current svn is rev 65.

None of the new code is called at run as of yet - it certainly would fail 
until the required data files are moved in.  I have to do quite a bit to it 
before it will be usable.

It should be noted that tuxmath will now require SDL_ttf to build, in addition 
to SDL, SDL_mixer, and SDL_image.

Cheers,

David Bruce

[Tuxmath-devel] Tuxmath builds again.

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

I'm working on merging in the menu system code from tuxtype to overhaul the 
titlescreen and menu system (of tuxmath, that is).

At least the program now compiles again, although the new code is not 
functional.  SDL_ttf is now needed to build tuxmath.

Cheers,

David Bruce

[Tuxmath-devel] Tuxmath currently under heavy construction

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

Colleagues,
I've started merging in the menu code from tuxtype - as a result, the current 
revision in svn does not build.  (I'm also about to replace the hard drives 
in my computer, so I wanted to be sure everything was committed in case of 
disaster).  Please use revision 61 if you need source that actually works.

Cheers,
-- 
David Bruce

Re: [Tuxmath-devel] Tuxmath Mac OS X build

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

Hi David,

On Thursday 23 November 2006 06:34, David Bruce wrote:
> On Wednesday 22 November 2006 06:40, Tim Holy wrote:
> > Thanks for doing the merge. It's still to be tested on another machine,
> > and probably won't be until after the holiday.
>
> btw, how big is the disk image file (i.e. could it feasibly be sent as an
> attachment)?  A parent at my daughter's school would be happy to test (and
> use) the program, but I don't think she wants to try to build it from
> source.

It's a mere 3MB. Should I try sending it to you (and anyone else who wants to 
give it a whirl)? Presumably that's a larger attachment than tuxmath-devel 
will accept...

--Tim

Re: [Tuxmath-devel] Tuxmath Mac OS X build

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

On Wednesday 22 November 2006 06:40, Tim Holy wrote:

> Thanks for doing the merge. It's still to be tested on another machine, and
> probably won't be until after the holiday.

btw, how big is the disk image file (i.e. could it feasibly be sent as an 
attachment)?  A parent at my daughter's school would be happy to test (and 
use) the program, but I don't think she wants to try to build it from source.

Thanks for picking up the TUXMATH_DEBUG bug!


-- 
David Bruce

Re: [Tuxmath-devel] Tuxmath Mac OS X build

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

Hi David,

Rats, my tuxmath messages are still being eaten by a SPAM filter. I _think_ 
I've finally gotten that taken care of...

Thanks for doing the merge. It's still to be tested on another machine, and 
probably won't be until after the holiday.

>  On another note - I am wondering whether we would be better off if
> subversion included the configure script and any other autogenerated files
> needed to do "./configure; make; make install".  It might make it easier to
> get new builds working if Autotools are not needed.  The "autogen.sh"
> method could still be the preferred one if possible.

Sounds like a good plan to me. But, I am not remotely an automake aficionado.

--Tim

[Tuxmath-devel] Tuxmath Mac OS X build

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

Hi Tim,

I merged in your diffs and committed them as revision 61/version 1.0.2.  Not 
having a Mac, I couldn't do any testing apart from making sure that the Linux 
build and Windows cross-build still work correctly (which they do).

On another note - I am wondering whether we would be better off if subversion 
included the configure script and any other autogenerated files needed to 
do "./configure; make; make install".  It might make it easier to get new 
builds working if Autotools are not needed.  The "autogen.sh" method could 
still be the preferred one if possible.

(the above statement is motivated by my attempts to get a working mingw32 
environment on my office Windows box so I can hack on Tuxmath whenever I have 
a little spare time at work).

-- 
David Bruce

[Tuxmath-devel] Mac OS X build

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

Hi David,

I've gotten the Mac build of tuxmath working (G4 PPC OS X 10.4). The only 
Mac-specific bug was that the screen flickered, and some changes to the video 
mode setting code in setup.c fixed that.

Included is a tree of diffs that includes
1. The patch to setup.c to fix the flickering.

2. (The biggest part of the work) Makefile support for building a disk image: 
it seems most Mac apps are distributed as disk images that contain a local 
directory tree with all libraries, etc, included. I've added a new make 
target, "make macapp", that appears to build this disk image correctly and 
puts it in a subdirectory called "macbuild". I will only know that this works 
for sure once I can test this on a second Mac (e.g., perhaps it's finding the 
system libraries installed on the Mac I used for building...). I hope to do 
that test sometime in the next week or so.
The build-related work also includes an icon for the application, etc. Any 
files without the "diff" extension are _new_ files that have to be included 
in their indicated location.

FYI, from my googling it seems that cross-compiling on Linux for a Mac target 
is not recommended; hence this was all built on a Mac.

Not yet done: I haven't put any effort into building a "universal binary" that 
would run on both PPC and Intel Macs. I don't yet know how hard that would 
be. (Probably not too bad.)

3. I took the liberty of adding myself to the credits.c file, as well as my 
various testers (my daughters and their school). If it's OK with you, I 
also "put you in your place" by taking the liberty to promote you to a "Lead 
Programmer"---in my opinion highly deserved given the huge amount of work 
you've done on tuxmath. Feel free to override any of these, of course, but 
expect a fight from me if you demote yourself :-).

Best,
--Tim