Re: [AD] OSX Port Notes

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


> Some notes -- I'm still trying to get it to compile:
> 
> - obj/macosx/plugins.h didn't get generated by your makefile, so I made
> it myself.

Heh, I'll have a look, but it would be cool if we got a proper makefile
generated automatically by configure...

> - You can disable precomp by using the apple-only gcc flag
> '-no-cpp-precomp' -- however, this generates some interesting errors in
> the current codebase.
> 
> Because you've included the Cocoa framework by default in all files
> (through the platform internal headers), not using precompiled headers
> leads the compiler to go crazy when trying to import the Obj-C cocoa
> framework headers.  I don't know if you included the framework
> intentionally due to some pthread magic or whatever you did to get the
> system working.  It might be best to completely seperate the Cocoa
> stuff (window, etc) from the rest of the allegro OSX code, so that you
> don't need to be including the cocoa framework by file.

The Cocoa global header was included in the allegro header to simplify
things, so I didn't have to specify it for every file. BTW, why would anyone
want to disable precompiled headers support? Isn't that supposed to speed
things up? This stuff is almost unknown to me so forgive me if I just said
something wrong...

> - The examples compile and run.  Wild stuff man. ^_^;;  It's amazing
> that you got them to accept keyboard input when run from the terminal;
> SDL's been wrestling with this for a long time.

It actually doesn't matter if the app is started from the terminal or not...
Keyboard is still handled via NSEvents fetched in the main app thread events
pump loop (see system.m).
BTW, I've just commited some changes, that among other things, fix the
keyboard behaviour when it comes to handle ALT-* and CTRL-* combos.

> Full screen seems
> nice, though it does give me the following errors at program close:
> 
> kCGErrorIllegalArgument : CGSSetWindowDepth: Invalid window
> kCGErrorIllegalArgument : CGSSetWindowDepth: Invalid window

Known issue. I've tried also to make mode switches only from the main app
thread, by sending application defined NSEvents which I intercepted in the
main thread events loop... But with no luck so far. It's weird as what I'm
doing to switch mode is exactly the same as reported in the CGDirectDisplay
API docs; by the way, you may have noticed those "errors" only happen if you
used to switch to a gfx mode with a depth different from your desktop
depth... It looks like a system bug, but I'm not really sure here.
I've also had a look at how SDL did it, and it's almost the same... Then I
ran some SDL examples in fullscreen to find out they have the same problem
:P At least this leads me to think it's not related to multithreading...

> Also, programs run in windowed mode don't respond to a clicking of the
> close button.

It is the supposed behaviour for windowed Allegro apps. It was decided
sometime ago that the window close button, if present, was disabled by
default. You can set a callback in your programs to be issued when the
button is pressed, and this is already supported by OSX Allegro. If you want
to shutdown an app for any reason without using the app built-in exit
facilities, press CTRL-ALT-END (as explained in the Allegro docs).

> - It might be nice to have another OSX-specific target, for generating
> app bundles of all compiled programs (examples, grabber, demo).  You
> know, for the sexy double-clickability. ^_^;;  A simple shell script
> would do the trick.

I've also thought about this issue. But personally I think a real app would
be better for the purpose; something ala wfixicon and bfixicon... A program
that takes as command line input an app filename and some Allegro supported
image files (as icons) and creates a bundle with them.
I've looked at your bundle stuff, but setting a default "A" icon isn't an
elegant solution to me... Better to let the user specify the icon(s), and if
none is specified, leave the bundle with no default icon; the system will
use the default app icon.
That said, it would be nice if you could code this app. How to name it
though? To be consistent, I'd call it "xfixbundle" or "fixbundle"...

> - build process halts on this error:
> 
> [...]
> 
> Then again, I remember trying to build a CVS build on djgpp about two
> weeks ago (needed vesainfo), and it failed back then too, but I forgot
> to report it.

Weird. I'll have a look.

> - When I run exalpha from inside an app bundle, it stops because it
> can't find the allegro.pcx file; on OSX, the allegro packfile routines
> should first look int the appbundle/Contents/Resources dir, then in the
> app bundle's parent dir, for files.

This will come.

> Whew.  Hope some of this helps. ^_^;;

Sure it did :) Feedback is *always* a good thing.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx





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