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?
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)
Interestingly, Apple made Carbon also available on iOS, although there wasn't a need for porting applications from classical Mac OS.
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.
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
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
As for testing every property, method, etc. that's what unit-testing is for.
Well actually YES. Luckily the compiler team writes unit tests.......<sigh and grumpy >:D >:D >:D >:D>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?
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?
Unit tests should always be doneyes. yes.
Unit tests should always be doneyes. yes.
but how - in cross-platform manner?
(More specifically - looking for tools)
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)
@phil, fair enough, I didn't know you meant the visual aspect.
Though there are GUI testing tools, I haven't used them before.
But the core problem remains, Cocoa not being implemented/done.Just work on it.
Anyone have ideas for how we can get movement on that?
(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.
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.)
Looks like there's a LGPL version and a commercial one starting at $459/mo. Ouch.
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.
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
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 :(
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!
less users who's preferred platform is Mac than Windows or Linux.
Thaddy, you read "retired" and stopped :-)What two years? since 2013,2014,2015? etc. READ!! Check dates!! <Ok, not really grumpy but still >:D >:D>
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 :-)
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.It's writen on june 2018!
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)
Anyone to try trunk?Guess who?.... Don't get your hopes up. Apple 32 bit is like Windows 95.... 8-) 8-)
I just tried building Laz with trunk (x64 Cocoa), and it won't compile :P
Hangs on pseudoterminaldlg.
How to learn what Carbon APIs are deprecated?Not every C-style function is part of Carbon.
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?If you can compile an application for 64-bit, then it's likely you're already not using any Carbon API function.
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.
Many thanks for you reply!You're welcome. Are there any plans for a new PixBuilder version? (any plans for macOS?)
How you think, is it safe to use deprecated CoreServices APIs:The sooner you switch away from them the better.
MPCreateSemaphore, MPDeleteSemaphore, MPCreateCriticalRegion, MPDeleteCriticalRegion, MPEnterCriticalRegion, MPExitCriticalRegion, MPCreateEvent
I use XCode (ProjectXC) to debug my app in High Sierra.only, if they are declared as deprecated in pascal headers.
Is it possible to see warnings regarding deprecated macOS functions? Or probably it's possible directly in Lazarus?
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).
The Cocoa ws is near to the official stable release...
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 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.
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.
off topic:QuoteA 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.