Lazarus

Programming => Widgetset => Carbon => Topic started by: MISV on March 11, 2015, 01:15:46 pm

Title: How future "safe" is Carbon - anyone knows?
Post by: MISV on March 11, 2015, 01:15:46 pm
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)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: jwdietrich on March 11, 2015, 02:37:05 pm
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.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on March 11, 2015, 04:08:50 pm
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 :D

...hmm... there's umbrella Carbon.framework :) but is there Cocoa.framework?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: felipemdc on March 11, 2015, 05:15:29 pm
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.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: felipemdc on March 11, 2015, 05:18:32 pm
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.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 14, 2018, 10:29:29 pm
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?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: dbannon on June 15, 2018, 08:18:45 am
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

 
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 03:42:55 pm
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.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 06:21:20 pm
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
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: marcov on June 15, 2018, 07:27:15 pm
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 ?  >:D
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 07:55:48 pm
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
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 08:31:15 pm
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.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 08:39:50 pm
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.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 08:43:58 pm
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?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on June 15, 2018, 09:10:02 pm
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  >:D >:D >:D >:D>
I still do not understand the lack of testing in Lazarus. (But somehow it turns out OK, that is by accident!)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on June 15, 2018, 09:27:04 pm
I still do not understand the lack of testing in Lazarus. (But somehow it turns out OK, that is by accident!)
Would there be a suggestion on how to create a unit test for LCL-UI part?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 09:40:11 pm
Unit tests should always be done :P
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on June 15, 2018, 09:41:28 pm
Unit tests should always be done
yes. yes.
but how - in cross-platform manner?
(More specifically - looking for tools)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 09:47:17 pm
That's what the :P is about.

I'm looking for unit test tools for FPC myself.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 10:12:22 pm
Unit tests should always be done
yes. yes.
but how - in cross-platform manner?
(More specifically - looking for tools)

Right, I don't know how a unit test would judge the _visual_ correctness of a UI element.

Maybe there could a database of UI element images generated from, say, the win32 widgetset. These would be judged to be "correct". Then automate the generation and capture of the same elements for another widgetset, say, Cocoa. Then do an image classification with a neural net similar to something like this:

http://yann.lecun.com/exdb/mnist

https://github.com/tensorflow/swift-models/tree/master/MNIST

If the classification doesn't identify a UI image, then it would be judged to be insufficiently "correct" visually and require manual (human) inspection. Currently manual inspection is required for all testing of UI elements.

Or something like this could be used as an example:

https://developer.apple.com/documentation/create_ml


Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on June 15, 2018, 10:23:27 pm
as far as I'm aware the major Cocoa issues is of behavioral nature.

I.e. the control is there, but it's not acting the way it's "expected" to act (due to behavior in other widgetset)

Not really sure, how to test for that in automated manner. 
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 10:29:14 pm
as far as I'm aware the major Cocoa issues is of behavioral nature.

I.e. the control is there, but it's not acting the way it's "expected" to act (due to behavior in other widgetset)

Exactly. And misbehavior usually manifests itself in some visual defect. That may be the end of the line, with earlier hiccups and glitches actually being the bug, but if the visual is okay, that usually means everything up to that point in the chain of events is okay. Hence why examining Lazarus itself against a widgetset is so rich in bug production: it's high up on the food chain, as it were.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 10:36:32 pm
@phil, fair enough, I didn't know you meant the visual aspect.

Though there are GUI testing tools, I haven't used them before.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 10:42:12 pm
@phil, fair enough, I didn't know you meant the visual aspect.

Though there are GUI testing tools, I haven't used them before.

Me neither. I don't even do much UI work anymore except Web stuff.

I don't have any idea of how realistic image classification would be for testing UI elements. It might be way more work than it's worth. However, I think you would end up with a set of tools that would be terrifically useful for other problems. Machine learning is becoming so ubiquitous that we would undoubtedly discover other uses once the first Pascal-based app or tool was underway.

If anyone is interested I have TensorFlow working on both macOS and Linux with a Pascal interface. My interest is primarily in numerical classification, not image or natural language classification, so many of the examples don't have much interest for me, but certainly those are two really active areas of investigation.

See this example for something fun:

https://appleinsider.com/articles/18/06/06/this-third-year-wwdc-scholarship-winner-built-an-ml-model-to-recognize-beer-yesterday

Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 15, 2018, 10:47:16 pm
Wow, nice, thanks for sharing Phil.

TF is indeed something I've been tempted to get into.

As for testing, I'm looking into various GUI testing tools, there are several free/open source ones, I'll try getting it set up to test it.

But the core problem remains, Cocoa not being implemented/done.

Anyone have ideas for how we can get movement on that?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on June 15, 2018, 11:01:46 pm
But the core problem remains, Cocoa not being implemented/done.

Anyone have ideas for how we can get movement on that?
Just work on it. 

Preferably you need to take the entire responsibility for the widgetset.
Meaning - you need to constantly work on it, until it's done.
"Until it's done" part is unclear and can span for the next decade.

(Not a joke at all! Windows / Gtk support goes on even today, started 25 years ago?)
For the best paste, it should be at least 2 hours a day. The best time is 4 hours a day.  4-5 days a week.
That's it.

Cocoa will start to shine in no time.

In the absence of enough free time as of this moment, I cannot do any significant progress on Cocoa.
(the next "Cocoa session" for me might be open in October this year)

Be prepare to fight we patches provided.
Sometimes patches come in and they look good, because they're solving a particular problem.
They might be applied (just because they were there long enough w/o anyone looking into them).
But on the long term, they might actually be damaging. Because the implementation was not good enough, causing more problems, than actually solving issues.

So making Cocoa move is easy -> work on it.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: marcov on June 15, 2018, 11:20:03 pm
(Not a joke at all! Windows / Gtk support goes on even today, started 25 years ago?)

GTK1 started around 2000, win32 only started later (at first gtk was used on windows too). Micha Nelissen worked a lot on Win32 afaik. (maybe he created it, I don't know). I'd say 2003ish.

Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 15, 2018, 11:31:35 pm
For the best paste, it should be at least 2 hours a day. The best time is 4 hours a day.  4-5 days a week.
That's it.

Right, that doesn't sound like something that we can reasonably expect a "volunteer" to do. But even with the offered bounty, let's see, say 20 hours per week for 10 weeks, that's $15/hour, or basically the starting pay at a Starbucks.

And I would assume that before you can work productively on a widgetset you would already need to be familiar with the inner workings of LCL and the existing widgetset code. I don't believe there's much documentation for that. Plus for Cocoa a knowledge of AppKit and Objective Pascal dialect would be assumed (those are documented). Meaning you eat that time yourself.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: dbannon on June 16, 2018, 01:58:27 am
Just for the benefit of someone watching who has not tried it. Cocoa does, right now, almost work ! Its not a case of starting from scratch, most of it is there and most of it mostly works.  ;D

To my knowledge, there are some things that don't behave as carbon does, maybe because Cocoa wants to be different, maybe bugs. And a few things that don't work. One real structural issue is memory leaks, if you are used to Lazarus's excellent heaptrc you are very disappointed to find it does not identify the source of a leak on the Mac - that makes fixing a leak very difficult (IMHO). Apparently thats a big job to fix and, obviously, one for someone with a pretty detailed knowledge of the inner workings. If heaptrc was fixed, maybe us mere plebs could address the more mundane issues ?

Davo

 
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 16, 2018, 02:15:21 am
Just for the benefit of someone watching who has not tried it. Cocoa does, right now, almost work ! Its not a case of starting from scratch, most of it is there and most of it mostly works.  ;D

I don't use Lazarus, but I do monitor its state (couldn't bring myself to write progress). That includes compiling the IDE against Cocoa. That really shows the bugs and missing pieces. If you haven't tried that, do so ASAP. If the IDE were stable and usable, I might agree with you. But it's not. (But it should be a good source of bug reports.)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 16, 2018, 02:35:29 am
I'm just seconding what Phil said.

I've tried building Lazarus with Cocoa, and it's unusable.

Now, it's not like the Carbon build doesn't have issues... Several GUI issues, especially in the settings forms, but it generally works.

I honestly wish there was something I could do.

Without Cocoa as an option, I don't see how I could stay with FPC/Lazarus for GUI applications, as most of what I do (GUI-wise) needs to be cross platform or Mac specific.

I just tried and can't rebuild Lazarus with any of the other widget sets to even get a feel for how well they work.

Without a big corporation using Laz and willing to put man-hours into it, I don't see how this will get better, not when it's been nearly a decade and there's an active $3k bounty for finish up an existing implementation.

I can offer a percentage of income from Cocoa based applications in the future, but can't put a lot down up front, and I doubt running a garage sale will get enough to really pay for development.

The only other option for me is to learn the inner workings of LCL, Lazarus, FPC, Cocoa, which I wouldn't mind but isn't feasible to get something within a reasonable timeframe, seeing as current apps are getting warnings from MacOS about being Carbon/32bit.

How do we convince Google that it's the wave of the future?  :D
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: mischi on June 16, 2018, 08:34:05 am
If the cocoa-lcl is not good enough, maybe try qt4-lcl.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: dbannon on June 16, 2018, 11:21:01 am
Said Phil -
Quote
I don't use Lazarus, but I do monitor its state (couldn't bring myself to write progress). That includes compiling the IDE against Cocoa. That really shows the bugs and missing pieces. If you haven't tried that, do so ASAP. If the IDE were stable and usable, I might agree with you. But it's not.

For sure, Phil, the IDE compiled under Cocoa is not usable. However, the Carbon based IDE will build (not perfect, maybe leaky) Cocoa apps. (I know you know but not everyone else does. It took me awhile ...).

Quote
(But it should be a good source of bug reports.)

Indeed, if we don't scare everyone away. From what I have seen, bug reports with attached patches get a lot more attention. Trouble is, my guess is we have less users who's preferred platform is Mac than Windows or Linux. So less who are comfortable getting their hand dirty there. While there are, overall, more Mac users than Linux, we Linux users are a self selected group of dapplers. Mind you, I have not tried GTK3   :D

Davo
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 16, 2018, 08:36:49 pm
Last night I tried GTK2 and GTK3 but couldn't get it working.

I haven't tried QT, but from what I've heard there are licensing fees or potential licensing issues for commercial applications using the free version.

I'll take a look though, if it solves my cross platform/mac issue, I'm happy.

--edit

Looks like there's a LGPL version and a commercial one starting at $459/mo. Ouch.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 16, 2018, 09:03:16 pm
Looks like there's a LGPL version and a commercial one starting at $459/mo. Ouch.

Yes, you'll need a license for Qt5 if you're not open sourcing your app.

Qt4 should be okay for non open source apps, but the Qt4 libraries have not been updated for over 4 years.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 16, 2018, 09:35:41 pm
I see qt and qt5 as widget options in Lazarus, would qt4 fall under the qt option?

I don't mind that it hasn't been updated for years, as long as it works well, doesn't have licensing issues, compiles to x64, and is easy to distribute.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 16, 2018, 09:45:44 pm
I see qt and qt5 as widget options in Lazarus, would qt4 fall under the qt option?

I don't mind that it hasn't been updated for years, as long as it works well, doesn't have licensing issues, compiles to x64, and is easy to distribute.

Yes, the "qt" widgetset is Qt 4.

Not easy to distribute. Or rather, the best way to do it is to include the Qt frameworks inside your app bundle. Adds quite a bit to the app bundle size, but that's really only an issue with small / trivial apps. For example, Microsoft Remote Desktop app on Mac includes the Qt4 libraries inside "Microsoft Remote Desktop.app/Contents/Frameworks.

You'll need to set up Laz with Qt4 using some other tool (fpcupdeluxe?) that compiles the Pascal interface library to the Qt C++ libraries to 64-bits. The supplied interface library is 32-bit only and the Qt libs are only 64-bit.

Looking at the Qt site I don't see a download for the Qt4 frameworks anywhere anymore, but it must be there somewhere.

Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 17, 2018, 12:03:20 am
If I can figure out a smooth compile/deploy cycle, it might work, if I can figure out the licensing for QT4 and it actually runs smooth.

I did find an installer, just gotta clean up 18gb to install it first  XD
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 17, 2018, 12:16:18 am
If I can figure out a smooth compile/deploy cycle, it might work, if I can figure out the licensing for QT4 and it actually runs smooth.

I did find an installer, just gotta clean up 18gb to install it first  XD

You only need qt-opensource-mac-4.8.6-1.dmg, which is <200 MB. Installs to much less than 18Gb.

For development, you can just compile against the frameworks, which will be installed under /Library/Frameworks.

For deployment, you would probably want to just write a script that copies the frameworks to the .app bundle's Frameworks subfolder, then fixes up the executable's paths. Use install_name_tool for this. There are example apps with scripts here that show how to do it:

https://macpgmr.github.io
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 17, 2018, 12:23:39 am
Oh ok, thanks for letting me know, the installer I found for QT requires 18.x gb to install, lol

Dang, I found that installer but it fails (With no specific error given) on MacOS High Sierra 10.13.5  :(
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 17, 2018, 12:26:02 am
Oh ok, thanks for letting me know, the installer I found for QT requires 18.x gb to install, lol

Dang, I found that installer but it fails (With no specific error given) on MacOS High Sierra 10.13.5  :(

Check the Console and see if the installer app output anything there.

I haven't tried any Qt4 installer on High Sierra. Could be they don't work, I suppose.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 18, 2018, 04:52:21 pm
I may have to stand (happily!) corrected.

I just created a new install of trunk laz + fpc with fpcupdeluxe, target x64 with cocoa, and it seems to work fairly well (Granted, I've only tested for a few minutes yet)

I recompiled an application which previously was utterly useless when compiled with Lazarus/fpc Cocoa, and it seems mostly fine with this compile  :)

I'll push this setup and see what gives, but it certainly seems useable compared to the previous times I've tried Laz/Cocoa.

Cautiously optimistic!
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Phil on June 18, 2018, 04:59:17 pm
I may have to stand (happily!) corrected.

I just created a new install of trunk laz + fpc with fpcupdeluxe, target x64 with cocoa, and it seems to work fairly well (Granted, I've only tested for a few minutes yet)

I recompiled an application which previously was utterly useless when compiled with Lazarus/fpc Cocoa, and it seems mostly fine with this compile  :)

I'll push this setup and see what gives, but it certainly seems useable compared to the previous times I've tried Laz/Cocoa.

Cautiously optimistic!

If you were using Laz 1.8.4, that version's Cocoa source has not been updated since ca. April 2017. I assumed you were already using trunk, the only place where Cocoa changes have been made over the last year or so.

Have you tried IDE against trunk? That's where the bugs / gaps show.

https://macpgmr.github.io/MacXPlatform/UsingCocoaFromTrunk.html

Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on June 18, 2018, 05:04:10 pm
I was using Trunk, but I guess an ancient version.

I was on Laz 1.9 though.

I'm now running the IDE  on Cocoa as well as building to Cocoa, and so far.. knock on wood.. it's working ok.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: marcov on June 18, 2018, 07:59:49 pm
less users who's preferred platform is Mac than Windows or Linux.

I'd rather say it is a problem of activity and priority rather than numbers.

While Mac seems to be the dominant platform among the hard core of Lazarus with both  Mattias and Martin usings Macs. At least they had Macs the last time I saw them, which is admitted a few years ago. (And Felipe too?)

Title: Re: How future "safe" is Carbon - anyone knows?
Post by: ChrisR on June 19, 2018, 02:38:04 pm
Like Trenatos, I have found the most recent Cocoa IDE to be pretty good (1.9 SVN 58330). Over the weekend, Dmitry updated the IDE o it can now copy/paste with other programs like web browsers. There are still a few rough edges, but it seems to be coming together. My sense is that if we as a community can start using the Cocoa IDE and build Cocoa apps, we can provide good bug reporting that will help the developers finish this up. If you have not tried the Cocoa IDE SVN recently, I suggest you give it another try.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 06, 2018, 11:07:15 am
Carbon died!

ERROR ITMS-90240: "Unsupported Architectures. Your executable contained the following disallowed architectures: '[i386 (in com.COBATA.XHTMLConstructor1Init.pkg/Payload/COBATA (X)HTML Constructor 1.0 Init.app/Contents/MacOS/COBATA(X)HTMLConstructor1.0Init)]'. New apps submitted to the Mac App Store must support 64-bit starting January 2018, and Mac app updates and existing apps must support 64-bit starting June 2018."

I wrote a "suggestion" to Apple that this is unacceptable and not loggical since the OS X 10.13.6 and Xcode 10 are still in beta - they will require/ impose to migrate to 64bit. Acctually, all the logic around the time, the OS version, etc is so subjective. MS tried to disallow Win32 APIs and this resulted in Desktop Bridge for Win32bit apps, because the store was empty.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 06, 2018, 01:35:08 pm
https://support.apple.com/en-us/ht208436

"...At our Worldwide Developers Conference in 2017, Apple informed developers that macOS High Sierra would be the last version of macOS to run 32-bit apps without compromise."
...
"When will the 64-bit transition be complete?
The 64-bit transition for macOS and macOS apps is still underway, so final transition dates have not yet been established. But now is a good time to check with the software developer to see if 64-bit versions of your favorite titles are available."

High Sierra is current, ... versions still in beta, Xcode too...
And we need time, that time, we loss time and loss money, caused by this kind of jumps.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 10, 2018, 02:32:26 pm
It's the response from Apple:
https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/Carbon64BitGuide/PortingTo64Bit/PortingTo64Bit.html

Is it resonable to be performed for Lazarus Carbon widget set?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on July 10, 2018, 02:43:54 pm
Not at all. Look at the screenshot, that documentation is retired:
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on July 10, 2018, 02:46:41 pm
I really do not understand that some people can't read. 32 bit will be retired. Period. Gives me head-aches too, but I respect that information and won't develop for 32 bit on Apple.
Note this goes for ALL Apple platforms. They are moving away. But to some extend some support for older devices.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on July 10, 2018, 04:01:34 pm
It's pretty straight forward: 32bit is going away, long live 64bit.

It's being deprecated by the platform, so focus needs to be mainly on 64bit and getting Cocoa up to date (Which seems to be going very well).

Carbon is dead, Apple killed it, now they're burying it.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 10, 2018, 04:09:28 pm
Thaddy, you read "retired" and stopped :-)

On Cocoa widgetset I read, that the plans Cocoa to be stable are 2 years, starting this autumn... This blocks me and does not fit to my plans... But if it is possible Carbon to live "on systems" for 1-2 years, i.e. if it is easy (for 1-2 weeks or even a month work) to be compilable for 64 bits and it is not risky to break the functionalities - it is definitely reasonable to me... Because..., lets say that the Customer has no interest is this Carbon or Cacoa and what are the differences, and more often these differences are disliked. Also, related to the software testing, it is easier to test the more stable and tested software (with the Carbon interface).
It's software with Carbon and for Mac.

Trenatos, OK :-)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on July 10, 2018, 04:14:29 pm
Thaddy, you read "retired" and stopped :-)

On Cocoa widgetset I read, that the plans Cocoa to be stable are 2 years, starting this autumn... This blocks me and does not fit to my plans... But if it is possible Carbon to live "on systems" for 1-2 years, i.e. if it is easy (for 1-2 weeks or even a month work) to be compilable for 64 bits and it is not risky to break the functionalities - it is definitely reasonable to me... Because..., lets say that the Customer has no interest is this Carbon or Cacoa and what are the differences, and more often these differences are disliked. Also, related to the software testing, it is easier to test the more stable and tested software (with the Carbon interface).
It's software with Carbon and for Mac.

Trenatos, OK :-)
What two years? since 2013,2014,2015? etc. READ!! Check dates!! <Ok, not really grumpy but still  >:D >:D>
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 10, 2018, 04:56:40 pm
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.

Cocoa will start to shine in no time.

In the absence of enough free time as of this moment, I cannot do any significant progress on Cocoa.
(the next "Cocoa session" for me might be open in October this year)
It's writen on june 2018!
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 10, 2018, 05:12:47 pm
Actually, the changes in Cocoa are not taken from the Trunk into the official release 1.8.4 since 2017 (please, don't want from me to search from where i read it :-)), but you want to develop in Cocoa AND to be more active on contributions :-D
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on July 10, 2018, 05:25:32 pm
If you want to be stubborn be an Ass (the animal, not you).
You can also call the Apple developer support line. Or email...
Same answer... <Now I am really grumpy  >:D >:D >:D >:D >:D >
Stop this thread
Freeze it.

[edit]
I promised to be careful with grumpy this year,but sheer..... 8-)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on July 10, 2018, 07:07:08 pm
Anyone to try trunk?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on July 10, 2018, 10:37:51 pm
Anyone to try trunk?
Guess who?.... Don't get your hopes up. Apple 32 bit is like Windows 95.... 8-) 8-)
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on July 10, 2018, 10:44:01 pm
I just tried building Laz with trunk (x64 Cocoa), and it won't compile  :P

Hangs on pseudoterminaldlg.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Martin_fr on July 11, 2018, 11:16:27 am
I just tried building Laz with trunk (x64 Cocoa), and it won't compile  :P

Hangs on pseudoterminaldlg.

svn up again, fixed last night
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on July 11, 2018, 03:34:41 pm
Martin_fr, still broken for me.

I'm only getting the one error now though: 213,45 - identifier idents no member "DevicePtyMaster"

I'd copy/paste the line, but the copy/paste functionality doesn't work in x64 Cocoa FPCUpDeluxe   :/

Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Trenatos on July 11, 2018, 05:44:26 pm
And I just got it working by rebuilding with
Code: Pascal  [Select][+][-]
  1. ./lazbuild --build-ide= --widgetset="Cocoa"
and now command+z works

Thanks!
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on July 13, 2018, 11:39:37 pm
Good work, Guys!

I am impressed!

I tried the version:
"Checked out revision 58509."

I wrote in Cocoa widget set "OpenPictureDialog is not openning?" topic.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on August 20, 2018, 11:46:16 am
How to learn what Carbon APIs are deprecated?

If I can compile my app in 64-bit with Cocoa widgetset, does it mean that all existing 64-bit Carbon APIs are not deprecated?

I have a large old Freepascal product which doesn't use LCL. It's hard work to check all the code in hundred of units to make sure that I didn't miss all deprecated Carbon APIs. My form is using Cocoa API.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on August 20, 2018, 03:14:06 pm
How to learn what Carbon APIs are deprecated?
Not every C-style function is part of Carbon.
I.e. CoreFoundation (https://developer.apple.com/documentation/corefoundation?language=objc) or CoreGraphics (https://developer.apple.com/documentation/coregraphics?language=objc) are C-style libraries, yet are not considered being a part of Carbon.

It's also worth noting that any unix or posix apis are not deprecated as well.
Even more Apple recommended those as alternative to Carbon APIs in their Carbon Deprecrecation (https://developer.apple.com/library/archive/releasenotes/General/CarbonCoreDeprecations/index.html#//apple_ref/doc/uid/TP40012224) document

If I can compile my app in 64-bit with Cocoa widgetset, does it mean that all existing 64-bit Carbon APIs are not deprecated?

I have a large old Freepascal product which doesn't use LCL. It's jard work to check all the code in hundred of units to make sure that I didn't miss all deprecated Carbon APIs. My form is using Cocoa API.
If you can compile an application for 64-bit, then it's likely you're already not using any Carbon API function.
(otherwise you would fail to link the app)
Another safe approach is to try out the app on Mojave. You should be able to get access to the beta version even now, by signing up for apple beta (http://beta.apple.com) program
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on August 20, 2018, 08:28:05 pm
Hi,

Many thanks for you reply!
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on August 20, 2018, 08:37:04 pm
Many thanks for you reply!
You're welcome. Are there any plans for a new PixBuilder version? (any plans for macOS?)
any new products maybe?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on August 20, 2018, 09:09:11 pm
Hi,

I just thought that you're our old good friend! Your nickname :)

We're working on Mac 64-bit version of PTE. We hope to build Alpha version this autumn. Currently we're testing different parts of PTE on Mac (interface, video player, audio).

How you think, is it safe to use deprecated CoreServices APIs:

MPCreateSemaphore, MPDeleteSemaphore, MPCreateCriticalRegion, MPDeleteCriticalRegion, MPEnterCriticalRegion, MPExitCriticalRegion, MPCreateEvent

P.S. Last official version PTE 9 for Windows contains many improvements - new powerful editor of animations, slide styles, color effects, etc.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on August 20, 2018, 09:19:26 pm
How you think, is it safe to use deprecated CoreServices APIs:

MPCreateSemaphore, MPDeleteSemaphore, MPCreateCriticalRegion, MPDeleteCriticalRegion, MPEnterCriticalRegion, MPExitCriticalRegion, MPCreateEvent
The sooner you switch away from them the better.

Multiprocessing Services (https://developer.apple.com/documentation/coreservices/carbon_core/multiprocessing_services?language=objc) has been announced deprecated in 10.8.
It would be more robust to use either Posix threads APIs (https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/pthread.3.html#//apple_ref/doc/man/3/pthread), or FPC runtime synchronization objects (they're based on Posix threads anyway).

The fact that documentation for Multiprocessing Services still exists suggests that they still might work on Mojave, yet it would be safer (and backwards compatible) to use Posix
Actually, no. These are part of Carbon Core, so they might not work on Mojave at all.

Using Objective-C locking objects (https://developer.apple.com/documentation/foundation/nslock?language=objc) could be a long term solution as well.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on August 21, 2018, 12:52:46 pm
Thanks again!
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on August 24, 2018, 03:09:03 pm
I use XCode (ProjectXC) to debug my app in High Sierra.

Is it possible to see warnings regarding deprecated macOS functions? Or probably it's possible directly in Lazarus?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on August 24, 2018, 03:30:53 pm
I use XCode (ProjectXC) to debug my app in High Sierra.
Is it possible to see warnings regarding deprecated macOS functions? Or probably it's possible directly in Lazarus?
only, if they are declared as deprecated in pascal headers.
and I'm quite sure they're not (carbon headers are not being updated)

Apple would be the best source of updated Pascal headers. However, the corporation doesn't provide them.

An alternative approach would be some sort of a tool that could parse C headers, extract deprecation information and then put it into pascal headers.
Such tool doesn't exists to my best knowledge
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on August 24, 2018, 04:55:49 pm
Thanks, I've understood the situation.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on May 13, 2020, 08:56:14 am
Hi,

I'm still trying to find all deprecated functions in our code.

Is there any news how automate this work?

Probably notarization tool can do it? Or not?
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: trev on May 13, 2020, 09:14:12 am
I'm still trying to find all deprecated functions in our code.
Is there any news how automate this work?
Probably notarization tool can do it? Or not?

Notarization (https://wiki.lazarus.freepascal.org/Notarization_for_macOS_10.14.5%2B) does not report deprecated functions - I've notarized  applications which contain functions deprecated in macOS 10.8 (Mountain Lion) and there were no warnings of any sort in the notarization log file. I only noticed the deprecations while trawling the Apple developer Documentation site (https://developer.apple.com/documentation).
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on May 13, 2020, 09:42:13 am
Notarization (https://wiki.lazarus.freepascal.org/Notarization_for_macOS_10.14.5%2B) does not report deprecated functions - I've notarized  applications which contain functions deprecated in macOS 10.8 (Mountain Lion) and there were no warnings of any sort in the notarization log file. I only noticed the deprecations while trawling the Apple developer Documentation site (https://developer.apple.com/documentation).

OK, I've understood. Thanks.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on May 13, 2020, 04:00:33 pm
Igor,

The Cocoa ws is near to the official stable release...
I asked the community to port Carbon 32 to 64 too with no success and finally decided that it is lost war with Apple (you know they f..ked even Embarcadero (and even automotive industry) with their often changing policies.
By me, it is more reasonable to continue to develop my software functionality and to recompile it for Cocoa when it is officially released.

Regards
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: cobata on May 13, 2020, 04:07:25 pm
The Cocoa ws is near to the official stable release...

I mean that all bugs I found for my software on porting and testing from Carbon to Cocoa I had reported and after an year they are all fixed...
It was maybe better to find your bugs and to report and to support them during the development of your software.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on May 14, 2020, 12:35:54 pm
It's very hard to find deprecated functions in existing code.

For example, GetCurrentProcess() from ApplicationServices framework.

I very hope that it there is some solutino to automate this work.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: PascalDragon on May 14, 2020, 01:30:02 pm
By me, it is more reasonable to continue to develop my software functionality and to recompile it for Cocoa when it is officially released.

It already is officially released (https://forum.lazarus.freepascal.org/index.php/topic,49356.0.html): Lazarus for macOS on x86_64 uses Cocoa.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: trev on May 14, 2020, 01:31:15 pm
Automation: Xcode shows deprecation warnings which I understand are based off the header files. If the function has been removed, then of course Xcode won't compile it.

Otherwise: You need to resort to Apple's macOS release notes (https://developer.apple.com/documentation/macos_release_notes) which only seem to go back to macOS 10.13.

I believe I've also seen the deprecations in FPC's converted macOS header files but I think FPC 3.0.4 is only up to date to macOS 10.5 and trunk is up to date to macOS 10.8.

I think the only sure way to know is to check your functions against the Apple online API documentation.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Igor Kokarev on May 15, 2020, 11:34:22 am
Thanks.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: trev on May 16, 2020, 06:39:45 am
Here is a listing (attached) of the deprecated functions for trunk as of r44876, 2020-04-20. Bear in mind this probably only catches deprecations up to macOS [edit]10.10 [/edit].
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: trev on May 23, 2020, 01:51:20 pm
I finally found the Release Notes for macos10.12 and older (https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes) back to OpenStep 4.x !
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: VTwin on June 03, 2020, 03:43:37 am
Cocoa support now exceeds past Carbon support, there is no reason to develop using Carbon anymore, it was deprecated in about 2012. It was available in fixes branch in 2.0.6, and in 2.0.8 is official.

Many thanks to the developers!
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on June 03, 2020, 04:27:38 am
...unless targeting 10.5 or earlier
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: Thaddy on June 03, 2020, 09:27:21 am
It was maybe better to find your bugs and to report and to support them during the development of your software.
That is not how software development works. Coders take care of what they see, which is most of the bugs, but only testers can take care of scenario's that the coder can not see or predict.
Hence in my last job we had 40+ coders and 20 testers. Also had test automation in place (which takes care of a different category of bugs)

To sum up: it is not even likely that the coder can find all bugs. His focus is elsewhere. Testing requires other people. Hence bug reports exist.... And good coders appreciate those reports very much. Only bad coders find them annoying...

An example why this is the case:
Testers take also into account the expectations of functionality of the customer, as in owner of the software in general.
Coders work based on a given specification of functionality as in what needs to be coded.

The coder does not write the specification. The customer does. So testers are necessary to check if the specifications are right too. It is often the case that expectation and specification do not meet. That is not the fault of the coder....
Functional design - produced by the customer - technical design by the architect based on the functional design - finally given to the coder. These roles can intermix, but not often in large projects.
And all three of the roles can cause bugs....

Finally:
skalogryz is a very professional coder, so the remark you made is completely out of place. Reason: what you wrote as "better" HAS been done and is continuing... You obviously are too lazy to help. You say (paraphrased) it does not work. You don't give enough information beyond that. Not very helpful.
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: skalogryz on June 03, 2020, 07:58:26 pm
off topic:
Quote
A software QA engineer walks into a bar.
He orders a beer.
Orders 0 beers.
Orders 99999999999 beers.
Orders a lizard.
Orders -1 beers.
Orders a ueicbksjdhd.

First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

Finally:skalogryz is a very professional coder...
I don't know. My day time job is C# and C++, plus occasionally it's Web (JS) and SQL.

Chances are I'm not the best person to maintain ObjC frameworks via Pascal xD
Title: Re: How future "safe" is Carbon - anyone knows?
Post by: VTwin on June 05, 2020, 04:33:30 pm
off topic:
Quote
A software QA engineer walks into a bar.
He orders a beer.
Orders 0 beers.
Orders 99999999999 beers.
Orders a lizard.
Orders -1 beers.
Orders a ueicbksjdhd.

First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

:D

"This software and any related documentation are provided as is without warranty of any kind, either express or implied, including, without limitation, the implied warranties or merchantability, fitness for a particular purpose, or non-infringement. It may burst into flames. The entire risk arising out of use or performance of the software remains with you."
TinyPortal © 2005-2018