Re: [AD] More OSX Allegro Notes

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> Defining ALLEGRO_USE_CONSOLE before including allegro.h still does not
> stop the icon from popping up on the dock in OSX.

OSX Allegro uses magic main replamenent that works this way: on startup a
cocoa NSApplication object is created (thus a connection with the window
server is enstablished), then it is registered with the dock (and you see
the icon popping out there) and then it spawns a thread running the user
main() function, while the main application thread fetches and handles
system events.
What can be done is not to register the app with the dock if
ALLEGRO_USE_CONSOLE is defined, but an NSApplication object is needed to
handle system events. But I wonder if this makes much sense at all.
Thoughts?

> I've been testing various parts of allegro, though, and everything else
> seems to be in good working order.  I also have a joystick now, so
> hopefully I'll be able to test that module as well.

Great. What kind of joystick do you have? I'm particularly interested in
knowing how the axis are reported on secondary sticks... I have a joypad
with a digital 8-way pad (hat) and two analog sticks; the first analog stick
works ok, but for the second I have the axis inverted (y works as x and x as
y). Dunno if it's my joypad or what... HID Manager reports 4 axis for me: x,
y, z and Rz... The first 2 are for the first stick, and the other for the
second one, and I don't know if they are to be interpreted y first and x
right after.

> I personally think the compile system was nicer when Carbon wasn't
> involved -- would it be possible for Allegro to recognize whether or
> not it's being compiled on a 10.2 machine, and then drop the 10.1 code?
> This would make the libraries required for compiling a lot shorter.

I've looked for such a way too, but failed so far. It is easy to check for
it at runtime (see qzmouse.m) though.
Anyway I don't see much problem here as you'll probably always use
allegro-config to generate proper linking options, so it shouldn't matter
how many libs are linked.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/