How future "safe" is Carbon - anyone knows?

[Trenatos]

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? 

[mischi]

If the cocoa-lcl is not good enough, maybe try qt4-lcl.

[dbannon]

Said Phil -

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

(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   

Davo

[Trenatos]

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.

[Phil]

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.

[Trenatos]

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.

[Phil]

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.

[Trenatos]

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

[Phil]

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

[Trenatos]

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 

[Phil]

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.

[Trenatos]

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!

[Phil]

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

[Trenatos]

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.

[marcov]

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