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/
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:
