Re: Carbon -> Cocoa

[Uli Kusterer]

On 22. Aug 2018, at 19:40, Alastair Houghton  
wrote:
> 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-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

Re: Carbon -> Cocoa

[Uli Kusterer]

On 18. Aug 2018, at 20:19, Stephane Sudre  wrote:
> 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-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

Re: Carbon -> Cocoa

[Uli Kusterer]

On 16. Aug 2018, at 13:54, Casey McDermott  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 (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

Re: is there a way to determine if an NSButton is toggleable ?

[Uli Kusterer]

> On 20. Aug 2018, at 12:04, Guillaume Laurent  
> wrote:
> 
> Hi all,
> 
> 
> For a custom UI I’ve had to write a custom control deriving from NSButton, 
> which highlights itself in a special way on mouse-over. In the method which 
> does the highlighting, I check if the button’s state is either .on or .off, 
> so I know which title or alternateTitle to display. But I realized that, no 
> matter the button's type, the state is always toggled on click. That is, even 
> if the button’s type is set to MomentaryPushIn, the button’s state is toggled 
> after a click. I’d have thought that this was the case only for 
> OnOff/Toggle/Switch… types.
> 
> Since there is no NSButton.type getter, is there a way to determine if the 
> button’s type is toggleable or not ? And what is the reason for switching 
> state for types like MomentaryPushIn ?

 You want to look at the showsStateBy bit field. See:

http://orangejuiceliberationfront.com/building-a-custom-nsbutton/

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

___

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

Re: Carbon -> Cocoa

[Saagar Jha]

Sent from my iPhone

> On Aug 22, 2018, at 10:40, Alastair Houghton  
> wrote:
> 
>> On 22 Aug 2018, at 17:53, Jens Alfke  wrote:
>> 
>>> On Aug 21, 2018, at 8:33 AM, Alastair Houghton 
>>> mailto:alast...@alastairs-place.net>> wrote:
>>> 
>>> 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.
> 
> 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.
> 
>> (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

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

> ; 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-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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com
___

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

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 22, 2018, at 10:40 AM, Alastair Houghton 
>  wrote:
> 
> 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?)

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 17:53, Jens Alfke  wrote:
> 
>> On Aug 21, 2018, at 8:33 AM, Alastair Houghton > > wrote:
>> 
>> 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.

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.

> (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-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

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 21, 2018, at 8:33 AM, Alastair Houghton  
> wrote:
> 
> 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-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