Lazarus
Programming => Widgetset => Cocoa => Topic started by: wittbo on July 16, 2017, 10:25:39 am
-
Hi,
since some months I'm working on a cross-platform project; cross-platform means, I would like to get it run on win64 and macOS 64bit. My development platform is macos 10.10 with Lazarus 1.6.4. I started with the carbon widgetset (IDE always carbon), made some experiences with colors, fontsizes and not really working border settings. But ok, the application works fine and can be compiled under WinXP and Win10 without errors. There are some minor adjustments necessary concerning fonts and font sizes and relative adjustments of GUI components, but the result is good enough. The functionality including SQLite database is without any problem.
But what will happen in the future? Within the next one or two years all 32bit applications won't no longer work on actual macOSses. So it seems to me the only way of survival on macOS is migrating to Cocoa 64bit widgetset. So I made my first experiences with Cocoa. IDE stayed on carbon, compiler switch was set to cocoa. Some minor bugs could be handled by workarounds, but then came some severe problems (app crashes on opening a windows OnShow Event, another window only showed less than the half of all visual components, ...). I doubt, that cocoa will ever be a stable platform on macOS. That would mean (for me), that Lazarus will die for macOS within the next two years.
My first Pascal course was in 1981 (may be, I'm an IT grandfather), then stepped into UCDS Pascal with Apple II, followed by Delphi about 20 years ago. I'm loving this language very much and would do much to help further development for this platform. I'm not a real IT compiler technician and I cannot look very deeply into the secrets of the underlying libraries, but I decided to register for the freepascal bug tracker and to help a little bit to make lazarus-cocoa as a stable pascal software development platform.
-
I disagree with lazarus will die for macOS. I only agree, that it will become more difficult.
First, with the removal of 32-bit carbon, the pressure for cocoa development increases and I expect faster progress.
Second, already now, you can try the 64-bit Qt4-based lcl, which looks pretty good. If this fails, too, the last option is the gtk2-based lcl, which admittedly looks horrible. Both approaches require the installation of additional libraries for the development, but with some effort it is possible to even create standalone applications.
In order to simplify these, I have created package descriptions for fink, a Debian-like package manager, for the Qt4- and gtk2-based lcls. They drag in all what is needed automatically. The currently supported versions are lazarus-1.6.4 and fpc-3.0.2. As soon as newer releases (1.8.0 and 3.0.4) are out, I will update.
However, Xcode and Swift are a tempting alternative.
No reason to despair - MiSchi
-
As time pressure increases, let's hope more contributors are coming to finish the Cocoa widgetset. The better way is to of course find capable contributors and work on it right away.
-
Hi,
since some months I'm working on a cross-platform project; cross-platform means, I would like to get it run on win64 and macOS 64bit. My development platform is macos 10.10 with Lazarus 1.6.4.
The Cocoa widgetset code in 1.6.4 is ancient. You need to try 1.8.0 RC3 or, even better, the trunk code:
https://macpgmr.github.io/MacXPlatform/UsingCocoaFromTrunk.html
There are still some gaps and bugs in the Cocoa widgetset, but if you use 1.6.4 you're almost assured that your program won't work with Cocoa.
-
Second, already now, you can try the 64-bit Qt4-based lcl
But is that even true anymore? The Qt 4.8.6 package for Mac is now incompatible with El Capitan and later, probably because it tries to put files in /usr/bin. And I was unable to compile the interface framework for 64-bits.
Laz 1.8 includes support for Qt5, as well as the C++ code for compiling the interface framework yourself, but has any Mac user ever gotten that to work? I posed that question here a while back and got no response, so I would guess we know the answer.
No, I don't think that Qt, with or without fink, is a viable answer to new Mac developers who want to try out Lazarus and expect 64-bit Cocoa out of the box.
However, Xcode and Swift are a tempting alternative.
No reason to despair - MiSchi
Apple reported last month that 3 million new developers had signed up in the previous year. Perhaps a few of them were Lazarus users, but probably not more than a handful.
https://www.macstories.net/news/apples-wwdc-keynote-by-the-numbers/
What's your definition of despair?
-
As time pressure increases, let's hope more contributors are coming to finish the Cocoa widgetset. The better way is to of course find capable contributors and work on it right away.
Felipe is pretty good about fixing bugs in the Cocoa widgetset, but these bugs do need to be reported. I'll admit that creating a test project that demos a bug and logging a bug report is probably one of the most tedious things that a developer can do, but it has to be done if you want a complete Cocoa widgetset some day.
I would say that 1.6.4 is about the end of the line for the Carbon widgetset. No one is working on it anymore and 1.8 introduced some serous regressions. Carbon will probably do for a while as the IDE, but we need to start targeting Cocoa for the apps, reporting bugs as they're uncovered.
-
QT 5.6 works fine with Lazarus trunk on 10.12 ! And I would like to thank the developer who has done all the QT5-work.
IMHO, QT is the way to go on 64bit.
-
QT 5.6 works fine with Lazarus trunk on 10.12 ! And I would like to thank the developer who has done all the QT5-work.
IMHO, QT is the way to go on 64bit.
That's good to hear, but again I don't think that's a viable choice for new developers. It does require a 1.1 GB download just to get the Qt5 frameworks. Plus there's the issue of deployment of those frameworks with your app. Gulp.
I regularly use two apps on Mac that use Qt: QGIS and Microsoft's Remote Desktop. The look and feel is pretty good, but I note that they still use Qt 4.8 and the issue of Qt library size adding to deployment is moot (QGIS.app footprint is over 600MB, so what's another 40MB for the Qt libraries?).
Unfortunately, the Qt5 widgetset interface library dropped support for QWebEngine (what 4.x called QWebView), so I can't add support to TWebBrowser, which now has proof-of-concept suppot for Qt4 on Lazarus:
https://macpgmr.github.io/MacXPlatform/lclwebbrowser-src.zip
No, Cocoa has to be where Lazarus gets to on Mac. Otherwise, there's no point to it.
-
But is that even true anymore? The Qt 4.8.6 package for Mac is now incompatible with El Capitan and later, probably because it tries to put files in /usr/bin. And I was unable to compile the interface framework for 64-bits.
No, I don't think that Qt, with or without fink, is a viable answer to new Mac developers who want to try out Lazarus and expect 64-bit Cocoa out of the box.
The fink packages for qt4, version 4.8.7 work flawlessly on 10.12. Fink packages never ever install stuff in /usr/bin. This has probably been fixed by the maintainer of the fink packages since ages. Secondly, i am not aware of any related problems with my lazarus-qt4 fink package on 10.12. At least, i have not received any bug report so far. Correct me, if i am wrong on this.
MiSchi.
-
QT 5.6 works fine with Lazarus trunk on 10.12 ! And I would like to thank the developer who has done all the QT5-work.
IMHO, QT is the way to go on 64bit.
For me that means, that it is time to pick it up and create a fink package description for it. Lazarus 1.8.0 sounds like a good starting point.
-
The fink packages for qt4, version 4.8.7 work flawlessly on 10.12. Fink packages never ever install stuff in /usr/bin. This has probably been fixed by the maintainer of the fink packages since ages.
Right, the Qt boys should have known better. For example, FPC has never installed to /usr/bin, I don't believe, only to /usr/local.
In any case, it's now well documented what locations are reserved for macOS:
https://developer.apple.com/library/content/documentation/Security/Conceptual/System_Integrity_Protection_Guide/FileSystemProtections/FileSystemProtections.html#//apple_ref/doc/uid/TP40016462-CH2-DontLinkElementID_2
I don't see a 4.8.7 Qt package:
http://download.qt.io/archive/qt/4.8/
Do you know of a different download site?
-
QT 5.6 works fine with Lazarus trunk on 10.12 ! And I would like to thank the developer who has done all the QT5-work.
IMHO, QT is the way to go on 64bit.
For me that means, that it is time to pick it up and create a fink package description for it. Lazarus 1.8.0 sounds like a good starting point.
Do you include the Qt frameworks too?
-
Do you know of a different download site?
I was talking about the fink packages.
http://pdb.finkproject.org/pdb/package.php/qt4-base-mac
http://pdb.finkproject.org/pdb/browse.php?name=lazarus&nochildren=on
Sure enough, you need to install fink, which is quite a step for a casual user, but should not be so much of a problem for a developer.
Fink package descriptions are supposed to take care of all installation issues and usually do so. In many cases, maintainers report issues to upstream, but the issues are not always picked up by upstream developers. Compared to MacPorts and Homebrew there are some Cons and Pros.
MiSchi.
-
Do you include the Qt frameworks too?
Since there are already package descriptions for Qt5, declaring appropriate dependencies in the package description of lazarus-qt5 takes care of it.
MiSchi.
-
Sure enough, you need to install fink, which is quite a step for a casual user, but should not be so much of a problem for a developer.
I can see the use case for Qt5 and fink with Lazarus on Mac, but that would be a very small number of developers, perhaps vanishingly small, possibly only experienced developers with large apps who are comfortable with Qt and deploying and supporting Qt (ie, C++ developers). But that is not a solution for the rest of us.
The problem for Lazarus on Mac is not that it can't attract Mac users, but that it can't retain them. And can you blame these users? 32-bit Carbon? gdb? Are you kidding me? That should be the normal reaction to Lazarus. And a quick exit stage right. And that's exactly what happens. Just follow the postings and subsequent silence from new Mac users here.
Lazarus on Mac just needs to be something reasonable. Easy to get installed and started with and capable of creating apps that aren't an embarrassment. Carbon needs to be deprecated like GTK1 was. We should be emphasizing the targeting of Cocoa, warts and all.
-
The problem for Lazarus on Mac is not that it can't attract Mac users, but that it can't retain them. And can you blame these users? 32-bit Carbon? gdb? Are you kidding me? That should be the normal reaction to Lazarus. And a quick exit stage right. And that's exactly what happens. Just follow the postings and subsequent silence from new Mac users here.
Too many users, too few developers for Mac indeed.
Lazarus on Mac just needs to be something reasonable. Easy to get installed and started with and capable of creating apps that aren't an embarrassment. Carbon needs to be deprecated like GTK1 was. We should be emphasizing the targeting of Cocoa, warts and all.
Setting policies is not useful in a purely volunteer effort. People work on what they work for their own reasons, not because of policies or popularity (exhibit A: the Amiga ports seem to have more devels than Mac)
If you want Cocoa to improve, improve Cocoa or raise money to do so. Oh, and GTK1 was only deprecated long after GTK2 was usable.
-
[Oh, and GTK1 was only deprecated long after GTK2 was usable.
Exactly. But the only way to get a usable Cocoa is to log bug reports. And that means to start using Cocoa, which most Mac users never do.
-
No, Cocoa has to be where Lazarus gets to on Mac. Otherwise, there's no point to it.
As a newcomer to the Apple Mac world, it's taken me a few weeks to appreciate the differences in Widget sets and the effect on Lazarus as an IDE and on apps built with Lazarus. I have to say that while I have been delighted by the quality of the Carbon widget set, I am concerned about where Lazarus is going to be a few years into the future. As I see it, part of the problem is one of perception. Lazarus, built with the Cocoa widget set just looks really unready for wide consumption, and apps built with Cocoa don't look any better. Maybe that's because I'm basing judgement on the 1.9 Lazarus truck source. I haven't yet tried the last stable version. Maybe what's needed is a major push in the next few weeks and months, where efforts are concentrated on making the product look better, even if the bits below the surface are not yet polished. Hopefully, this would attract more users and the Cocoa version of Lazarus would develop some sort of momentum.
-
Lazarus, built with the Cocoa widget set just looks really unready for wide consumption, and apps built with Cocoa don't look any better. Maybe that's because I'm basing judgement on the 1.9 Lazarus truck source.
Right, the IDE probably exercises just about the entire widgetset, so it's only going to be as complete as the Cocoa widgetset.
However, the parts of the Cocoa widgetset I've used in the trunk are quite stable and complete. If you have issues with the trunk Cocoa in your apps, then you need to log bug reports with small projects that demo the problems. Yes, that's tedious, wasted time, but it has to be done.
-
I can see the use case for Qt5 and fink with Lazarus on Mac, but that would be a very small number of developers, perhaps vanishingly small, possibly only experienced developers with large apps who are comfortable with Qt and deploying and supporting Qt (ie, C++ developers). But that is not a solution for the rest of us.
The problem for Lazarus on Mac is not that it can't attract Mac users, but that it can't retain them. And can you blame these users? 32-bit Carbon? gdb? Are you kidding me? That should be the normal reaction to Lazarus. And a quick exit stage right. And that's exactly what happens. Just follow the postings and subsequent silence from new Mac users here.
I agree on the second paragraph, but there are more severe reasons than you give in the first paragraph. My point of view is, that the lcl itself has a number of shortcomings with respect to macOS and violations of the Human Interface Guidelines, independent of its basis, whereas the extra layer of the lcl actually prevents you to deal with subtleties of Qt, at least from most of them. The problem with gdb is also independent of the lcl basis. The point I want to stress is that if the carbon-based lcl was good enough for you so far, chances are good that you can get along for example with the Qt-based lcl. That is what i meant with no reason for despair if the support for carbon stops. The end of lazarus-carbon does simply not put an absolute end to lazarus on macOS. Even if lazarus-cocoa has not reached a sufficient level. Sure enough, without lazarus-carbon the situation becomes even worse on macOS, but lazarus-gtk2 and lazarus-qt4 are already available as fink packages and can be used, although i haven't tested them extensively. As soon as lazarus-cocoa is possible as a release, i will put it together, even if it needs some patches. I'll give lazarus-qt5 a try with version 1.8.0.
I have the impression that when it comes to macOS, people limit their view to the carbon-based lcl and miss all other options.
MiSchi
-
I have the impression that when it comes to macOS, people limit their view to the carbon-based lcl and miss all other options.
Right. I don't have a problem with a Carbon-based IDE, or even a Qt-based one that includes all the Qt libraries, but I think it's time to start encouraging the targeting of Cocoa when building your apps.
The way I'm doing that is by creating custom LCL controls for Lazarus that can't be used with Carbon because it's, well, Carbon. For example, the TWebBrowser needs the Cocoa WebView - nothing like that available for Carbon:
https://macpgmr.github.io/MacXPlatform/lclwebbrowser-src.zip
I'm also creating a custom control that wraps the Mapbox SDK, so I started with TWebBrowser since was easier to do. I'm already using Mapbox on the Web in production and the native MacOS SDK is equally awesome:
https://mapbox.github.io/mapbox-gl-native/macos/0.5.0/
It's so cool that I simply had to do a custom LCL control to share the joy.
And note that Mapbox SDK on Mac is a 64-bit Cocoa framework, so no 32-bit, no Carbon need apply.
-
Right. I don't have a problem with a Carbon-based IDE, or even a Qt-based one that includes all the Qt libraries, but I think it's time to start encouraging the targeting of Cocoa when building your apps.
I agree on that.
The way I'm doing that is by creating custom LCL controls for Lazarus that can't be used with Carbon because it's, well, Carbon. For example, the TWebBrowser needs the Cocoa WebView - nothing like that available for Carbon:
https://macpgmr.github.io/MacXPlatform/lclwebbrowser-src.zip
I'm also creating a custom control that wraps the Mapbox SDK, so I started with TWebBrowser since was easier to do. I'm already using Mapbox on the Web in production and the native MacOS SDK is equally awesome:
https://mapbox.github.io/mapbox-gl-native/macos/0.5.0/
It's so cool that I simply had to do a custom LCL control to share the joy.
And note that Mapbox SDK on Mac is a 64-bit Cocoa framework, so no 32-bit, no Carbon need apply.
As always, I appreciate your work. Sometimes i even find the time to make a fink package description for it.
MiSchi.
-
Sometimes i even find the time to make a fink package description for it.
And good on you for that.
Wait till you see the Mapbox control for Lazarus, although I can't really claim much credit there. I used Ryan's most excellent parser to parse the entire Mapbox SDK headers (https://github.com/genericptr). And of course the Mapbox lads somehow managed to put all of that stuff into a single 3.5MB library that you include with your app. Take a look at the code below. Even if you don't know Objective C, it should be fairly readable. And how did they achieve that? Well, generous use of white space, consistency in indentation and naming, good organization, and comments where they're needed. Good looking code.
https://github.com/mapbox/mapbox-gl-native/blob/master/platform/macos/src/MGLMapView.mm
-
I think that the original post is missing a link, I found something in macrumors:
https://www.macrumors.com/2017/06/06/apple-to-phase-out-32-bit-mac-apps/
Anyway, don't panic people, we'll just need to switch the Lazarus IDE to run in Cocoa. Even if there are some bugs.
-
Back again. It was a good feeling for me to follow the engaged discussion.
It confirmed my decision, that a switch to Cocoa is the right way. So I started registering for bug tracker and I will post those cocoa bugs I find upon developing with cocoa. Hope that there is a stable cocoa implementation until end of this year.
-
But is that even true anymore? The Qt 4.8.6 package for Mac is now incompatible with El Capitan and later, probably because it tries to put files in /usr/bin. And I was unable to compile the interface framework for 64-bits.
Laz 1.8 includes support for Qt5, as well as the C++ code for compiling the interface framework yourself, but has any Mac user ever gotten that to work? I posed that question here a while back and got no response, so I would guess we know the answer.
Yes, Qt5 works on Mac (Cocoa 64 bit). Haven't enough time for testing, but it works here in virtual machine, only thing is that you must build libQt5Pas on your own.
-
Hi zeljko/Phil/or another user :)
How do u make the Qt5Pas.framework, i use from codetyphon (only this framework) and after install qt, i can build from lazarus. But i get this error running the app:
dyld: Library not loaded: /opt/local/libexec/qt5-mac/lib/QtWebKitWidgets.framework/Versions/5/QtWebKitWidgets
Referenced from: /Users/esteban/Qt5Pas.framework/Versions/1/Qt5Pas
Reason: image not found
Abort trap: 6
Or i get this error running macdeployqt: (the other files from framework are copied to framework subdir's app)
ERROR: no file at "/Library/Frameworks/Qt5Pas.framework/Versions/1/Qt5Pas.framework/Versions/1/Qt5Pas"
Thanks !
-
dyld: Library not loaded: /opt/local/libexec/qt5-mac/lib/QtWebKitWidgets.framework/Versions/5/QtWebKitWidgets
Referenced from: /Users/esteban/Qt5Pas.framework/Versions/1/Qt5Pas
Reason: image not found
Abort trap: 6
Sounds like it can't find QtWebKitWidgets library. Note that the installation does not make any sense to me. Normally frameworks are installed under /Library/Frameworks or locally inside the .app bundle.
Or i get this error running macdeployqt: (the other files from framework are copied to framework subdir's app)
ERROR: no file at "/Library/Frameworks/Qt5Pas.framework/Versions/1/Qt5Pas.framework/Versions/1/Qt5Pas"
That path makes no sense. Did you copy it here wrong?
-
I agree with you Phil, for that reason create the directories and a symbolic link, but also the directory QtWebKitWidgets does not exist in my QT installation and install all the components of the installer that is recommended in the wiki. Subsequently probe install with brew install qt, but there is still no such library.
-
I agree with you Phil, for that reason create the directories and a symbolic link, but also the directory QtWebKitWidgets does not exist in my QT installation and install all the components of the installer that is recommended in the wiki. Subsequently probe install with brew install qt, but there is still no such library.
I can't help you with CodeTyphon or homebrew. Why don't you start clean with Lazarus and install Qt5 frameworks (under /Library/Frameworks), build Pascal interface library and framework, etc?
-
Well Phil, I'll do what you suggest. I really admire your knowledge of macOS. In one of those you can clarify a little more about QT5 and macos because there is very little information.
-
Hello,
Just passing by. I use every day Qt on my mac. I do not think the support of Qt by Lazarus is the future of Lazarus because Lazarus greatly reduces qt's capabilities. In addition it is necessary to distribute all necessary qt libraries.
But I can not understand. In interpreting your remarks, I understand that it is currently possible to use an experimental trunk lazarus cocoa ?
The cross compilation is a problem : I tried from Lazarus Carbon to use UniDac by cross-compiling to 64-bit Cocoa: total failure.
I believe that to develop the use of Lazarus under macOS you must facilitate its installation.
It takes a step-by-step tutorial, updated to the new version of Mac: OS 10.12.6, including the installation of an integrated debugger ... even if it's under Carbon 32.
Then you need a step-by-step tutorial to cross-compile the projects to Cocoa 64.
Do not complain if there is no Mac OS Lazarus's user. Installation is very difficult when compared to the Windows or Linux installation.
Then for someone who wants to test Lazarus, it is almost a blow on abandonment before even being able to test it.
I installed Lazarus, managed to integrate gdb and dropped to cross-compilation. Too painful, too time consuming, too complicated ...
Regards. Gilles
-
But I can not understand. In interpreting your remarks, I understand that it is currently possible to use an experimental trunk lazarus cocoa ?
Not sure what you mean by "experimental". The trunk Cocoa widgetset code is a bit more recent than the Lazarus 1.8 RCx Cocoa widgetset code, and quite a bit more recent (and complete) than the Laz 1.6 Cocoa widgetset code.
https://macpgmr.github.io/MacXPlatform/UsingCocoaFromTrunk.html
The cross compilation is a problem : I tried from Lazarus Carbon to use UniDac by cross-compiling to 64-bit Cocoa: total failure.
What version of Lazarus were you using? Be sure to test the Cocoa widgetset only with RC 1.8RC3 or later.
Then for someone who wants to test Lazarus, it is almost a blow on abandonment before even being able to test it.
Yes, I'm sure many prospective Mac Lazarus users have been greatly disappointed over the years.
-
Hello Phil,
I just installed trunk : OK.
Fig 1 (http://www.sdeidev.com/lazarus/mac/trunk/01.png)
Test : IDE very slow including moving the mouse. It is possible to change the width of the IDE toolbar but the height can not be changed...And the height is too small.
Fig 2 (http://www.sdeidev.com/lazarus/mac/trunk/02.png)
To compile my small code, it takes 45 seconds. (The texts are truncated)Fig 3 (http://www.sdeidev.com/lazarus/mac/trunk/03.png)
Unable to recompile Lazarus from itself. (idem).
Fig4 (http://www.sdeidev.com/lazarus/mac/trunk/04.png)
Many fonts are too large.
I am available to carry out all the tests you want but do you have a programmer with whom we can work live?
Cordially. Gilles
-
Hi GillesH,
2. Try to uncheck "Automatically adjust IDE main window height"(screenshot 1)
4. Rescan FPC sources, maybe it helps(screenshot 2)
-
Hello GetMem,
I try the first action. But Lazarus crashes when I validate the change. Bug report (http://www.sdeidev.com/lazarus/mac/trunk/Bug_01.txt) (Crash transmitted to Apple).
My fpc is that of the stable version (3.0.2). Must I compile the trunk version ? I think that's possible. I usually compile my environment Qt. Doing this with fpc should not be any more complicated :D
ADD : 2: It's OK - 4 : Obviously a directory problem. I will look tomorrow morning
Regards. Gilles
-
Hello,
4: OK. Aside from a font problem in the windows (screenshot (http://www.sdeidev.com/lazarus/mac/trunk/05.png)), Lazarus works normally (including the reported slowness that no longer exists). GDB is operational.
I can recompile it with the default settings from the IDE itself so I can integrate my own components.
But, the default configuration is i386 and not x86_64 and any attempt with this option fails (http://www.sdeidev.com/lazarus/mac/trunk/06.png).
Regards. Gilles