Here you go. It compiled with no issues.. well, almost. I had to add an END_OF_MAIN() and a little bit of code to change the working directory to the executable. This is because I've bundled the program as double clickable App, and it wouldn't run unless it was in the executable's current directory. Also, I'm not sure if the person you're giving this to has Allegro installed, so I tried my best to embed the library so it will be runnable even if they do not have Allegro. It may or may not work. I don't have an OS X machine that doesn't have Allegro installed on it, so I couldn't test that. If you have issues, PM me or respond to this thread.

Anyway, enjoy.

It appears it needs another file to operate. Please give me a moment to include it into the zip file. I'll edit this post when done.

[Edit] All set. Try again now.

Thanks a lot!!

However, I have a question: When you press F12 in the program, a screenshot is saved to the actual directory. Where would this be if you run the app on Mac OS X? Or where should I save the screenshot to if I'm too lazy to make a dialog for selecting the location? The code which has the screenshot location is in manager.cpp in line 36, if you want to modify it for testing purposes.

If you want to test my program a bit more, I tell you the controls here:

Keys 1-5: change color of the tile under the mouse cursor
Arrow left/right: Change the fractal resolution
Combination of +/- on the numeric keypad and W, A, S, D: Resizes the field. For example, if you press + and W, this will make more tiles on the left.

EDIT:
Ultio: What did you have to do with changing the directory? Could you tell me what you had to modify to make it compiling?

Thomas: Thanks for testing this, too!

Thanks for your feedback & your tips! I've attached a new version with the fixes you proposed. What do you think: should I stick with the +/- on the numeric keypad or do you have a better idea for the resizing keys?

Thanks for the F12 explanation!

What does the code you posted do? It gets the executable path, modifies it in some way and changes to this directory. What does strrchr() do? I notice that one argument of this function is '/', and the program should be absolutely cross-platform (Windows, Linux, Mac OS X), so I don't think '/' is correct in every case!

It would be nice if you would compile the last version I attached and change KEY_F12 to KEY_ENTER in manager.cpp. If the code you posted is not absolutely critical, you can ignore it for the moment. Please test making screenshots with KEY_ENTER - there should appear a file screenshot.bmp on the desktop. Thanks!

Thanks, Pete, now I do understand! The code changes the current working directory to the directory where the binary resides!

But what do I need this for? I thought saving the screenshots to the desktop would work just fine?

Now, the final question: Can users access the directory where the binary is? Is it considered as good praxis to save files there?

I don't believe that saving screenshots from an app in OS X should place them within the bundle itself. There should simply be a specific location that they will go. Either in the same folder that the .app resides, a subfolder where the app lives, or, my least favorite (minus a system screenshot) on the desktop, or lastly, the user gets to decide where.

As for my code not being cross compatible, it definitely isn't, since Windows is the suck and uses the other style slash. In code I actually use in compilation amongst Linux, OS X and Windows, I simply have a #ifdef ALLEGRO_WINDOWS to handle the other style separator.

Honestly, what should exist is a function that returns the filename separator for a given OS so that doing stuff like this can truly be cross compilable. Better yet, since it's such a big issue, change_to_executable_dir might be even better. When do you ever not want to be in the same directory as the executable when you run it, anyway?

In my opinion,

• "the same folder that the .app resides" - NO! (/Applications should not contain random screenshots)

• "a subfolder where the app lives" - equally no

• "the desktop" - Yes. If you do a 'System' screenshot (Apple-Shift-3 or -4) this is exactly where the new file goes.

• "the user gets to decide where" - OK, but maybe overcomplicated

Pete

Yes but I'd use PATH_MAX instead of 256

Pete

Lack of Allegro library, I'm assuming. I probably packaged it wrong, somehow. I always manage to do that, simply because it's a pain in the ass. I do have the embeddable version of the library installed on my system, so it's either an error in my packaging the framework in, or another error that I'm not in control of.

Pete: You have all good points there. I'm assuming that the App is going to live in its own folder, since it reads the text file to get some data. I didn't want to embed it because I wasn't sure whether it might be hand edited, etc, and going into an app is just an extra added annoying procedure in order to get at some resource. In the case that an App does live in it's own folder (and it's documented that the app isn't standalone -- yeah yeah, Apple guidelines, whatever) I don't see why it would be such an issue to just save screenshots to that directory. I sure wouldn't be happy if, say, while playing WoW every screenshot I took during a session is now on my desktop. The shots are in the game's containing folder in a screenshots directory. It seems fairly reasonable to me. Again, in the case of a fully self-contained app, saving to the containing directory WOULD be a disaster.

I've just had a quick look at Michael's most recently posted sources; it compiled OK with a makefile that I wrote (attached) except the part in manager.cpp like this

 #ifdef ALLEGRO_MACOSX
 path = getenv("HOME") + "/Desktop/";
 #endif

I changed it to

 #ifdef ALLEGRO_MACOSX
 path = std::string(getenv("HOME")) + "/Desktop/";
 #endif

because it complained manager.cpp:45: error: invalid operands of types `char*' and `const char[10]' to binary `operator+'

I recommend static linking Allegro for something like this; it's less hassle. (i.e. `allegro-config --static` )

Note that I didn't test it much, just checked to see that it started OK.

Pete

You can either use XCode - Allegro comes with project templates - which will produce an .app straight off, but not with Allegro embedded (though you can add this to the build process rather than doing it manually every time you want to release). Or you can do it the UNIX way from the commandline, after which you could technically create a .app yourself but it is much easier to use fixbundle, a little tool that Allegro comes with for that purpose. Fixbundle can embed the Allegro framework and even convert images in any of the Allegro supported file formats into suitable icons.

I'll have a go at knocking you up an .app right now - back in a bit...

EDIT: a zipfile containing the .app and field.txt is attached. It's sort of weird to have a file you have to keep in the same place as the .app but I'm sure the person you're sending it to will cope. It should be compatible with 10.2+ and has Allegro embedded.