Re: Carbon -> Cocoa
Re: Carbon -> Cocoa
- Subject: Re: Carbon -> Cocoa
- From: Uli Kusterer <email@hidden>
- Date: Thu, 23 Aug 2018 05:19:05 +0200
On 16. Aug 2018, at 13:54, Casey McDermott <email@hidden> wrote:
> I am curious, are there other developers on this list working on conversions
> from C++ Carbon to Cocoa?
>
> If so, how is it going?
I've worked on a few in previous jobs, it was definitely a lot of work, but
most of that was due to the lack of MVC separation in most existing C++
codebases, and due to (at the time) only limited support for co-habitation of
Cocoa and Carbon code in the same app, so we had to branch and develop two apps
(the shipping Carbon and the work-in-progress Cocoa app), because certain
things (like mixing non-modal Cocoa and Carbon windows) were just too buggy.
Luckily most of these ports pre-dated 64 bit (well, pre-dated Apple being
annoying about 32-bit apps), so we could port to Cocoa first, then to 64 bit
from there.
Some of the apps shipped, some got sold to other companies and those companies
haven't shipped their Cocoa versions yet ... so I can't claim a 100% success
rate.
In retrospect, for most of them I'd say the best approach is to just tear off
the view layer, wrap all the remaining code in some sort of API, then swap out
the UI layers. We basically did that for Game Capture and that was our fastest
port.
In the ones where we attempted to port parts over, there was usually a huge gap
between the easy beginnings and later parts. Replacing file panels, standard
alerts, cursors etc. with Cocoa calls, replacing all modal windows with Cocoa
windows etc. was fairly straightforward. Actually moving over the menu bar
required taking the main event loop along, and only *then* would non-modal
Cocoa windows work properly.
You can mix modeless Cocoa and Carbon windows in a RAEL-based app or even
WNE-based app, and they will sort of work, but it's only suitable for testing
both versions of a window, nothing you would want to ship. Too many subtle
focus and window-ordering bugs in daily use.
That said, NSSelectorFromString() let us make a pretty neat translation scheme
between ObjC menu item selectors and HICommands, and many older C++ frameworks
actually behave more like ObjC's -validateMenuItem: than modern Carbon did, so
in one case I was very happy an app's codebase hadn't been brought up to speed
with Carbon best practices, because I could just hollow out TCL classes and
back them with ObjC objects and all was fine.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden