# OS-X: Carbon event handling

**URL:** <https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210>\
**Category:** SDL Development\
**Created:** [April 5, 2006, 1:36pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210 "2006-04-05T13:36:33Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 5, 2006, 1:36pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/1 "2006-04-05T13:36:33Z")

</div>

This may be opening a can of worms, but I’m wearing my Nomex suit, so  
I shall ask anyway:

Why do the OS-X bits of SDL use Cocoa, instead of Carbon? I’ve been  
looking over the code, and as far as I can see, using Cocoa causes  
nothing but complications, particularly the need for the SDLmain  
stuff and the strange way the event loop gets run. Every time a I  
debug an SDL app I’m a bit troubled by the the state of the bottom of  
the stack.

From what I can tell, a pure Carbon and C implementation of the  
event code using ReceiveNextEvent would be entirely doable; the  
major obstacle I can see is that most of the code in video/quartz  
would need to be moved over from Cocoa calls to their Carbon  
equivalents, but that’s not a huge amount of code in total, and I  
notice various places where ‘Core’ calls are already inter-mixed with  
the Cocoa code; eg calls to CGL functions in QDL\_QuartzGL.m.

(…looking over the code some more …)

In fact, SDL\_QuartzVideo.m seems to confirm my point even more than I  
realized: most of the key code is CoreGraphics, Quickdraw or CSG  
calls, with a very few NSxxx calls inter-mixed, and at one least  
comment indicating a work-around for a bug where Cocoa and  
CoreGraphics don’t synchronize something correctly.

By the way, I love Cocoa, but all the things it’s designed for (and  
good at) are irrelevant to SDL, and some of the things SDL wants to  
do are ‘unusual’ in Cocoa.

I would be happy to do more investigation on this, and the bulk of  
coding, but of course there’s a lot of time and effort invested in  
the current Cocoa-based code, so I won’t bother unless the SDL mac  
contributors (I guess that means Eric Wing and Ryan Gordon, and  
anyone else with a strong opinion) agree this is worth pursuing, at  
least as an experiment. I would love to see SDLmain.m and the  
applicationDidFinishLaunching magic die a quick, but maybe no one  
else is that bothered 🙂

Please let me know if this might be contemplated (for 1.3.x,  
naturally), and what criteria would be necessary for people to  
consider using it. I don’t think a basic proof-of-concept would take  
long to get off the ground, but I’d sooner not spend time on it, if  
people think this is a silly idea.

Regards,  
James

---

<div class="post-metadata">

**Author:** ![Christian\_Walther](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/christian_walther/32/322_2.png) [@Christian\_Walther](https://discourse.libsdl.org/u/Christian_Walther)\
**Post date:** [April 5, 2006, 5:38pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/2 "2006-04-05T17:38:25Z")

</div>

James Turner wrote:

> Why do the OS-X bits of SDL use Cocoa, instead of Carbon?

I guess the reason is that the people who worked on it are fluent in  
Cocoa, can deal with CoreFoundation and CoreGraphics-like stuff, but are  
utterly unfamiliar with Carbon. At least, that’s the case for me. 🙂

However, I think there _is_ a Carbon backend, and I faintly remember  
hearing that it works on Mac OS X. I’ve never used it, though. The guy  
to ask about this would be Anders F. Bj?rklund  
([Skaffa nya Galaxy Z Flip6 eller Fold6. Skal och hörlurar på köpet. | Mobil, bredband & Tv](http://www.algonet.se/~afb/libsdl/)). I guess you should be able to find  
out some things by reviewing his postings to this mailing list:  
[http://search.gmane.org/?query=&email=afb%40algonet.se&group=gmane.comp.lib.sdl&sort=date](http://search.gmane.org/?query=&email=afb%40algonet.se&group=gmane.comp.lib.sdl&sort=date)

> …Quickdraw…

The QuickDraw stuff should probably be replaced some time, see  
[Quartz driver compiler warnings on Intel Macs (10.4 SDK?) · Issue #31 · libsdl-org/SDL · GitHub](https://bugzilla.libsdl.org/show_bug.cgi?id=108) .

> …at one least comment indicating a work-around for a bug where  
> Cocoa and CoreGraphics don’t synchronize something correctly.

I’m not sure if anyone has recently checked whether that bug is still  
present in the versions of Mac OS X we support (10.2+). There were even  
some workarounds for bugs in Mac OS X Public Beta in the code until  
recently…

> I would love to see SDLmain.m and the applicationDidFinishLaunching  
> magic die a quick, but maybe no one else is that bothered 🙂

I’ve gotten used to being able to hook up my menus in Interface Builder,  
use Cocoa alerts and file dialogs, and even display auxiliary windows  
using Cocoa - would we lose these abilities (or any of their ease) in a  
Carbon backend?

-Christian

---

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 5, 2006, 6:03pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/3 "2006-04-05T18:03:26Z")

</div>

> The QuickDraw stuff should probably be replaced some time, see  
> [https://bugzilla.libsdl.org/show\_bug.cgi?id=108](https://bugzilla.libsdl.org/show_bug.cgi?id=108) .

Interesting, and worth thinking about for sure.

> > …at one least comment indicating a work-around for a bug where  
> > Cocoa and CoreGraphics don’t synchronize something correctly.
> 
> I’m not sure if anyone has recently checked whether that bug is still  
> present in the versions of Mac OS X we support (10.2+). There were  
> even  
> some workarounds for bugs in Mac OS X Public Beta in the code until  
> recently…

I wasn’t sure what versions of OS-X were officially supported, but as  
you say, it’s likely some work-arounds are no longer needed.

> > I would love to see SDLmain.m and the applicationDidFinishLaunching  
> > magic die a quick, but maybe no one else is that bothered 🙂
> 
> I’ve gotten used to being able to hook up my menus in Interface  
> Builder,  
> use Cocoa alerts and file dialogs, and even display auxiliary  
> windows  
> using Cocoa - would we lose these abilities (or any of their ease)  
> in a  
> Carbon backend?

This could be made to work in Carbon, but I hadn’t planned on it -  
if you’re using Interface Builder and Cocoa, why are you using SDL in  
the first place?! My concern is all the open-source projects that  
don’t have or want any Mac specific code. If you’re simply using SDL  
as a helper within Cocoa, I think something is amiss anyway;  
wouldn’t a regular NSView and Cocoa event handling suit you better  
than the SDL event model? As it stands right now, your Cocoa  
auxiliary windows are running in a very odd way, since the top-level  
NSApplication event loop is bypassed by the SDLmain code.

I suspect the real solution if you care about using SDL that way  
would be an explicit Cocoa video device that creates a specialised  
NSView subclass, and then extracts events from that view explicitly.  
This is basically what the current code in video/quartz does, but I  
think a video backend designed for the job would be simpler, since it  
could rely on more Cocoa things operating ‘normally’, and presumably  
wouldn’t need the video mode switching or full-screen support, unless  
you are doing something /really/ odd with SDL.

That said, I don’t think it’s a good tradeoff for every cross-  
platform SDL app on OS-X to need Cocoa, given the resulting issues,  
purely to support this use case. Of course, if all your care about is  
showing some alerts and NIB-based dialogs, that can be done from  
Carbon easily enough, but you still need another solution for Windows  
and Linux and …

## H&H JamesOn 5 Apr 2006, at 18:38, Christian Walther wrote:

Some people, when confronted with a problem, think ?I know, I?ll use  
regular expressions.? Now they have two problems.

---

<div class="post-metadata">

**Author:** ![Christian\_Walther](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/christian_walther/32/322_2.png) [@Christian\_Walther](https://discourse.libsdl.org/u/Christian_Walther)\
**Post date:** [April 5, 2006, 9:25pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/4 "2006-04-05T21:25:04Z")

</div>

James Turner wrote:

> > I’ve gotten used to being able to hook up my menus in Interface Builder,  
> > use Cocoa alerts and file dialogs, and even display auxiliary windows  
> > using Cocoa - would we lose these abilities (or any of their ease) in a  
> > Carbon backend?
> 
> This could be made to work in Carbon, but I hadn’t planned on it - if  
> you’re using Interface Builder and Cocoa, why are you using SDL in the  
> first place?!

Alerts and file dialogs aren’t provided by SDL, so I have to do these in  
platform-specific code - I’m using Cocoa on Mac OS X, GTK on X11, win32  
on Windows. About the menus - I just think it’s nice to be able to do  
things like “Open saved game…” from a menu on the Mac, since the menu  
bar is there anyway. The auxiliary window I mentioned just displays  
debug information while I’m developing on my home platform Mac OS X, it  
isn’t used in the final product that also runs on Linux and Windows.

> My concern is all the open-source projects that don’t have or want any Mac specific code.

Just out of curiosity, what’s the problem with those and the Cocoa  
backend? They don’t have to use SDLMain.nib or anything if they don’t  
want to. As long as they can deal with SDL wrapping up their main()  
function (which AFAIK also happens on other platforms), everything  
should be fine?

> As it stands right now, your Cocoa auxiliary windows are running  
> in a very odd way, since the top-level NSApplication event loop is  
> bypassed by the SDLmain code.

I actually wondered about this too, but it seems to work well - the  
periodic [NSApp nextEventMatchingMask: …] and subsequent [NSApp  
sendEvent:event] done through SDL\_PollEvent() seems to be sufficient to  
keep the window alive. Again, I’m not depending on this in a released  
product - I just tried it and was pleasantly surprised that it worked.

> That said, I don’t think it’s a good tradeoff for every cross-platform  
> SDL app on OS-X to need Cocoa, given the resulting issues, purely to  
> support this use case.

Care to elaborate on what your “issues” are? I haven’t had any with the  
few Mac-agnostic SDL apps I’ve compiled.

> Of course, if all your care about is showing some alerts and NIB-based dialogs, that can be done from Carbon easily enough

OK, that’s actually what I expected, so I’m not too worried about this.  
Is any initialization work other than setting up an NSAutoreleasePool  
required to use Cocoa in a Carbon app? (That’s a rhetorical question, I  
should be able to find the answer to that myself easily.)

-Christian\> On 5 Apr 2006, at 18:38, Christian Walther wrote:

---

<div class="post-metadata">

**Author:** ![Brad\_Beveridge](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/b487fb/32.png) [@Brad\_Beveridge](https://discourse.libsdl.org/u/Brad_Beveridge)\
**Post date:** [April 10, 2006, 9:36pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/5 "2006-04-10T21:36:27Z")

</div>

Christian Walther \<cwalther gmx.ch\> writes:

> Just out of curiosity, what’s the problem with those and the Cocoa  
> backend?
> 
> > That said, I don’t think it’s a good tradeoff for every cross-platform  
> > SDL app on OS-X to need Cocoa, given the resulting issues, purely to  
> > support this use case.
> 
> Care to elaborate on what your “issues” are? I haven’t had any with the  
> few Mac-agnostic SDL apps I’ve compiled.

I have just been grappling with this recently myself. I am using Lisp (SBCL)  
and SDL on OS X. On all other platforms, this is reasonably easy because SDL is  
plain C for the most part. However the Cocoa wrapper on OS X causes headaches,  
partly because the SDL wrapper expects to exit when SDL\_main returns. In an  
interactive Lisp environment you want to bring a window up, do some stuff  
(perhaps interactivly) maybe close the window and start again. All without  
leaving the Lisp image. Python needs to jump through similar hoops - infact I  
copied the way that Python does it.  
In short, I think that any non-basic-c applications of SDL on OS X will probably  
suffer because of the Cocoa backend.

Assuming Carbon makes all or most of this pain go away, then I would really like  
to see a Carbon backend & would be willing to help where I can.

Cheers  
Brad

---

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 10, 2006, 10:10pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/6 "2006-04-10T22:10:41Z")

</div>

> I have just been grappling with this recently myself. I am using  
> Lisp (SBCL)  
> and SDL on OS X. On all other platforms, this is reasonably easy  
> because SDL is  
> plain C for the most part. However the Cocoa wrapper on OS X  
> causes headaches,  
> partly because the SDL wrapper expects to exit when SDL\_main  
> returns. In an  
> interactive Lisp environment you want to bring a window up, do some  
> stuff  
> (perhaps interactivly) maybe close the window and start again. All  
> without  
> leaving the Lisp image. Python needs to jump through similar hoops
> 
> - infact I  
> copied the way that Python does it.  
> In short, I think that any non-basic-c applications of SDL on OS X  
> will probably  
> suffer because of the Cocoa backend.

Urk, that’s a pretty nasty scenario. I dread to think what the code  
you borrowed from Python looks like. And yes, this sort of thing is  
exactly why I think it would be good for SDL-OSX to fit better with  
the SDL event / mainloop model. Based on what you describe, I think  
this should work ‘better’ with Carbon: all the event processing  
would happen inside SDL\_PollEvent, so you could run as many loops as  
you like. Of course I don’t know what the Lisp environment on OS-X is  
doing with the system event queue, but any issues should be the same  
for Cocoa or Carbon.

I think it would be interesting to at least prototype this - I’m  
inclined to do so as a mod to 1.2.9 (so I can test existing SDL apps  
with a drop-in framework replacement). I’ll try to assemble my  
thoughts on doing the prototype, and post them tomorrow.

## Regards, JamesOn 10 Apr 2006, at 22:36, Brad Beveridge wrote:

There is no such thing as a humble opinion.

---

<div class="post-metadata">

**Author:** ![Brad\_Beveridge](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/b487fb/32.png) [@Brad\_Beveridge](https://discourse.libsdl.org/u/Brad_Beveridge)\
**Post date:** [April 10, 2006, 10:22pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/7 "2006-04-10T22:22:22Z")

</div>

> SDL\_PollEvent, so you could run as many loops as you like. Of course I don’t  
> know what the Lisp environment on OS-X is doing with the system event queue,  
> but any issues should be the same for Cocoa or Carbon.  
> SBCL, at least, really only uses console i/o, so I don’t think that it  
> should interfere with the event loop at all. Though, I haven’t used  
> Cocoa really at all before - so who knows? 🙂

> I think it would be interesting to at least prototype this - I’m inclined to  
> do so as a mod to 1.2.9 (so I can test existing SDL apps with a drop-in  
> framework replacement). I’ll try to assemble my thoughts on doing the  
> prototype, and post them tomorrow.  
> Cool. I’d be willing to test.

BradOn 4/10/06, James Turner wrote:

---

<div class="post-metadata">

**Author:** ![Eric\_Wing](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@Eric\_Wing](https://discourse.libsdl.org/u/Eric_Wing)\
**Post date:** [April 11, 2006, 1:04am UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/8 "2006-04-11T01:04:55Z")

</div>

First, I thought somebody already recently fixed up the Carbon  
backend. You should look into that. I did not do anything for the  
Xcode build system for this, but I think it might be in the autoconf  
system. This will hopefully save you work and testing.

Second, I personally like the Cocoa stuff for many of the same reasons  
Christian mentioned. Though SDL code has a focus on being portable,  
but I don’t think it’s intended to prevent you from polishing your app  
to better work with the native host. (I think I recall Ryan recently  
added something to allow drag-and-drop onto the app’s dock icon.) SDL  
is also a very good candidate for (rapid) prototyping where  
portability may not be the primary concern. How many times has the  
WindowID hack been asked about for Windows? I think the SDLMain.m  
architecture gives OS X developers a lot of this kind of flexibility.

More to my paranoia than hard facts, I also worry about Carbon  
support. I get the feeling Apple only keeps it around for Adobe and  
Microsoft and would kill it if not for those two. As the platform  
continues to evolve, we’re seeing a lot of enhancements and updates to  
Cocoa, but Carbon seems to lag behind. And on their 5th major release,  
there continue to be rough spots where Cocoa and Carbon don’t mix.  
This all worries me a bit. On flip side, Cocoa continues to get cool  
enhancements which makes developing in Cocoa much easier. For example  
QuickTimeKit was a very welcome addition. I hope to see the same for  
CoreAudio and other components. I would hope that future iterations of  
SDL might be able to leverage this stuff to shrink the code base and  
make it easier to write and maintain.

But I am not familiar with your specific issues so maybe Carbon is a  
better fix. However, is it possible to modify/fix the SDLmain to  
better handle the exit condition mentioned?

I should also add the disclaimer that I’m not the guy who wrote and  
maintains most of the OS X code base. I’ve been doing only minor code  
maintenance things. Most of my efforts have been trying to keep the  
build system, binaries, and documentation up-to-date. So my opinion is  
less important 🙂 However, I find that for what code I do end  
modifying, it’s been easier to work with Cocoa than Carbon.

Thanks,  
Eric

---

<div class="post-metadata">

**Author:** ![Brad\_Beveridge](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/b487fb/32.png) [@Brad\_Beveridge](https://discourse.libsdl.org/u/Brad_Beveridge)\
**Post date:** [April 11, 2006, 1:34am UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/9 "2006-04-11T01:34:07Z")

</div>

I ought to add that I have very little experience with Lisp or OS X  
(hence both Carbon and Cocoa). For more info on what Python had to  
do, and I had to copy, Google for CPSEnableForegroundOperation

Cheers  
Brad

---

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 11, 2006, 9:45am UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/10 "2006-04-11T09:45:52Z")

</div>

> First, I thought somebody already recently fixed up the Carbon  
> backend. You should look into that. I did not do anything for the  
> Xcode build system for this, but I think it might be in the autoconf  
> system. This will hopefully save you work and testing.

Thanks, I’ll look into that.

> Second, I personally like the Cocoa stuff for many of the same reasons  
> Christian mentioned. Though SDL code has a focus on being portable,  
> but I don’t think it’s intended to prevent you from polishing your app  
> to better work with the native host. (I think I recall Ryan recently  
> added something to allow drag-and-drop onto the app’s dock icon.) SDL  
> is also a very good candidate for (rapid) prototyping where  
> portability may not be the primary concern. How many times has the  
> WindowID hack been asked about for Windows? I think the SDLMain.m  
> architecture gives OS X developers a lot of this kind of flexibility.

I’ll address this point below.

> More to my paranoia than hard facts, I also worry about Carbon  
> support. I get the feeling Apple only keeps it around for Adobe and  
> Microsoft and would kill it if not for those two. As the platform  
> continues to evolve, we’re seeing a lot of enhancements and updates to  
> Cocoa, but Carbon seems to lag behind. And on their 5th major release,  
> there continue to be rough spots where Cocoa and Carbon don’t mix.  
> This all worries me a bit. On flip side, Cocoa continues to get cool  
> enhancements which makes developing in Cocoa much easier. For example  
> QuickTimeKit was a very welcome addition. I hope to see the same for  
> CoreAudio and other components. I would hope that future iterations of  
> SDL might be able to leverage this stuff to shrink the code base and  
> make it easier to write and maintain.

This could quickly get subjective, but I’ll try to keep it factual.  
The issue is that Carbon and Cocoa are not symmetric equals on OS-X -  
Cocoa is much more high level, and has many, many features that make  
it ideal for writing rich, modern applications. Unsurprisingly, this  
means all the new Apple applications are written in Cocoa, and hence  
people often assume Carbon is a temporary shim to keep Adobe and  
Microsoft Office working. To compare with Linux, Cocoa would be like  
Qt, and Carbon would be like Motif.

This is fundamentally not the case.

The correct analogy is that Cocoa is like Qt, but Carbon is  
equivalent to X11. Sure, you can write a desktop app in raw X11, but  
very few people would. But, if SDL used Qt on Linux, instead of raw  
X11 calls, I think everyone would agree that would also be strange.  
Indeed, if SDL did use gtk or Qt, the main loop would have exactly  
the same problem mapping to the SDL event API that the Cocoa backend  
does!

And sure, if the Linux port used Qt instead of raw X11, it would be  
easy to make SDL interoperate with GUI written in Qt … but that’s  
not a good enough reason to make SDL use Qt on linux.

Significantly, the Qt OS-X port (which I use every day at work) is  
written in nothing but Carbon. And Cocoa itself uses Carbon  
internally for things like drawing the menus. So you need to think of  
Carbon not as an orphaned, legacy GUI toolkit, but as the low-level  
access to the OS, that bypasses most of the heavy-weight (and  
powerful) abstractions of Cocoa. It just so happens that, like X11,  
it also contains some rather ancient GUI things (the original Mac  
Toolbox). Those might go away one day (indeed, Carbon HIViews  
obsolete them), but those aren’t the pieces of Carbon that SDL needs  
to use, any more than SDL for X11 uses the Xt widgets.

Keep in mind that the entire ‘critical’ heart of video/quartz/  
quartz\_video.m is basically written in CoreGraphics calls anyway;  
these aren’t going to change in a Carbon version. Other pieces of the  
OS-X code already use Carbon calls, so I think that makes your  
paranoia a bit hard to justify.

Btw, in the entire discussion above, you can also replace ‘Qt’ with  
‘MFC’ or ‘.Net’ and ‘X11’ with ‘the Win32 platform SDK’. Again, SDL  
for windows uses the platform calls directly, not MFC or any other  
high-level abstraction. And whatever Microsoft might like, the Win32  
platform API is not going anywhere - the .net runtime sits on top of  
it, it does not replace it.

To take the example of CoreAudio, Apple may one day produce a lovely,  
easy to use wrapper for it in Cocoa - but does that help SDL? A  
cocoa API would undoubtedly be full of rich, persistent objects,  
where you define ‘NSSample’ or ‘NSChannel’ objects, hold onto them  
and generally uses them as long-lived objects. None of which is  
relevant to the SDL API, and cannot be exposed through it. The  
current CoreAudio API is low-level, and a bit brutal in places, but  
provides very precise control - exactly what SDL needs.

Now, to address the issue of using SDL for prototype apps, or showing  
Carbon or Cocoa UI, I present the following document:

[http://developer.apple.com/documentation/Cocoa/Conceptual/](http://developer.apple.com/documentation/Cocoa/Conceptual/)  
CarbonCocoaDoc/carboncocoa.pdf

In summary, since 10.2, the event loops are bound together. You can  
write a C function which calls into Cocoa code, and do absolutely  
anything you like - load NIBs, show NSViews, etc.

Right, that’s enough from me. Once i have something to show for a de-  
Cocoa-ified SDL, I’ll post more.  
JamesOn 11 Apr 2006, at 02:04, E. Wing wrote:

---

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 11, 2006, 11:35am UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/11 "2006-04-11T11:35:14Z")

</div>

> > First, I thought somebody already recently fixed up the Carbon  
> > backend. You should look into that. I did not do anything for the  
> > Xcode build system for this, but I think it might be in the autoconf  
> > system. This will hopefully save you work and testing.

I’ve just looked over the code in video/maccommon, video/macrom and  
video/macdsp (I’m assuming this is what you are referring to, since I  
can’t see anything else). It brings back happy memories of  
programming the original toolbox, Quickdraw and DrawSprocket.  
However, it is essentially an antique at this point - while there are  
#ifdefs to make it build on OS-X, it’s still using APIs that are  
being killed off. Every second toolbox call is deprecated. The code  
still has 68k assembler glue in places!

So something else to consider might be removing these backends from  
CVS, since I can’t imagine many people are targeting OS-9 these days.  
Or 68k macs 🙂

Regards,  
JamesOn 11 Apr 2006, at 10:45, James Turner wrote:

---

<div class="post-metadata">

**Author:** ![Gregory\_Smith](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/50afbb/32.png) [@Gregory\_Smith](https://discourse.libsdl.org/u/Gregory_Smith)\
**Post date:** [April 11, 2006, 1:25pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/12 "2006-04-11T13:25:46Z")

</div>

> So something else to consider might be removing these backends from CVS,  
> since I can’t imagine many people are targeting OS-9 these days. Or 68k macs  
> 🙂

I’m trying to target Mac OS 9! Even having some limited success, although  
I can’t get OpenGL to work (nor testgl), nor hardware surfaces.

No 68k though 🙂

Is there a maintainer for SDL/Mac OS 9?

GregoryOn Tue, 11 Apr 2006, James Turner wrote:

---

<div class="post-metadata">

**Author:** ![Mattias\_Karlsson](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@Mattias\_Karlsson](https://discourse.libsdl.org/u/Mattias_Karlsson)\
**Post date:** [April 11, 2006, 1:38pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/13 "2006-04-11T13:38:37Z")

</div>

> So something else to consider might be removing these backends from CVS,  
> since I can’t imagine many people are targeting OS-9 these days.

Well, I for one would like to keep it around, even if don’t have any  
Apple hardware at all. Just judging by the number of games listed as  
available for MacOS, they apear to be more than those targeting \*BSD 😉  
And I hope I am far from the only SDL user who is more concerned over  
writing fun and playable games than the framerate…

> Or 68k macs 🙂

Now THIS is a whole other story…On Tue, 11 Apr 2006, James Turner wrote:

---

<div class="post-metadata">

**Author:** ![Brad\_Beveridge](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/b487fb/32.png) [@Brad\_Beveridge](https://discourse.libsdl.org/u/Brad_Beveridge)\
**Post date:** [April 17, 2006, 2:52pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/14 "2006-04-17T14:52:24Z")

</div>

Just a follow up from my situation. Writing the SDL backend in Carbon  
will not solve the problem where the window doesn’t come to the front,  
and doesn’t accept events. The issue is that running out of a Lisp  
(or any console based interpreter) image does not work properly, you  
need to make calls like.  
void osx\_foreground ()  
{  
ProcessSerialNumber processSerialNum;  
GetCurrentProcess(&processSerialNum);  
CPSEnableForegroundOperation (&processSerialNum, 0, 0, 0, 0);  
SetFrontProcess(&processSerialNum);  
}  
This creates a dock icon and lets the SDL window (either Carbon or  
Cocoa) come to the fore.

Cheers  
Brad

This was hard to google for, so here are some keywords:  
OS X OSX Carbon Cocoa Window fore foreground Lisp interpreter SDL OpenGL dockOn 4/11/06, Mattias Karlsson wrote:

> On Tue, 11 Apr 2006, James Turner wrote:
> 
> > So something else to consider might be removing these backends from CVS,  
> > since I can’t imagine many people are targeting OS-9 these days.
> 
> Well, I for one would like to keep it around, even if don’t have any  
> Apple hardware at all. Just judging by the number of games listed as  
> available for MacOS, they apear to be more than those targeting \*BSD 😉  
> And I hope I am far from the only SDL user who is more concerned over  
> writing fun and playable games than the framerate…
> 
> > Or 68k macs 🙂
> 
> Now THIS is a whole other story…
> 
> * * *
> 
> SDL mailing list  
> SDL at [libsdl.org](http://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)

---

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 17, 2006, 3:10pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/15 "2006-04-17T15:10:50Z")

</div>

> void osx\_foreground ()  
> {  
> ProcessSerialNumber processSerialNum;  
> GetCurrentProcess(&processSerialNum);  
> CPSEnableForegroundOperation (&processSerialNum, 0, 0, 0, 0);  
> SetFrontProcess(&processSerialNum);  
> }  
> This creates a dock icon and lets the SDL window (either Carbon or  
> Cocoa) come to the fore.

The better fix for this is to make a proper bundle, then the  
CPSEnableForegroundOperation hack should no longer be necessary. But  
it’s useful to have it for debugging and other edge cases.

JamesOn 17 Apr 2006, at 15:52, Brad Beveridge wrote:

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [April 17, 2006, 4:29pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/16 "2006-04-17T16:29:12Z")

</div>

> Right, that’s enough from me. Once i have something to show for a de-  
> Cocoa-ified SDL, I’ll post more.

Make sure you work with CVS code, it’s been totally revamped from 1.2.9.  
Also, I’d appreciate it if you have a chance to look at all the deprecated  
API’s that we get warnings for on Mac OS X 10.4

Thanks!  
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

---

<div class="post-metadata">

**Author:** ![James\_Turner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@James\_Turner](https://discourse.libsdl.org/u/James_Turner)\
**Post date:** [April 17, 2006, 4:49pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/17 "2006-04-17T16:49:50Z")

</div>

> Make sure you work with CVS code, it’s been totally revamped from  
> 1.2.9.  
> Also, I’d appreciate it if you have a chance to look at all the  
> deprecated  
> API’s that we get warnings for on Mac OS X 10.4

I made a start on this (I have the basic event mapping from Carbon  
Events through to SDL\_PrivateFoo written) but got side-tracked by  
more pressing things and the general lack of enthusiasm.

In terms of deprecated APIs, well that’d be because the ‘Cocoa’ code  
still goes back to Quickdraw for non-OpenGL mode! As I understand it,  
the calls to LockPortBits and the like just bring the WindowServer  
and CoreGraphics screeching to a halt, with the drawing pipeline  
being flushed and every overlapping window being recomposited in  
funky ways. Presumably this is worse on Tiger, where rendering as  
well as compositing is pipelined through to the hardware.

In the long-term, the approach I would like to take (and the only I  
can think of that is compatible with the future direction of  
CoreGraphics) is to always make SDL software drawing render to a  
memory buffer, and to create a CGImage from that each time a buffer  
swap is requested - this is also what Apple suggest for direct access  
to the rendering context. Even on the slowest iMac or iBook, such  
approach should be plenty fast enough, and means the client code  
using SDL can see a nice palettised or 24-bit, randomly-sized  
surface, with or without alpha. An additional advantage would be that  
any upscale during the blit can be filtered in hardware by CoreGraphics.

Anyway, once I get back to this, I’ll start doing it against CVS, not  
1.2.9, and also track down which deprecated functions are easy to get  
rid of, and which require the (somewhat intrusive!) change describe  
above.

H&H  
JamesOn 17 Apr 2006, at 17:29, Sam Lantinga wrote:

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [April 17, 2006, 5:15pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/18 "2006-04-17T17:15:22Z")

</div>

> In the long-term, the approach I would like to take (and the only I  
> can think of that is compatible with the future direction of  
> CoreGraphics) is to always make SDL software drawing render to a  
> memory buffer, and to create a CGImage from that each time a buffer  
> swap is requested - this is also what Apple suggest for direct access  
> to the rendering context. Even on the slowest iMac or iBook, such  
> approach should be plenty fast enough, and means the client code  
> using SDL can see a nice palettised or 24-bit, randomly-sized  
> surface, with or without alpha. An additional advantage would be that  
> any upscale during the blit can be filtered in hardware by CoreGraphics.

> Anyway, once I get back to this, I’ll start doing it against CVS, not  
> 1.2.9, and also track down which deprecated functions are easy to get  
> rid of, and which require the (somewhat intrusive!) change describe  
> above.

Thanks!  
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [April 17, 2006, 9:24pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/19 "2006-04-17T21:24:56Z")

</div>

> In the long-term, the approach I would like to take (and the only I can  
> think of that is compatible with the future direction of CoreGraphics)  
> is to always make SDL software drawing render to a memory buffer, and to  
> create a CGImage from that each time a buffer swap is requested - this  
> is also what Apple suggest for direct access to the rendering context.  
> Even on the slowest iMac or iBook, such approach should be plenty fast  
> enough, and means the client code using SDL can see a nice palettised or  
> 24-bit, randomly-sized surface, with or without alpha. An  
> additional advantage would be that any upscale during the blit can be  
> filtered in hardware by CoreGraphics.

I think this is the right way to go, but every time I sit down to attack  
it, my spirit is broken by the Apple documentation. 🙂

I think this is way more important than moving from Cocoa to Carbon…it  
happens to work fine on Tiger, but the performance implications for  
Leopard are still an unknown, so this has to get rewritten in the next  
six months or so, I think.

–ryan.

---

<div class="post-metadata">

**Author:** ![Ulrich\_von\_Zadow](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/u/aca169/32.png) [@Ulrich\_von\_Zadow](https://discourse.libsdl.org/u/Ulrich_von_Zadow)\
**Post date:** [April 17, 2006, 9:53pm UTC](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210/20 "2006-04-17T21:53:26Z")

</div>

James Turner wrote:

> > Make sure you work with CVS code, it’s been totally revamped from 1.2.9.
> > 
> > Also, I’d appreciate it if you have a chance to look at all the deprecated
> > 
> > API’s that we get warnings for on Mac OS X 10.4
> 
> I made a start on this (I have the basic event mapping from Carbon  
> Events through to SDL\_PrivateFoo written) but got side-tracked by more  
> pressing things and the general lack of enthusiasm.

Re: ‘general lack of enthusiasm’, I’d like to say that I’ve jumped  
through the hoops nessesary to get something that uses SDL exported to a  
scripting language in Mac OS X and I’d love to see this cleaned up :-).

Regards,

Uli\> On 17 Apr 2006, at 17:29, Sam Lantinga wrote:

[Next page](https://discourse.libsdl.org/t/os-x-carbon-event-handling/13210.md?page=2)