How future "safe" is Carbon - anyone knows?

[MISV]

What I mean is - if I build a solution on Carbon/Lazarus today - can I risk it will suddenly not work? And/or are people here betting on Cocoa implementation then being ready? (I am fine with not being able to build 64bit for OSX for many years or having access to new APIs)

[jwdietrich]

Unfortunately, the situation with the Carbon API isn't quite clear.

Basically, it is a deprecated API that dates back to 1998. Its aim was to facilitate the transition from classical Mac OS to Mac OS X. The native API Cocoa was and is preferred by Apple, and with the introduction of Mac OS X 10.8 (Mountain Lion) Carbon was deprecated. However, the Carbon APIs are still accessible to developers and, as it is currently understood, all Carbon applications will run even in future, but the APIs will no longer be updated. Interestingly, Apple made Carbon also available on iOS, although there wasn't a need for porting applications from classical Mac OS.

If you don't use too much OS-dependent code you will be fine with the abstract LCL-based API offered by Lazarus. The Cocoa widget set is getting better and better and it received considerable extensions in the recent past. Therefore I expect it to be easy to switch the widgetset once Cocoa is sufficiently supported. Certain small applications already run fine with the Cocoa widgetset.

[skalogryz]

Apple made Carbon also available on iOS, although there wasn't a need for porting applications from classical Mac OS.

How's that? Or actually, what should be considered part of Carbon?

Are CoreXXX frameworks carbon (i.e. CoreGraphics). They're rather treated as part of Cocoa as well.
Quartz 2d? But it is considered (declared by Apple) to be part of CoreGraphics.

I'd say it's more clear to use framework names: AppKit, UIKit ... etc rather than high-level "Cocoa" and "Carbon". Besides iOS is not Cocoa, it's CocoaTouch

...hmm... there's umbrella Carbon.framework but is there Cocoa.framework?

[felipemdc]

What I mean is - if I build a solution on Carbon/Lazarus today - can I risk it will suddenly not work? And/or are people here betting on Cocoa implementation then being ready? (I am fine with not being able to build 64bit for OSX for many years or having access to new APIs)

I am working in LCL-Cocoa. Please test your application with it and report problems in the BTS. Please attach in bug reports minimal applications reproducing the problem. That's my proposed answer to your Carbon question: Test Cocoa, report bugs.

[felipemdc]

Interestingly, Apple made Carbon also available on iOS, although there wasn't a need for porting applications from classical Mac OS.

That's because many APIs are available only in Carbon with no Cocoa alternative. Part of those are supported in 64-bits and part isn't. Also many Cocoa parts were written on top of Carbon APIs, so they had no choice but to include them. And they deprecated only part of Carbon, not all of it. But still, they deprecated a large part of it.

[Trenatos]

I know this is an old thread, but it's still a valid question, one I have myself right now.

My biggest issues with Cocoa is that looking at the Wiki, it's not completely implemented, and I know from testing that some things just work differently between the two.

I can't just select Cocoa and expect it to actually work the same (Write once, compile maybe?). Is anyone actively working on the Cocoa implementation?

[dbannon]

I have an application, tomboy-ng, which is cross platform, Linux, Windows and Mac

I advise users, at present, to use the 32bit version on the Mac but do release a 64bit Cocoa version. I note that a number of things don't work as expected =

Mac 64bit Cocoa - is experimental, it has several known issues and probably more. Known ones include ... unable to display trayicon. Printing fails and copying into and out of the application fails.

https://wiki.gnome.org/Apps/Tomboy/tomboy-ng/BugsAndIssues

I have had to restructure things to ensure the crossplatform-ness does not require too many ifdefs. On a more positive note, the way it is now, I can switch between carbon and cocoa just by changing compiler options. And same code base works on Linux and Windows too. About seven thousand lines of code.

Davo

 

[Trenatos]

Carbon's been working very well for me, but I'm pretty sure Apple has restricted Carbon to 32bit, and are now showing warnings for applications that aren't 64bit, so it really is time to look for a solution.

Unfortunately.. I don't know what that solution is.

Cocoa doesn't work right, and afaik none of the others look native.

[Phil]

Carbon's been working very well for me, but I'm pretty sure Apple has restricted Carbon to 32bit, and are now showing warnings for applications that aren't 64bit, so it really is time to look for a solution.

Unfortunately.. I don't know what that solution is.

Cocoa doesn't work right, and afaik none of the others look native.

The forthcoming Mojave (10.14) is the last version of macOS to support 32-bit apps. Period. That's been discussed elsewhere on this forum.

The time to move to Cocoa was probably 5-6 years ago when there was still some air left in desktop app development. Microsoft was actually a bit late to the transition, moving Office on Mac to Cocoa in 2011 and going 64-bit only in 2016. The first commit to the Lazarus Cocoa widgetset was May 2008, so it certainly got off to the right start. My prediction this last winter was 1-2 years for a stable Cocoa widgetset for LCL.

Some production software like QGIS and Microsoft Remote Desktop do use Qt libraries since these apps are cross-platform. But for smaller, non-production hobby apps Qt probably is not the right choice. So I guess I agree with you: there is no solution short of rewriting the UI portion of an app using Cocoa directly as described here (ProjectXC):

https://macpgmr.github.io

[marcov]

So I guess I agree with you: there is no solution short of rewriting the UI portion of an app using Cocoa directly as described here (ProjectXC):

https://macpgmr.github.io

Well, or just think different, and go to windows ? 

[Trenatos]

Man, there's a $3000 bounty for a fully working Cocoa implementation, and still not done... Not a good sign.

http://wiki.lazarus.freepascal.org/Bounties

[Phil]

Man, there's a $3000 bounty for a fully working Cocoa implementation, and still not done... Not a good sign.

http://wiki.lazarus.freepascal.org/Bounties

When that was posted 6 months ago or so, I suggested something to the effect that the bounty was too vague and too ambitious. Just the demo app alone would be huge and really should be provided by the poster with the post. (Actually, it doesn't even make much sense - how do you test every widget? Every property? Every method?)

And while that sum might seem large for a project like Lazarus, for someone with the requisite skills to actually finish this amorphous thing that's called a widgetset, it's not very much.

[Trenatos]

I get that. I'm a software developer by trade. $3k only gets you so far, but for an otherwise volunteer-only project that's a decent sum.

I don't have the skills needed to work on it, I wouldn't even know where to start, bounty or not.

As for testing every property, method, etc. that's what unit-testing is for.

If we can't get movement with a $3k bounty to not write from scratch, but only finish Cocoa, I don't feel hopeful about using Lazarus for Mac in the future  :/

I contribute to other open source projects already, but I've no idea how I could help with this.

[Phil]

As for testing every property, method, etc. that's what unit-testing is for.

I don't see Lazarus unit tests anywhere. You mean those would need to be done too?

[Thaddy]

As for testing every property, method, etc. that's what unit-testing is for.

I don't see Lazarus unit tests anywhere. You mean those would need to be done too?

Well actually YES. Luckily the compiler team writes unit tests.......<sigh and grumpy  >
I still do not understand the lack of testing in Lazarus. (But somehow it turns out OK, that is by accident!)