SDL, OS X, and Carbon

There’s still a couple carbon calls in SDL2:

Undefined symbols for architecture i386:
"_HideMenuBar", referenced from:
_Cocoa_SetDisplayMode in libSDL2.a(SDL_cocoamodes.o)
"_KBGetLayoutType", referenced from:
_Cocoa_HandleKeyEvent in libSDL2.a(SDL_cocoakeyboard.o)
"_LMGetKbdType", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)
_Cocoa_HandleKeyEvent in libSDL2.a(SDL_cocoakeyboard.o)
"_ShowMenuBar", referenced from:
_Cocoa_SetDisplayMode in libSDL2.a(SDL_cocoamodes.o)
_Cocoa_QuitModes in libSDL2.a(SDL_cocoamodes.o)
"_TISCopyCurrentKeyboardLayoutInputSource", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)
"_TISGetInputSourceProperty", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)
"_kTISPropertyUnicodeKeyLayoutData", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)

This isn’t priority, but would be nice to get them eventually removed.

[>] Brian

Hi,On Thu, Jul 26, 2012 at 7:03 AM, Brian Barnes wrote:

There’s still a couple carbon calls in SDL2:

Undefined symbols for architecture i386:
"_HideMenuBar", referenced from:
_Cocoa_SetDisplayMode in libSDL2.a(SDL_cocoamodes.o)
"_KBGetLayoutType", referenced from:
_Cocoa_HandleKeyEvent in libSDL2.a(SDL_cocoakeyboard.o)
"_LMGetKbdType", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)
_Cocoa_HandleKeyEvent in libSDL2.a(SDL_cocoakeyboard.o)
"_ShowMenuBar", referenced from:
_Cocoa_SetDisplayMode in libSDL2.a(SDL_cocoamodes.o)
_Cocoa_QuitModes in libSDL2.a(SDL_cocoamodes.o)
"_TISCopyCurrentKeyboardLayoutInputSource", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)
"_TISGetInputSourceProperty", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)
"_kTISPropertyUnicodeKeyLayoutData", referenced from:
_Cocoa_InitKeyboard in libSDL2.a(SDL_cocoakeyboard.o)

This isn’t priority, but would be nice to get them eventually removed.

There isn’t any trace of HIToolbox calls being removed in 10.8, at least
not those Text Input Sources (TIS) functions (which are added in 10.5):

https://developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html

Any particular reason for removing them in SDL?

  • Jiang

Jjgod Jiang wrote:

There isn’t any trace of HIToolbox calls being removed in 10.8, at least
not those Text Input Sources (TIS) functions (which are added in 10.5):

https://developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html

Any particular reason for removing them in SDL?

Just future proofing. Carbon was depreciated in Mountain Lion, and it’s
been many years of Apple telling us to stop using it. It’s probably got
a limited life span, and it would be nice to be able to remove the
carbon framework. You can see in the future no longer being able to put
these in the App Store. It’s a dead API walking :slight_smile:

Again, as I said, not a priority, but there doesn’t look like a great
deal left to handle. It might be the time in the transition to 2.0 to
pull them out.

[>] Brian

Hi,

Just future proofing. Carbon was depreciated in Mountain Lion, and it’s
been many years of Apple telling us to stop using it. It’s probably got a
limited life span, and it would be nice to be able to remove the carbon
framework. You can see in the future no longer being able to put these in
the App Store. It’s a dead API walking :slight_smile:

Carbon is not deprecated in Mountain Lion, Carbon Core is.

See:
https://developer.apple.com/library/mac/#releasenotes/General/APIDiffsMacOSX10_8/Carbon.html
https://developer.apple.com/library/mac/#releasenotes/Miscellaneous/CarbonCoreDeprecations/_index.html

HIToolbox is part of Carbon umbrella framework, but not part of Carbon Core.
The functions you listed all belongs to HIToolbox, as I said in my previous
reply.

Again, as I said, not a priority, but there doesn’t look like a great deal
left to handle. It might be the time in the transition to 2.0 to pull them
out.

I agree that the Carbon Menu bar API usage should be replaced with Cocoa
correspondence. But the TIS APIs are actually the latest in that matter,
no better replacement (no replacement at all) has been provided by Apple.

  • JiangOn Thu, Jul 26, 2012 at 4:22 PM, Brian Barnes wrote:

Jiang wrote:

Just future proofing. Carbon was depreciated in Mountain Lion, and it’s
been many years of Apple telling us to stop using it. It’s probably got a
limited life span, and it would be nice to be able to remove the carbon
framework. You can see in the future no longer being able to put these in
the App Store. It’s a dead API walking :slight_smile:

Carbon is not deprecated in Mountain Lion, Carbon Core is.

See:
https://developer.apple.com/library/mac/#releasenotes/General/APIDiffsMacOSX10_8/Carbon.html
https://developer.apple.com/library/mac/#releasenotes/Miscellaneous/CarbonCoreDeprecations/_index.html

HIToolbox is part of Carbon umbrella framework, but not part of Carbon Core.
The functions you listed all belongs to HIToolbox, as I said in my previous
reply.

Sure, but obviously all of Apple’s forward development is going forward with Carbon, there’s really nothing but maintenance on carbon and hasn’t been anything new for years now. Which parts of it they feel like depreciating today doesn’t mean they won’t do more of it tomorrow.

Anyway, as I said, low priority.

Again, as I said, not a priority, but there doesn’t look like a great deal
left to handle. It might be the time in the transition to 2.0 to pull them
out.

I agree that the Carbon Menu bar API usage should be replaced with Cocoa
correspondence. But the TIS APIs are actually the latest in that matter,
no better replacement (no replacement at all) has been provided by Apple.

Well, that’s a whole different problem. I’m a hypocrite on a lot of this, I’m still maintaining carbon code, but it was my desire to stop doing that which lead me to discover these bits. Again, not a big deal, just thought I’d point it out.

[>] Brian> On Thu, Jul 26, 2012 at 4:22 PM, Brian Barnes <@Brian_Barnes> wrote: