What I'm adding, and what I'm planning next...

[richmond62]

Bonus bragging . . .

That's a Windows executable in a wineskin wrapper on MacOS.

Well, I was doing that with LC 963 and MacOS Snowman for quite some time.

The only snag (and quite a big snag) was hiving off MacOS standalones . . . that did not function in MacOS.

[tperry2x]

Bonus bragging . . .
That's a Windows executable in a wineskin wrapper on MacOS.

Correct. And an updated one, based on this, to work on MacOS 10.15.4 through to (in theory) MacOS 14.

[overclockedmind]

Sorry to be so blunt, but Apple isn't Apple anymore. Those who don't see it, simply refuse to see it.

I think you are right, and it's a real pity.
I wonder if this method would be the future option for running OXT lite on MacOS?
No prizes, but bonus bragging rights if you can spot what might be different to this version I open, as opposed to the normal MacOS 1.03 version.

Wineskin.

[tperry2x]

Wineskin.

Yes, that's the one, but modded for newer MacOS.
The thinking being that it's a way of providing a newer engine (9.7) if the mac version won't compile. Hopefully it won't come to that. Otherwise, anyone is welcome to try compiling it.

Paul mentioned that the code might be intended to compile under Big Sur (which I can't run here as don't have anything capable of running it, let-alone compiling in it). - But, I don't mean to heap this job onto Paul, so with the link above, it's fair-game for anyone to have a go at.

[OpenXTalkPaul]

The only snag (and quite a big snag) was hiving off MacOS standalones . . . that did not function in MacOS.

That's not the only snag, no maOS native functionality is going to work with a Windows version running in a Virtualization, and to make a 'standalone' of sorts you would have to include Wine Engine.

Paul mentioned that the code might be intended to compile under Big Sur (which I can't run here as don't have anything capable of running it, let-alone compiling in it). - But, I don't mean to heap this job onto Paul, so with the link above, it's fair-game for anyone to have a go at.

What I meant was I think they must have been compiling on BigSur, but 9.6.3 the build target macOS SDK is 10.9 (Intel 64 bit arch only, 32bit was dropped after 9.6.1). They were likely testing the build on macOS 11 because there's BigSur related bug fixes listed, so it would make sense to compile on that too (the testing automated).
If you read through the Gitter.im LiveCode dev chat group, Monte mentions compiling on macOS 10.12, but maybe he meant macOS 12? Not sure.

[tperry2x]

(Intel 64 bit arch only, 32bit was dropped after 9.6.1). They were likely testing the build on macOS 11 because there's BigSur related bug fixes listed,

That potentially means that no 32-bit mac standalone can be produced if I did succeed in updating the mac engine to the 9.7-dp1 github version (?) I wonder if that was dropped in the standalone builder, or if it was axed via the engine directly.

...read through the Gitter.im LiveCode dev chat group, Monte mentions compiling on macOS 10.12, but maybe he meant macOS 12? Not sure.

I wasn't aware there's a LiveCode dev chat group (?)
Have tried on MacOS 10.13 and got the results mentioned previously. It would make sense that they were doing this on big sur.

[tperry2x]

I've also made this conditional, so you can turn it on and off via the preferences:

conditional-preset-sizes.gif (140.35 KiB) Viewed 314 times

[tperry2x]

Also added this for Linux users.
If this is turned on, the engine uses the system's shared memory extension (if available) to speed up rendering.
The setting of this property has no effect on MacOS or Windows. (It's a Linux-only thing).

also-added.png (6.19 KiB) Viewed 314 times

[tperry2x]

(Intel 64 bit arch only, 32bit was dropped after 9.6.1).

That potentially means that no 32-bit mac standalone can be produced if I did succeed in updating the mac engine to the 9.7-dp1 github version (?)

Just checked:

engine-test.gif (89.44 KiB) Viewed 298 times

I can make a stack on linux (using the 9.7-dp1 engine from my recompile).
I can save this as a 32-bit MacOSX standalone
Transfer to the old MacOS machine, and confirm it's running in 32bit mode.

If anyone is wondering why didn't I make the stack on the Mac version of OXT lite - it's because it wouldn't have been a worthwhile test. That version of the engine is stuck at 9.6.3, so I wanted to check that the 32-bit build option hadn't been disabled in-engine in 9.7-dp1 (which it hasn't been by the look of this).

Long story short: looks like we can retain MacOSX 32-bit compatibility for a while longer.

[OpenXTalkPaul]

I've also made this conditional, so you can turn it on and off via the preferences:
conditional-preset-sizes.gif

Excellent!
Will help me in merging too!

Having all the things like this as optional is a great, one thing I'd also like to get to is for everything to be user customizable. The reason being can be seen in this instance in that U.S. Letter/Legal/Tabloid Paper standard sizes may not be particularly useful for someone that's not even printing or if they are maybe not buying printer paper in the USA. So I propose we can have simply line-delimited or tab delimited IDE .conf configuration files in the user's folder for things like this.

I was thinking that these extra Sizes, along with IDE / syntax coloring sets, and color swatch palettes (those GIMP .gpl files, two palettes I've worked on and that GIF Editing library could all benefit from supporting color swatches / color tables files). Eventually I wanted to also make 'Template' stacks a thing, and also Auto-completion snippet additions could be added in there as well. They would be loaded via directory in the ~/My OpenXTalk/ (or ~/.openxtalk/) folder (where user installed extensions get installed). They'll be setup in the same way as other parts of the IDE in that the content can be extend over the content included in the IDE folders (such as the AddOns/ or the revLibIcons stuff for examples).

A little work would be needed for syntax coloring sets so as to not be limited to the hard-coded sets. I think those get stored as an array so should be able to replace/add to that array.

I want to be able to set the IDE highlight colors too, like the color of the highlight block in the Tools pal, which currently in my build it's still that 'OXT' violet color/ Really this color should be auto-set to what the user has selected in their operating system/ UI theme. I have extension the can get the system wide user selection color on macOS. Did you implement something to get the equivalent from the elected theme on Linux/FreeDesktop compliant OS UIs? Or did you already make this a user-settable pref?

I'm currently cleaning up my dev projects folders again and I really want to do a 'Deluxe' release before moving on to making a serious effort to do a 'clean' build of LC CE 9.6.3 for the mac engine binary (and then moving on from there to doing some editing to it).

[OpenXTalkPaul]

That potentially means that no 32-bit mac standalone can be produced if I did succeed in updating the mac engine to the 9.7-dp1 github version (?) I wonder if that was dropped in the standalone builder, or if it was axed via the engine directly.

Not sure how your SBuilder is set up, but my 9.6.1-based 32bit-building (re-) setup, builds from as separate 32 bit standalone build folder/procedure. The older scripts would build 'FAT' 32+64 and then called on 'Lipo' command line to strip out the unused architecture bits for 32-only or 64 only. Currently we want 32-only as a back-porting option only, since 32 bit on macOS has long been deprecated at this point 10.8, and the 32bit engine is 9.6.1 (not 9.6.3).

I wasn't aware there's a LiveCode dev chat group (?)

Yeah, but its not at all active these days:
https://app.gitter.im/#/room/#LiveCode_Lobby:gitter.im

[OpenXTalkPaul]

From the last posts in that chat room:

brucemontegani (Bruce Montegani)
Is there a reason the engine is still being built against MacOS SDK 10.9? It would seem that it would be easier for Livecode to drop support for old versions and only support newer versions both for MacOS and iOS. 10.9 (Mavericks) was released in 2013 and the last update was in July 2016. Anyway, which SDKs do I need to install to get livecode to compile. This includes:

engine/ — The main LiveCode engine. This directory produces the IDE, "standalone", "installer" and "server" engines

Non-third-party libraries:
libcore/ — A static library that provides various basic functions and types, and is used by many of the other subprojects

libexternal/ and libexternalv1 — Static libraries that support the LiveCode "external" interface, which allows the engine to load plugins

Externals (libraries that can be dynamically loaded into the engine at runtime):
revdb/ — Database access external, and drivers for various backend database systems

revmobile/ — The iOS support external (which can only be built on Mac) and the Android support external (available on all desktop platforms)

revpdfprinter/ — Print-to-PDF functionality

revspeech/ — Text-to-speech support

revvideograbber/ — Video capture (Windows only)

revxml/ — XML parsing and generation

revzip/ - Zip archive management

Can I install the latest sdks?

montegoulding (Monte Goulding)
We build and run tests against macOS 10.11 on Travis so you could go with that if you want (requires extra configuration). The simplest is to download Xcode 6.2 and use the script as described to symlink the SDK into a newer version of Xcode.

I don't have a machine that runs El Capitain v10.11, I skipped over that macOS version, but I suppose it could be set up, maybe in a VM, for compiling purposes.

ICUDK, 'Travis' is an automated build system:
https://www.travis-ci.com

[tperry2x]

Did you implement something to get the equivalent from the elected theme on Linux/FreeDesktop compliant OS UIs? Or did you already make this a user-settable pref?

I made this a user settable pref:

selector.png (1.94 KiB) Viewed 201 times

Only because you can theme Linux and Windows (to a lesser extent), so having something that picks up on whatever theme might be in use is quite hard. I thought it was simpler just to let the user select their own colour for the tool button hover/select colours.

I'm currently cleaning up my dev projects folders again and I really want to do a 'Deluxe' release before moving on to making a serious effort to do a 'clean' build of LC CE 9.6.3 for the mac engine binary (and then moving on from there to doing some editing to it).

That would be great. If you can get that engine to compile. Using the 9.7 source from github for the engine though would bring a lot more fixes to the party for MacOS. These are fixed in the 9.7 engine:

• X and Y Co-ordinates now should be correct for multi-screen macOS systems.

• Placing buttons and progress bars on a card will no longer cause slowdowns on macOS 10.10 or later.

• When opening the IDE menus on macOS, there should no longer be a delay.

• The engine will no longer crash when accessing the camera or microphone on recent versions of macOS X.

• Scripts which run without locking the screen are a lot faster (macOS Big Sur and later)

• If lots of fonts are loaded into memory, the time to quit the IDE has been improved.

• If an engine runtime error occurs, an error dialog will be displayed rather than failing silently.

• While typing in the script editor, performance has been improved.

• If you open and close the message box, the IDE used to get slower. Fixed.

[tperry2x]

Not sure how your SBuilder is set up, but my 9.6.1-based 32bit-building (re-) setup, builds from as separate 32 bit standalone build folder/procedure. The older scripts would build 'FAT' 32+64 and then called on 'Lipo' command line to strip out the unused architecture bits for 32-only or 64 only. Currently we want 32-only as a back-porting option only, since 32 bit on macOS has long been deprecated at this point 10.8, and the 32bit engine is 9.6.1 (not 9.6.3).

Not depreciated in my version, I re-enabled it again in the standalone builder a while back.
My version uses lipo too, resulting in non-fat (slimmed-down / specific x32 and x64) binaries:

sb-oxt-lite.png (24.44 KiB) Viewed 200 times

[tperry2x]

Poking around in the various LCC builds, I think I spotted a typo.
In 9.0, this file seems to be incorrectly spelt - and seems to have been incorrectly spelt all the way up to 9.6.3 and 9.7 from what I can tell. The IDE is looking for the file with the correct spelling, so I've corrected it. I'm not sure yet what side-effect this might have. (good or bad) - more testing to be done, but it seems like it would allow mobile/android built apk and iOS apps - the datagrid should recognise a swipe gesture.

strange.png (179.22 KiB) Viewed 261 times

[tperry2x]

I'll cover those points from that chat room (as far as I'm concerned anyway):

Is there a reason the engine is still being built against MacOS SDK 10.9? It would seem that it would be easier for Livecode to drop support for old versions and only support newer versions both for MacOS and iOS. 10.9 (Mavericks) was released in 2013 and the last update was in July 2016.

If I had my way, I'd support MacOS X 10.6 or further back to PPC. Why can't we have some backwards compatibility as well as MacOS 14+?

Anyway, which SDKs do I need to install to get livecode to compile.

The instructions are here for Mac compile environment setup. You need multiple versions of xCode (6.2.1 > 8.3)

engine/ — The main LiveCode engine. This directory produces the IDE, "standalone", "installer" and "server" engines

Yes, but I only care about the 'Engine' - not fussed about the others at this point. Baby steps first.

libcore/ — A static library that provides various basic functions and types, and is used by many of the other subprojects
libexternal/ and libexternalv1 — Static libraries that support the LiveCode "external" interface, which allows the engine to load plugins
Externals (libraries that can be dynamically loaded into the engine at runtime):
revdb/ — Database access external, and drivers for various backend database systems
revmobile/ — The iOS support external (which can only be built on Mac) and the Android support external (available on all desktop platforms)
revpdfprinter/ — Print-to-PDF functionality
revspeech/ — Text-to-speech support
revvideograbber/ — Video capture (Windows only)
revxml/ — XML parsing and generation
revzip/ - Zip archive management

Aren't these all part of the Mac prebuilts - I believe all these libs are included inside the tar.bz2 files. You can manually copy these into the 'Fetched' folder, to skip all the hassle of the gyp build script trying to access them from the livecode server, which obviously it can't do.

Can I install the latest sdks?

Yes, and if retaining support for 10.9, need to install and link additional xCode versions in /Applications/xCode_Dev/

We build and run tests against macOS 10.11 on Travis so you could go with that if you want (requires extra configuration). The simplest is to download Xcode 6.2 and use the script as described to symlink the SDK into a newer version of Xcode.

Yes, exactly my point above - but wrong MacOS version?

I don't have a machine that runs El Capitain v10.11, I skipped over that macOS version, but I suppose it could be set up, maybe in a VM, for compiling purposes.

Do they mean MacOS 11?

[OpenXTalkPaul]

Not sure how your SBuilder is set up, but my 9.6.1-based 32bit-building (re-) setup, builds from as separate 32 bit standalone build folder/procedure. The older scripts would build 'FAT' 32+64 and then called on 'Lipo' command line to strip out the unused architecture bits for 32-only or 64 only. Currently we want 32-only as a back-porting option only, since 32 bit on macOS has long been deprecated at this point 10.8, and the 32bit engine is 9.6.1 (not 9.6.3).

Not depreciated in my version, I re-enabled it again in the standalone builder a while back.
My version uses lipo too, resulting in non-fat (slimmed-down / specific x32 and x64) binaries:
sb-oxt-lite.png

I think mine is the same, I recall now that originally I tried to make this use 32-bit-slice-only binary (to save on a few megabytes of space) and then change script to skip the lipo part of the SB building process but I couldn't get that to work correctly for some reason and so just left it as-was.

I still think it would be cool to also add back-in an even older back-port option, back to a PowerPC engine. Such as build script would need to down save the stack versions of all stacks down to like vers. 4 or 5 stack file format (loosing bits like Widgets and better Unicode support).

[tperry2x]

I still think it would be cool to also add back-in an even older back-port option, back to a PowerPC engine. Such as build script would need to down save the stack versions of all stacks down to like vers. 4 or 5 stack file format (loosing bits like Widgets and better Unicode support).

Me too. In fact, it makes me wonder if I can look at an older LCC standalone builder and pull the 10.4 PPC > 10.6 routines from it.

[tperry2x]

Today, I've been going through removing typos like this:

typos.png (104.53 KiB) Viewed 231 times

[OpenXTalkPaul]

Today, I've been going through removing typos like this:
typos.png

Hah I've corrected little things like that in a few comments, it just looks sloppy but has no actual effect on the IDE operations.

That was my thoughts on PPC engine, might possibly need 'lipo' still, as that probably used a PPC32/Intel32 'FAT' binary. The PPC Engine binary can certainly be lifted from 6.5.2 (IIRC) Community edition. It seems the standalone 'building' is not so much 'building' as it is more the 'linking' part of compilation. Again, must ensure stack files are in 6.x compatible stack format version before building.