Mac binaries of program needed
Michael Faerber

I'm currently making a simple fractal program for a student (no Mandelbrot, much simpler fractals). He runs Mac OS X, and I need binaries for this system. Because I only have Linux, I wanted to ask an experienced Mac user if he could do this job?

I compile this application via "g++ *.cpp -o frakt -I./" on Linux.

The application is attached.

Ultio

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

Thomas Harte
Quote:

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 linked against the framework (as per the ordinary Allegro project template), temporarily removing Allegro.framework from /Library/Frameworks is a good way to test!

Anyway, when I ran it just now on OS X v10.4.4, a main Allegro window opened and closed and then I got an error message that said "Bitmap operation is not valid!". Am I doing something wrong?

Ultio

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.

Thomas Harte

Works much better now! Displays a very low resolution image which seems to match the contents of field.txt, and I can change block colours using the number keys. I guess there are more controls I didn't figure out. As it's clearly not meant to be a public release I guess my only useful comment is: that build works fine on my machine.

Michael Faerber

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!

Thomas Harte
Quote:

Or where should I save the screenshot to if I'm too lazy to make a dialog for selecting the location?

You could use getenv("HOME") to get the path to the user's home directory, then append /Desktop to save the file to their desktop. E.g.

char OutputBuffer[512]; //arbitrary big number
sprintf(OutputBuffer, "%s/Desktop/%s", getenv("HOME"), filename_for_file);

Also, of the built in formats provided by Allegro, BMP is the smartest choice for saving as it is supported by all the tools the OS comes with and will be capable of being previewed in the Finder (i.e. using a small version of the image as the icon - much as XP does).

Quote:

Arrow left/right: Change the fractal resolution

Ah, I hadn't figured these two out, and...

Quote:

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.

I'm on a laptop so I don't really have a numeric keypad, although I can do the keypresses with "fn" shifts and so on...

If you're still modifying, I'd also add a set_close_button_callback! I can't remember what happens under XP with Allegro, but if you don't use that in Allegro the program window still has a red close button it just annoyingly doesn't do anything.

Michael Faerber

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?

Ultio

Mike, for saving screenshots, they will be dumped to the current directory that the .app lives in. Note that the F12 key is usually reserved for some Mac OS X feature. I think by default it's set up to bring up the Dashboard overlay. While most decent users will know that there's a modifier key you can use to get the "real" FKeys, you may consider changing the screenshot key. Other than that, you shouldn't need to do anything for taking a screenshot.

Code changes" I added END_OF_MAIN() to the end of the main.cpp file. I added opening and closing curlies to hold the body of the function, as well, but I'm not sure if that was necessary.

Added the following to init.cpp (some of the old code there for reference). It's not the best error handling, but it should do the job. Unfortunately, the user will never see that message. If you'd like it to be more robust, I can allegro_message-ify it and send you a new binary:

1...
2// to avoid Unicode strings
3set_uformat(U_ASCII);
4 
5// if allegro initialization fails, throw general error
6if (allegro_init() != 0)
7 throw error("Couldn't initialise Allegro!");
8 
9char *exe_path = (char *)malloc(sizeof(char)*255);
10if(!exe_path)
11{
12 printf("Error allocating memory for exe_path");
13 exit(1);
14}
15 
16get_executable_name(exe_path, 255);
17(strrchr(exe_path, '/'))[1] = 0;
18chdir(exe_path);
19free(exe_path);
20 
21internal::init_timer();
22...

Michael Faerber

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!

Peter Hull

You could do it like this

char buf[PATH_MAX];
...
get_executable_name(buf, sizeof(buf));
replace_filename(buf, buf, ".", sizeof(buf));
chdir(buf);

Which should be safe and cross-platform.

Pete

ps. strrchr finds the last instance of a character. Do man strrchr for more info or look here.

Michael Faerber

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?

Peter Hull
Quote:

Is it considered as good praxis to save files there

IMO, no. For an installed Linux app, it would be /usr/local/bin, which definitely shouldn't be written to, and for Macs, it would be somewhere inside the bundle. I assumed that code was to find some resource files. Something like a screenshot could be saved to the desktop or maybe $HOME for Linux folks. What do other people think?

Pete

Ultio

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?

Thomas Harte
Quote:

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?

When you're in a bundle and all your resources are in the Resources directory.

To the original poster - would it be possible to use Allegro's file_select_ex to allow the user to explicitly pick where to save their file? If so I could provide you with a C-callable OS X native replacement that just uses the normal Aqua save box. It would be fairly easy to select which to use via #ifdef at compile time using Allegro's built in ALLEGRO_<platform> defines - ALLEGRO_MACOSX is defined for OS X.

Peter Hull
Quote:

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.

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

Michael Faerber

Thanks that you still show such interest for my work!

In fact, I've already written a function like Ultio made it for me before: It looks like this:

std::string als::get_bin_path()
{
  // the final path
  char path[256];
  // the executable name
  char executable[256];

  get_executable_name(executable, sizeof(executable));

  // delete the file part from the path so the directory remains
  replace_filename(path, executable, "", sizeof(path));

  return slashed(path);
}

I will use this as it's already part of my Allegro framework, but I still have to thank you that you gave me your versions.

Yesterday I showed my program to my client(s), and they were quite happy with it. I asked them where the screenshots should be saved to and suggested that they could be automatically saved to the desktop, and they agreed with me. However, I'm interested in your native file selection stuff, Thomas, so I would be grateful if you would post this here.

I've just fixed a bug right now, so I will fix some stuff now, comment the code a bit, then I'll upload the newest version and would ask one of you (Ultio?) to compile my code.

EDIT: Okay, code cleaned and attached! ;)

Peter Hull

Yes but I'd use PATH_MAX instead of 256

Pete

Michael Faerber

/me makes a note about using PATH_MAX in the future

My client has tested the program now, but it didn't work for him. When he opened frakt.app, nothing happened. When he browses frakt.app and executes the binary "frakt" manually, this happens:

Last login: Fri Feb  3 19:32:18 on ttyp1
Welcome to Darwin!
le-point:~ aeroes$ /Users/aeroes/Desktop/frakt\ osx/frakt.app/ 
Contents/MacOS/frakt; exit
dyld: Library not loaded: liballeg-4.2.dylib    <--------------------
   Referenced from: /Users/aeroes/Desktop/frakt osx/frakt.app/ 
Contents/MacOS/frakt
   Reason: image not found
Trace/BPT trap
logout
[Prozess beendet]

He has Mac OS X 10.4.4 on PowerPC.

Ultio

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.

Michael Faerber

Erm ... and what should I do now? Should I install Allegro on his machine? Or do you take another try and compile my newest sources?

If you don't want to struggle with it anymore, tell me at least how to compile Allegro programs on Mac OS X. Do you use XCode, or do you use a Terminal where you use gcc directly? And how do you make the .app?

Peter Hull

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

Michael Faerber

Thanks a lot, Pete, you seem to be the first to test my new sources on Mac!

I hope that somebody of you will send my an .app in some time now ... ::)

Thomas Harte
Quote:

If you don't want to struggle with it anymore, tell me at least how to compile Allegro programs on Mac OS X. Do you use XCode, or do you use a Terminal where you use gcc directly? And how do you make the .app?

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.

Michael Faerber

Wow, thanks a lot, Thomas! That's really nice from you!

Thread #563120. Printed from Allegro.cc