Carbon -> Cocoa

Discussion:

Carbon -> Cocoa

Casey McDermott

2018-08-16 11:54:59 UTC

I am curious, are there other developers on this list working on conversions
from C++ Carbon to Cocoa?

If so, how is it going?

Thanks,

Casey McDermott
Turtle Creek Software
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Jeremy Hughes

2018-08-16 12:32:46 UTC

Permalink

We found it very difficult. This was for a large C++ Carbon application.

We’re now rewriting in Swift + Cocoa, starting from scratch.

Jeremy

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent

Steve Mills

2018-08-16 13:14:10 UTC

Permalink

Post by Casey McDermott
I am curious, are there other developers on this list working on conversions
from C++ Carbon to Cocoa?
If so, how is it going?

At my previous job, we started doing that soon after I started. This was an enormous app with, jeez, I forget, like 150 dialogs? There were 4 of us that could do Mac dev, plus still keep up with normal release cycles. 3 years later, all but 1 of those 4 were laid off because the new owner moved the company to Colorado to be with his other bought-up company. In those 3 years, we made a small dent in the Carbon->Cocoa, and that was only because 1 guy would work nights and weekends coming up with ways to automate parts of the process.

We'd continually run into weird problems when trying to have Carbon and Cocoa windows up at the same time. But that was quite a few major OS versions ago. I'll just say it's not a fun process, especially when it's this many years after the "Carbon is dead" announcement. My choice would be to do it as a rewrite.

--
Steve Mills
Drummer, Mac geek

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Sean McBride

2018-08-16 13:48:46 UTC

Permalink

Post by Casey McDermott
I am curious, are there other developers on this list working on conversions
from C++ Carbon to Cocoa?

By now, Cocoa may be the new Carbon.

If you haven't switched to Cocoa after all these years, and if your app is large, I'd wait to see what happens with Marzipan.

Sean

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Jeremy Hughes

2018-08-16 13:56:46 UTC

Permalink

Post by Sean McBride
By now, Cocoa may be the new Carbon.

The crucial difference is that Cocoa supports 64-bit applications, and Carbon doesn’t.

Post by Sean McBride
If you haven't switched to Cocoa after all these years, and if your app is large, I'd wait to see what happens with Marzipan

We don’t have time to wait for Marzipan - Apple are dropping support for 32-bit applications after Mojave.

Jeremy

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email s

Stephane Sudre

2018-08-18 18:19:46 UTC

Permalink

It might be the new Carbon once:

- there is ABI stability in Swift. This could be not before late 2019.

- the new APIs are only available in Swift. Is Swift NIO a hint this
is coming sooner than expected? I don't know. I don't use networking
frameworks.

Regarding the complexity of porting from C++ Carbon to Cocoa, there's
also the important question of what your minimum OS target is.

Maybe one of the reasons why you kept a Carbon version alive so long
is that the application needs to keep working on older OS versions.

Porting to OS X 10.10 or later is not the same thing as porting to
10.6 or later for instance.

Post by Sean McBride

Post by Casey McDermott
I am curious, are there other developers on this list working on conversions
from C++ Carbon to Cocoa?

By now, Cocoa may be the new Carbon.
If you haven't switched to Cocoa after all these years, and if your app is large, I'd wait to see what happens with Marzipan.
Sean
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/dev.iceberg%40gmail.com

--
Packaging Resources - http://s.sudre.free.fr/Packaging.html
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Mike Crawford

2018-08-18 19:45:08 UTC

Permalink

"older OS versions", porting to 10.6 or later vs. 10.10 or later:

I at first intended all the drivers I write for my clients to work on
Snow Leopard 10.6, but after actually attempting to do so I settled
upon supporting El Capitan 10.11, sometimes just Sierra 12.6.

There are some occasional but quite serious problems with new APIs
appearing during a minor release so you can't just set your Deployment
Target to a major release's first drop. To get drivers to build - and
I expect Cocoa code as well - one must take _great_ care to check
Apple's doc for most if not all of your API calls to determine when
they first appeared.

For one particular client's USB function driver we actually had three
kernel extensions. I at first planned to package this in just one
kext bundle but because of time pressure shipped them as three
separate ones.

Two of the drivers had Deployment Targets of 10.12, the third 10.11.
I had some manner of good reason for doing it this way, but I've just
been up all night nosediving deeply into Wikipedia and all manner of
Epic Talk Page Flame Wars so just now I'm too thrashed to actually
remember what it was.

Mike Crawford
Portland Custom Software Development
http://soggywizards.com
***@soggywizards.com

One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Charles Srstka

2018-08-19 22:37:45 UTC

Permalink

Post by Mike Crawford
I at first intended all the drivers I write for my clients to work on
Snow Leopard 10.6, but after actually attempting to do so I settled
upon supporting El Capitan 10.11, sometimes just Sierra 12.6.
There are some occasional but quite serious problems with new APIs
appearing during a minor release so you can't just set your Deployment
Target to a major release's first drop. To get drivers to build - and
I expect Cocoa code as well - one must take _great_ care to check
Apple's doc for most if not all of your API calls to determine when
they first appeared.
For one particular client's USB function driver we actually had three
kernel extensions. I at first planned to package this in just one
kext bundle but because of time pressure shipped them as three
separate ones.
Two of the drivers had Deployment Targets of 10.12, the third 10.11.
I had some manner of good reason for doing it this way, but I've just
been up all night nosediving deeply into Wikipedia and all manner of
Epic Talk Page Flame Wars so just now I'm too thrashed to actually
remember what it was.

Recent version of Xcode make this much easier to deal with, though, thanks to the @available attribute (#available in Swift). If you have your warnings set up correctly, this will result in a warning when you use an unavailable API outside of an @available block. In Swift, it’s a compiler error rather than a warning, so you’re basically forced to do this.

Charles

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

Alastair Houghton

2018-08-20 07:52:43 UTC

Permalink

Slightly off topic, but drivers are definitely the worst case, as sometimes you need to use the old SDKs to build them, and the Xcode team is, in my view, somewhat overenthusiastic about dropping support for them… the Deployment Target setting isn’t always sufficient. I do wonder, actually, how much thought is given to those of us who have KEXTs to build when pondering whether or not to drop an SDK from Xcode. There have been some other pain points in recent macOS versions relating to KEXTs also (changes to driver signing, the recent blocking of third-party KEXTs until the user visits System Preferences to confirm their installation, etc.). One would almost think Apple didn’t want us writing low-level code…

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.n

Jens Alfke

2018-08-20 16:51:25 UTC

Permalink

Post by Stephane Sudre
- there is ABI stability in Swift. This could be not before late 2019.
- the new APIs are only available in Swift. Is Swift NIO a hint this
is coming sooner than expected?

By “NIO” do you mean the new Network.framework? They did only demo the Swift API at WWDC, but it has a full C API too. (Which makes sense, since part of its goal is to drag C developers away from the POSIX sockets API.)

Post by Stephane Sudre
I don't know. I don't use networking frameworks.

You should consider adopting one at some point. There are several benefits they provide that aren’t available with POSIX APIs, like faster connection startup, and transparently switching between WiFi and cellular. (Stuart Cheshire’s various WWDC talks go into detail.)

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.n

Jean-Daniel

2018-08-21 07:28:05 UTC

Permalink

Post by Jens Alfke

Post by Stephane Sudre
- there is ABI stability in Swift. This could be not before late 2019.
- the new APIs are only available in Swift. Is Swift NIO a hint this
is coming sooner than expected?

No, NIO is basically Netty in swift (and can use Network.framework under the hood): https://github.com/apple/swift-nio <https://github.com/apple/swift-nio>

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This

Mike Crawford

2018-08-21 09:09:35 UTC

Permalink

Post by Jens Alfke
drag C developers away from the POSIX sockets API

Don't be dismayed if you're not happy with NIO:

There are numerous APIs that do such dragging, for example the
ADAPTIVE Communications Environment (ACE):

http://www.dre.vanderbilt.edu/~schmidt/ACE.html

Mozilla's NetScape Portable Runtime, The Electric Magic Company's
ZooLib is C++ and MIT Licensed:

http://www.em.net/portfolio/2000/12/zoolib.html

I expect there are many others.

Mike Crawford
--
Mike Crawford ***@gmail.com

The Global Computer Industry Index: http://soggy.jobs/computer
(It's getting more and more global every day now.)

Post by Jens Alfke

Post by Stephane Sudre
- there is ABI stability in Swift. This could be not before late 2019.
- the new APIs are only available in Swift. Is Swift NIO a hint this
is coming sooner than expected?

No, NIO is basically Netty in swift (and can use Network.framework under the hood): https://github.com/apple/swift-nio <https://github.com/apple/swift-nio>
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-i

Alastair Houghton

2018-08-21 15:33:47 UTC

Permalink

Post by Mike Crawford

Post by Jens Alfke
drag C developers away from the POSIX sockets API

There are numerous APIs that do such dragging, for example the
http://www.dre.vanderbilt.edu/~schmidt/ACE.html <http://www.dre.vanderbilt.edu/~schmidt/ACE.html>
Mozilla's NetScape Portable Runtime, The Electric Magic Company's
http://www.em.net/portfolio/2000/12/zoolib.html <http://www.em.net/portfolio/2000/12/zoolib.html>
I expect there are many others.

One of the problems with many of those libraries is that they tend to insist that your software use their own event loop implementation(s). Admittedly it’s been a while since I looked at ACE (for example), but NIO is at least going to be using the same mechanisms that you’d use anyway in a macOS or iOS application.

Anyway, when looking at an async networking library, you want to check that it will integrate nicely with the set of platforms you care about, using the kind of event dispatch you require in your application. So, for instance, it’s not so good on macOS or iOS if its event dispatcher is based on select(), (e)poll() or kqueue() because what you really want on macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, you’ll end up having to use threading to run the network library’s event loops on background threads, which for an async networking library kind of defeats the point IMO. (Of course, you may want to have event loops running in threads or thread pools for performance reasons, but one of the real benefits of async networking libraries is that you can use them from the main thread in your GUI code.)

Likewise, on Windows you’re going to want something that uses MsgWaitForMultipleObjectsEx() or similar, and on Linux you definitely want epoll() support.

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to g

Jens Alfke

2018-08-22 16:53:31 UTC

Permalink

Post by Alastair Houghton
So, for instance, it’s not so good on macOS or iOS if its event dispatcher is based on select(), (e)poll() or kqueue() because what you really want on macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, you’ll end up having to use threading to run the network library’s event loops on background threads, which for an async networking library kind of defeats the point IMO.

It does mean you have to spin up one background thread to sit and wait for events; but that's not a big hardship. You still get the scalability benefits of event-driven I/O, vs. having to use one thread per socket the old-fashioned way.

(NSURLSession and Network.framework are doing the same thing under the hood, after all.)

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email s

Alastair Houghton

2018-08-22 17:40:49 UTC

Permalink

Post by Jens Alfke

Well, yes and no. If the network library works that way, it’ll fire its callbacks on the background thread, which makes life awkward if you’re interacting with the UI as you’ll need to forward to the main thread and it may in some cases for you to use synchronisation when you wouldn’t have needed to. Much better to use a library that’s properly integrated with the native run loop and that therefore doesn’t end up calling your code on a background thread.

Post by Jens Alfke
(NSURLSession and Network.framework are doing the same thing under the hood, after all.)

Are they? kqueue() supports monitoring of fds, Mach ports and timers, so there’s really no reason that CFRunLoop would have to spawn a background thread just to monitor some file descriptors. As far as I can tell, the current CFRunLoop implementation is built on top of GCD, which sadly we don’t have the source code for; I don’t have time to reverse engineer it right now to see whether or not GCD does in fact spawn background thread(s) for this or not, but I see no particular reason it should have to.

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This

Jens Alfke

2018-08-22 18:32:31 UTC

Permalink

Post by Alastair Houghton
Well, yes and no. If the network library works that way, it’ll fire its callbacks on the background thread, which makes life awkward if you’re interacting with the UI

Then you write glue around the callbacks that dispatches them on a selectable dispatch queue. (Which you'll want to do anyway, because who wants to work with C callbacks?)

Post by Alastair Houghton
Much better to use a library that’s properly integrated with the native run loop and that therefore doesn’t end up calling your code on a background thread.

To be pedantic, both NSURLSession and Network.framework are based on dispatch queues, not runloops. They call delegate code on the dispatch queue assigned to the task.

Anyway, I agree with you that using a library integrated with OS facilities is better than one that isn't. But developers using non-HTTP protocols, or coding in C/C++, don't have that luxury … not until they can move up to iOS 12 / macOS 10.14 as their deployment SDKs. In my case that's probably about three years away. :(

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ge

Alastair Houghton

2018-08-23 10:06:58 UTC

Permalink

Post by Jens Alfke

Post by Alastair Houghton
Well, yes and no. If the network library works that way, it’ll fire its callbacks on the background thread, which makes life awkward if you’re interacting with the UI

Then you write glue around the callbacks that dispatches them on a selectable dispatch queue. (Which you'll want to do anyway, because who wants to work with C callbacks?)

You’ll take a performance hit doing that; not sure how large, but some, for sure. Not necessarily a big issue for most apps, but worth bearing in mind.

Post by Jens Alfke

Post by Alastair Houghton
Much better to use a library that’s properly integrated with the native run loop and that therefore doesn’t end up calling your code on a background thread.

To be pedantic, both NSURLSession and Network.framework are based on dispatch queues, not runloops. They call delegate code on the dispatch queue assigned to the task.

Run loops are based on dispatch queues too, these days.

Post by Jens Alfke
Anyway, I agree with you that using a library integrated with OS facilities is better than one that isn't. But developers using non-HTTP protocols, or coding in C/C++, don't have that luxury … not until they can move up to iOS 12 / macOS 10.14 as their deployment SDKs. In my case that's probably about three years away. :(

It’s worth checking whether any of the other libraries have dispatch queue or run loop integration. It wouldn’t surprise me if some of them do — it isn’t much of a stretch, once you have an async I/O library, to add the necessary support. That was sort of the point I was making, namely that it’s worth looking carefully at the available options to see which have the platform support you need to make them interoperate well with your platform specific code (without necessarily being platform specific themselves).

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-

Tor Arne Vestbø

2018-08-24 19:01:48 UTC

Permalink

Post by Alastair Houghton
Run loops are based on dispatch queues too, these days.

Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and I these behave as normal sources without any sign of dispatch queues as far as I can tell?

I did experiment with using dispatch sources instead, but these can not be recursed, which was a showstopper unfortunately. I would have loved to use the queue debugging feature (backtrace recording) to tie posted Qt events back to their origin.

Cheers,
Tor Arne

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Alastair Houghton

2018-08-24 19:16:59 UTC

Permalink

Post by Tor Arne VestbÃ¸

Post by Alastair Houghton
Run loops are based on dispatch queues too, these days.

You can see the code here

https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html <https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html>

Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re very tightly integrated… CFRunLoop appears to be using dispatch queues for timers, and there’s clearly integration such that dispatched calls will run within the run loop.

It does still have its own separate run loop sources, observers and so on, I believe; they all talk to the run loop itself via a set of Mach ports.

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This emai

Tor Arne Vestbø

2018-08-24 19:26:12 UTC

Permalink

Post by Alastair Houghton

Post by Tor Arne VestbÃ¸

Post by Alastair Houghton
Run loops are based on dispatch queues too, these days.

You can see the code here
https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html
Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re very tightly integrated… CFRunLoop appears to be using dispatch queues for timers, and there’s clearly integration such that dispatched calls will run within the run loop.
It does still have its own separate run loop sources, observers and so on, I believe; they all talk to the run loop itself via a set of Mach ports.

Right, that matches my understanding. In a sense dispatch queues are based on runloops as well, so your description of “tightly integrated” is accurate 😊

Cheers,
Tor Arne
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.n

Saagar Jha

2018-08-22 20:42:46 UTC

Permalink

Sent from my iPhone

Post by Alastair Houghton

Post by Jens Alfke

Post by Jens Alfke
(NSURLSession and Network.framework are doing the same thing under the hood, after all.)

libdispatch is open source: https://github.com/apple/swift-corelibs-libdispatch

Post by Alastair Houghton
; I don’t have time to reverse engineer it right now to see whether or not GCD does in fact spawn background thread(s) for this or not, but I see no particular reason it should have to.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com

Alastair Houghton

2018-08-23 10:28:29 UTC

Permalink

libdispatch is open source: https://github.com/apple/swift-corelibs-libdispatch <https://github.com/apple/swift-corelibs-libdispatch>
I recall hearing from someone at Apple that they basically ported GCD to Linux for the Swift Linux release ... have you looked whether that code might give any clues about what may be happening on macOS?

Interesting. That isn’t quite the same libdispatch that’s used on the macOS by the look of things, but it does appear to have things merged across from the macOS version. It looks, from a cursory examination, as if the macOS functionality is built on top of a kernel “work queue” implementation that lives inside the non-open-source pthread.kext. (I’m sure I’m not the only one to have noticed that quite a bit of functionality has been moved from open source parts of the macOS to closed-source libraries and KEXTs; personally I find this a disappointing development, as it makes debugging and developing software harder if it’s impossible to inspect the source code.)

Anyway, from what I can see it seems highly unlikely that there will be any background threads to monitor file descriptors, at least on the macOS.

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive

Uli Kusterer

2018-08-23 03:30:33 UTC

Permalink

Post by Alastair Houghton
Are they? kqueue() supports monitoring of fds, Mach ports and timers, so there’s really no reason that CFRunLoop would have to spawn a background thread just to monitor some file descriptors. As far as I can tell, the current CFRunLoop implementation is built on top of GCD, which sadly we don’t have the source code for; I don’t have time to reverse engineer it right now to see whether or not GCD does in fact spawn background thread(s) for this or not, but I see no particular reason it should have to.

I recall hearing from someone at Apple that they basically ported GCD to Linux for the Swift Linux release ... have you looked whether that code might give any clues about what may be happening on macOS?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This

Uli Kusterer

2018-08-23 03:25:36 UTC

Permalink

Post by Stephane Sudre
Regarding the complexity of porting from C++ Carbon to Cocoa, there's
also the important question of what your minimum OS target is.
Maybe one of the reasons why you kept a Carbon version alive so long
is that the application needs to keep working on older OS versions.
Porting to OS X 10.10 or later is not the same thing as porting to
10.6 or later for instance.

+1. I think we pretty much only supported whatever the current OS version was in our Cocoa ports. We had the Carbon versions in parallel that supported the older OSes, so it wasn't as if users would notice. There were significant improvements over macOS releases. Particularly 10.2 and 10.8, IIRC. I haven't had to Carbon-port much later than that.

... well, that's not true, I did a rough Carbon-to-Cocoa port for a friend about a year ago, but that was just getting the basics to work and solving the hard issues (like adding certain modifications he needed to standard views to Cocoa, in a Cocoa way), and hasn't shipped yet.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

James Walker

2018-08-16 16:44:38 UTC

Permalink

James Walker

2018-08-16 17:04:48 UTC

Permalink

Post by Casey McDermott
I am curious, are there other developers on this list working on conversions
from C++ Carbon to Cocoa?
If so, how is it going?

(Sorry about the empty post; the list server eats my messages if I try
to post in HTML.)

I'm working on it. I have converted all windows and menus to Cocoa.
What remains is converting to NSApplicationMain, getting rid of Carbon
Events being sent to window event targets, and other miscellaneous things.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Casey McDermott

2018-08-17 13:56:10 UTC

Permalink

The OP is as late as he could be (no offense meant).

We started 4 years ago. The previous update from OS 9 to OS X Carbon took about
3 months. Moving from PPC to Intel was about a month (helped by the fact we
already byte-swap for the Windows version). So, we figured it would take a year or so.

The original plan was to subcontract the GUI work, since we assumed there would
be many experienced contractors who had already done Carbon to Cocoa ports.
Meanwhile, we updated the back end in parallel: converting PowerPlant's LArray to std::vector,
replacing the database, etc.

4 different contractors tried to Cocoa-ize, and got nowhere. Another used QT and
reached the first draw payment, then stopped. We started asking people for prior conversion
samples. The few who had actually finished one all wanted $100K+ to do another.

So, we started the GUI work in-house 2 years ago. Completion estimates keep receding.

Casey McDermott
Turtle Creek Software
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Casey McDermott

2018-08-17 16:45:22 UTC

Permalink

Post by Casey McDermott

By now, Cocoa may be the new Carbon. if your app is large, I'd wait to see what happens with Marzipan.

This is true, and very scary. Makes us wonder about sunk cost fallacy.

It's annoying but not dreadful to link C++ code into Cocoa via Objective-C. Throw in Swift and future APIs
that are Swift-dominated, and it becomes harder. How soon will it be impossible?

Our app has 6 or 8 programmer-years of C++ cross-platform business logic. Accounting software is complicated.
Rewriting that in another language would be hard work, and tons of testing. More than Mac sales would justify,
so it would be time to go Windows-only or just fold.

Casey McDermott
Turtle Creek Software

--------------------------------------------
On Thu, 8/16/18, Sean McBride <***@rogue-research.com> wrote:

Subject: Re: Carbon -> Cocoa
To: "Casey McDermott" <***@turtlesoft.com>, cocoa-***@lists.apple.com
Date: Thursday, August 16, 2018, 9:48 AM

On Thu, 16 Aug 2018 11:54:59

Post by Casey McDermott
I am

curious, are there other developers on this list working on
conversions

Post by Casey McDermott
from C++ Carbon to

Cocoa?

If
you haven't switched to Cocoa after all these years, and

Sean

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.ne

Jeremy Hughes

2018-08-17 17:10:47 UTC

Permalink

Our app has 6 or 8 programmer-years of C++ cross-platform business logic. Accounting software is complicated. Rewriting that in another language would be hard work, and tons of testing. More than Mac sales would justify, so it would be time to go Windows-only or just fold.

If you have a cross-platform business logic, it’s presumably separate from the UI and separate from Carbon - so you don’t need to rewrite it.

Personally, I would rewrite the UI. You can try to Cocoa-fy it in a gradual process, but that didn’t work out for us, and it doesn’t seem like it’s working out for you.

Jeremy

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This em

Jens Alfke

2018-08-17 18:12:39 UTC

Permalink

It's annoying but not dreadful to link C++ code into Cocoa via Objective-C. Throw in Swift and future APIs
that are Swift-dominated, and it becomes harder. How soon will it be impossible?

Never. I can't think of a single (nontrivial) language that doesn't have a foreign-function mechanism to call into C code. It's vital to have this, since much of a higher-level language's runtime support code and libraries are written in lower-level languages.

Also, even if 'Marzipan' is released with the goal of eventually replacing AppKit (which is speculative), it will be in a similar position to Cocoa in 2001 — regardless of how good it is, the apps that _must_ be kept running on the Mac, like Office, PhotoShop, Final Cut, Ableton Live, still use the old language/framework and won't be rewritten any time soon. That means Apple must keep supporting the old framework for years and years and years. (17 years and counting, in the case of Carbon…)

—Jens [who worked in the OS team at Apple during the OS 9 / OS X transition]
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This ema

Alastair Houghton

2018-08-20 07:43:15 UTC

Permalink

By now, Cocoa may be the new Carbon. if your app is large, I'd wait to see what happens with Marzipan.

This is true, and very scary. Makes us wonder about sunk cost fallacy.

I don’t actually think it’s very likely that Marzipan will replace Cocoa (except possibly for things like calculator, to-do list and notes type apps). My impression is that it’s really a way to run iOS apps, which typically have a much simpler UI and far fewer features, on the macOS. That makes sense for some types of software, for sure, but I think larger packages are likely to want to stick with AppKit.

It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.

Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” and then use C++ wherever you wish.

Throw in Swift and future APIs that are Swift-dominated, and it becomes harder. How soon will it be impossible?

It’ll never be impossible, but you’re right at the moment you’ll need either an Objective-C or vanilla C API to wrap your C++. I’d tentatively suggest that it’s likely that Swift will develop some means of interfacing more directly with C++ code in the future, which should make this easier rather than harder.

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.ne

Jens Alfke

2018-08-20 16:44:28 UTC

Permalink

Post by Alastair Houghton
I’d tentatively suggest that it’s likely that Swift will develop some means of interfacing more directly with C++ code in the future, which should make this easier rather than harder.

There are tools like SWIG for generating inter-language glue code; I don’t know if it supports C++ and Swift, though…

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.n

Casey McDermott

2018-08-17 17:37:03 UTC

Permalink

We are slogging along with Cocoa. The app has final appearance now, but
there are many small details to complete. We won't be done by Mojave release but
probably can finish before the next one.

Of course, the C++ business logic doesn't need any changes. The concern is,
how long will it last? Seems like the future is an entirely Swift-based API
that replaces Objective-C Cocoa in 5 years, with no easy way to link to other languages.
The payback isn't big enough to write software with only a 5 year lifetime.

Casey McDermott
Turtle Creek Software

--------------------------------------------
On Fri, 8/17/18, Jeremy Hughes <***@virginmedia.com> wrote:

Subject: Re: Carbon -> Cocoa
To: "Casey McDermott" <***@turtlesoft.com>
Cc: "Cocoa Dev" <cocoa-***@lists.apple.com>
Date: Friday, August 17, 2018, 1:10 PM

Post by Casey McDermott
Our app has 6 or 8 programmer-years of

C++ cross-platform business logic. Accounting software is
complicated. Rewriting that in another language would be
hard work, and tons of testing. More than Mac sales would
justify, so it would be time to go Windows-only or just
fold.

If you have a
cross-platform business logic, it’s presumably separate
from the UI and separate from Carbon - so you don’t need
to rewrite it.

Personally,
I would rewrite the UI. You can try to Cocoa-fy it in a
gradual process, but that didn’t work out for us, and it
doesn’t seem like it’s working out for you.

Jeremy

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This

Andreas Falkenhahn

2018-08-17 17:43:05 UTC

Permalink

Post by Casey McDermott
We are slogging along with Cocoa. The app has final appearance now, but
there are many small details to complete. We won't be done by Mojave release but
probably can finish before the next one.
Of course, the C++ business logic doesn't need any changes. The concern is,
how long will it last?

Well, I'd guess that C++ is pretty future-proof. If you want to be even safer,
go back to plain C. Given the wide array of open-source libraries written in C
and used by Apple, I think it's pretty certain that they can never ever drop C
support. Even if the higher level stuff changes every once in a while now, there'll
always be a way to call into C code from it. At least that's what I'd predict.
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Jerome Krinock

2018-08-18 00:52:44 UTC

Permalink

Post by Andreas Falkenhahn

Post by Casey McDermott
Of course, the C++ business logic doesn't need any changes. The concern is,
how long will it last?

Well, I'd guess that C++ is pretty future-proof.

Swift is itself written in C++ :)

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net

Mike Crawford

2018-08-18 15:58:14 UTC

Permalink

A while back I offered to port a PowerPlant Carbon app to Cocoa for
sometime who posted it on one of the contract programming sites -
ucode or some such.

We agreed on his total price but he absolutely _refused_ to agree on
pre-agreed milestones. I always put such milestones in the contract,
as well as mailing back and forth with my clients as to what each
milestone should actually be, my pay for reaching each milestone as
well as what ACCEPTANCE TESTS my code must pass so as to trigger a
payment.

The reason this joker gave for being so obstinate was that he once
paid one of my Friendly Competitors for some networking code WITHOUT
EVEN LOOKING AT IT, that Friendly Competitor bailed, then his next
Friendly Competitor coudn't make sense of the first one's code.

I remain _dumbstruck_ that anyone at all would either propose, agree
to or actually pay for a milestone without both sides agreeing to the
acceptance tests which are SPECIFIED IN THE CONTRACT.

Don't even get me started.

Just Don't.
--
Mike Crawford ***@gmail.com

The Global Computer Employer Index: http://soggy.jobs/computer
(It's actually starting to get global now.)

Post by Jerome Krinock

Post by Andreas Falkenhahn

Post by Casey McDermott
Of course, the C++ business logic doesn't need any changes. The concern is,
how long will it last?

Well, I'd guess that C++ is pretty future-proof.

Swift is itself written in C++ :)
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com

Jeremy Hughes

2018-08-17 17:51:35 UTC

Permalink

Post by Casey McDermott
Of course, the C++ business logic doesn't need any changes. The concern is,
how long will it last? Seems like the future is an entirely Swift-based API
that replaces Objective-C Cocoa in 5 years, with no easy way to link to other languages.

Core parts of Webkit are written in C++, so I think you’re safe with that.

I haven’t tried to interface between Swift and C++, but I think it’s possible and will probably get easier. You could ask in the Swift forums.

I think ObjC will be around for a while, at least the next ten years.

Jeremy

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This

Saagar Jha

2018-08-19 22:46:51 UTC

Permalink

Saagar Jha

Post by Jeremy Hughes

This isn’t currently possible, and would be a huge undertaking since bridging with C++ essentially requires adding the (complex) semantics of C++ to the bridging language. That being said, I think this is something that the Swift core team was interested in.

Post by Jeremy Hughes
I think ObjC will be around for a while, at least the next ten years.
Jeremy
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com

Guillaume Laurent

2018-08-20 09:53:33 UTC

Permalink

Post by Jeremy Hughes

It’s not currently possible, from what I’ve tried, the best way to do this is to wrap a C++ class in an ObjC++ class.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive

Casey McDermott

2018-08-20 13:27:06 UTC

Permalink

Post by Alastair Houghton

Post by Casey McDermott
It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.

Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” and then use C++ wherever you wish.

That part is easy, and at the beginning we were very optimistic.

The problem is, we already have an MVC architecture written in C++ / PowerPlant.
It has many business logic quirks. We have to link the C++ controllers to Cocoa controllers,
and each C++ view field to a Cocoa control (usually with subtly different behaviors).

Moving anything from Obj-C to C++ objects is easy, because the .mm file can contain both.

Moving back is hard, because C++ can't reference Obj-C classes. We use an
intermediate C++ linker class with void pointers to Obj-C objects in the header.
Then a .mm source file that talks with both.

What used to be controller -> field becomes Cocoa controller -> C++ controller ->
C++ field -> linker -> Cocoa control. The alternative is to rewrite all the business logic
in Cocoa, but that would require a year of testing to get it all right again. Then maintaining
two code bases from here on out.

Post by Alastair Houghton
I’d tentatively suggest that it’s likely that Swift will develop some means of

interfacing more directly with C++ code in the future, which should make this easier rather than harder.

This link says that C++ support is now marked "out of scope" in Swift 3.0:
https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift
I didn't find any mention of future support being planned.

Casey McDermott
Turtle Creek Software
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

T

Alastair Houghton

2018-08-20 13:46:57 UTC

Permalink

Post by Casey McDermott
Moving anything from Obj-C to C++ objects is easy, because the .mm file can contain both.
Moving back is hard, because C++ can't reference Obj-C classes.

It can, but only if it’s either (a) in a .mm file, or (b) prepared to call the Objective-C runtime functions. You can include the Objective-C runtime from a C++ file, and you’ll get all the base types (so, not the Foundation or AppKit types, or any of your own, but you will get “id”, “Protocol”, “Class” and so on), and can make method calls using appropriate Objective-C runtime APIs. I’m not saying either of those would be better than what you’ve done, mind.

Post by Casey McDermott

Post by Alastair Houghton
I’d tentatively suggest that it’s likely that Swift will develop some means of

interfacing more directly with C++ code in the future, which should make this easier rather than harder.
https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift
I didn't find any mention of future support being planned.

Sure, that may well be the case. I can’t imagine anyone thinking it isn’t a desirable feature for Swift to have at some point, though, and Swift being Open Source, any of a very large pool of people and companies could work on this if they wanted. I think it’s inevitable that Swift will at some point develop better support for C++ objects.

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narki

Uli Kusterer

2018-08-23 03:19:05 UTC

Permalink

Post by Casey McDermott
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 (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net