Which deployment target version should we aim at? Qt 5.12 (current stable) only supports 10.12
and up (https://doc.qt.io/qt-5/macos.html). Is that reasonable? Note that users of older versions can
still compile from source or use Macports/Homebrew to get the command line tools.
Anyone with experience dealing with this matters, notably using CMake and Qt as development
platform?
I’m sorry for the trouble QtConsole on Mac is causing. And I miss the hw to test…
Clearly, Qt isn’t at all a silver bullet. And it’s also become most unusable on my Ubuntu. A debugging session takes ages…
These days I’m working on iOS,Android,ReactNative,Expo,WordPress… your plan to switch to HTML5 still seems a great idea. To rewrite the console in NodeJS should be doable… Alas, tempus fugit…
Part of the trouble was that I did not specify a deployment target with CMake. I always used to be very far behind with my MacOS, so that was not a problem. Now I’m completely up-to-date @ridgeworks now claims its runs on one of his Macs, but not on the other running the same (10.13) os. This also applies to the command line tools though, so it seems unrelated to Qt. This should be resolved unless it is something really specific and wrong with this Mac. That is why I would like more experiences running the bundle on several MacOS versions.
I hardly ever use the Qt window on Ubuntu. IMO the normal terminal (I use terminator) console is just fine: fast and lightweight with good completion, etc. That basically also applies to the Mac, but if you want to make the system available as a bundled app you need to provide a GUI (I think, let someone correct me if it is also possible to open a terminal with a command from a .app).
Problems with slow debugging might be unrelated. Sure this only happens in the Qt console?
That said, a console with menus written in a suitable high level language would be nice to have, especially if it is easily ported and can replace swipl-win on MacOS and Windows (and others).
No, everything that references QtWidgets (or other large) libraries. Debuggable images are so heavy… and apparently QtCreator expect I know the magic to force the toolchain to keep those chunks in memory… no way, every time it reloads.
Not sure if this helps… But anyway here are my experiences on MacOS.
I have MacOS 10.14.4 Mojave and SWI Prolog 8.0.2.
Running the SWI-Prolog app works fine, the graphic resolution of the interface is reduced though and the font menu does not seem to have any effect. Running swipl from Terminal works great (subjectively it seems very fast, maybe more than previous versions).
Thanks. What this topic is about though is to deal with the version problems for the 8.1.5 installer. This was built on the latest 10.14 MacOS with the latest tool and, while it seems to fix the font issues, it seems to run problematically on some Macs. Should support Macs running 10.12 or later.
This might be cause by the Macports dependencies that seem to have no deployment target set.
Seems the latest reincarnation (http://www.swi-prolog.org/download/devel/bin/swipl-8.1.5-4.x86_64.dmg) of the MacOS bundle works. Instead of using the dependencies from Macports it now compiles them from source. A script for downloading and compiling the dependencies is included in the (git) source in scripts/macos-deps.sh.
If you appreciate a good GUI version for the Mac, please test and suggest improvements. Current status:
Should run on MacOS 10.12 or later
Only 64-bit
TLS (HTTPS) seems to work now
Basic compilation of packs with C code should work if Xcode is installed.
Proper initialization of the locale (character set) is probably still not good. I have little clue how that must be done for a MacOS app.
Starts in /. Is that ok/normal?
Etc. I hardly ever use a Mac application except for Terminal
