On 8/10/19 2:16:41 AM, Uli Kusterer wrote:
The Cocoa event handling code uses CarbonEvents under the hood. AFAIR, you can
switch to the Cocoa event loop right away, and Carbon windows will just keep
working.
You're saying some interesting things. Given the demise of 32-bit, if this is
still true, maybe the rumored internal 64-bit Carbon implementation might be
deployed behind the scenes to support any portions of Cocoa that still depend on
Carbon. None of that matters for now since obviously I'm doing the port on an
older macOS.
However, also you make me realize that I didn't have it pinned down what "switch
to the Cocoa event loop" might prove to mean. I assumed it meant calling
NSApplicationMain. I did try that already.
Currently if I call NSApplicationMain instead of my regular Carbon event loop
(which is based on ReceiveNextEvent), NSApplicationMain returns immediately. I
don't call NSApplicationMain immedately because there is scads of initialization
that I do without relation to incoming events.
This makes me wonder about NSApplicationLoad, which I do call. It would seem
offhand that one calls NSApplicationLoad only because one is not calling
NSApplicationMain, but now I'm in the position of possibly needing both.
Without calling NSApplicationLoad my Cocoa menu bar does not come up. The
NSBundle loadNibNamed:... call that loads the menus is done shortly after where
NSApplicationLoad is called and seems to depend on it. Maybe there is some
other application initialization structures I need to have in place.
NSApplicationMain "loads the main nib file from the application’s main bundle",
and maybe depends on certain standard things being in place which are not in
place in this app. (I have no main nib file as such.) All of which would then
be part of what "switch to the Cocoa event loop" means. I do have an
AppDelegate but it is not doing much yet.
Incidentally Cocoa menus and modal dialogs are already working, so that is a
sign that Cocoa events are to some degree alive and well.
Modal Cocoa dialogs run their own Cocoa event loop, that's why they work 🙂
Yes I do call runModalForWindow:.
It's also the most tested part of Carbon/Cocoa mixing, as that's what Apple used
for NSOpenPanel & Co. Cocoa menus are Carbon menus under the hood as well, NeXT
had no Mac-style menu bar (they had windows containing the deprecated NSMenuView),
so that was based on the Carbon code from the start. There's even a private
_NSGetCarbonMenu() call that Apple uses internally to get at the MenuRef backing an
NSMenu.
Just be aware that there are various small bugs and issues that make it
impractical to ship an application that mixes modeless Carbon and Cocoa windows,
Well it doesn't really make sense to ship an application with Carbon in it at
this point, since after all getting rid of Carbon very quickly is the reason for
the current porting effort.
mainly to do with window activation/ordering and application
activation/ordering. What works (since that is what AppKit used itself) is
modal Cocoa windows in an otherwise Carbon app. HICocoaView worked for some
views, but not for all of them. Modeless windows will randomly re-order,
sometimes causing the current modal window to end up behind another window and
blocking the user from interacting with it.
Thanks, it is good to know what issues are in store for me.
-Kurt
Cheers,
-- Uli Kusterer
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
