MacOS 14 (Sonoma)

[tperry2x]

..I have timetabled October 15th for my attempt to get my Mac Mini back to MacOS 13 'Ventura'...

Just a weird idea. I was wondering if you can just try something before you revert back to MacOS 13.
Could you please try installing the xCode14 command-line tools, and see if after a reboot, if OpenXTalk / LC 9.6.x will function?

https://developer.apple.com/xcode/resources/

My hope is that by adding these in, that we might have something running.
I mention xCode14 as I think that's what 9.6.x is built in, and what the dependencies would be.
It should be available on that link under "Command line tools and old versions of Xcode"

The most recent MacOS I can run here is MacOS 12 Monterey.

[richmond62]

Yes, I'll try and manage that on Saturday, as for the next 2 days I'm getting "down and dirty" with EFL and some determined and hard-working kids.

Mind you, you are going to rub quite a few end-users up the wrong way if you ask them to install that large file alongside OXT.

[richmond62]

OK, OK; I'm the biggest sucker of all: currently the Mac Mini is at MacOS 14.1 beta 1 and, NO JOY with any LiveCode 'Community' versions.

Both of my recent Macs [MacOS 12 and MacOS 14] playing 'silly buggers' when I try to reset my Mac App Store login, so currently doing THIS:

https://archive.org/download/xcode-14.0-beta2

with MacOS 10.7 'Tired Lion' at school.

Onto a flash-drive to take home for the weekend.

https://en.wikipedia.org/wiki/Something_for_the_Weekend

[tperry2x]

Good luck.
This is exactly why I use rescuezilla for all my Macs, PCs and Linux machines I need to make a backup of. It's easy to clone and restore whenever you feel like it. No app store or redownloading required.

[tperry2x]

Mind you, you are going to rub quite a few end-users up the wrong way if you ask them to install that large file alongside OXT.

I honestly don't think it's too much of an issue. I mean, Linux users commonly have to download extra dependencies all the time, so this wouldn't be too different. The command line tools should suffice, and only about 140mb if I recall. So not too bad.

Mac users should be used to huge downloads, where each update is multiple Gb in size.
The only thing, I think it has to be launched via the terminal otherwise it'll refuse to run. Not too much of a problem if it works as it could detect the OS version and run from the installer.

That's if it works, fingers crossed.

[richmond62]

xCode Command line tools make no difference at all: 963 does NOT run on MacOS 14 Sonoma.

Gif a Mac standalone generated by LC 9.6.3 Community runs on MacOS 14, while the IDE does not, what is the difference between the engine that powers the IDE and the engine that powers the standalone?

I wonder if one cannot, in some way, use the standalone engine inwith the IDE, and things micht wark!

A "quick-n-dirty" engine switch from the Mac standalone engine package results in an app that plays 'bouncy-bouncy' in the dock for about 2 minutes and then quits (MacOS 12).

[tperry2x]

As far as I understand, (although I'm still learning about how this is all put together slowly)
The engines used to assemble the standalones are in the runtime folders.

The engine that actually runs the livecode application is different, hasn't been updated as frequently as the runtimes by the look of it. (this will need recoding and is why arm support is such a pain to add). Yes. The updated engine exists as part of 9.6.10 - but because this isn't a community / open source offering, I can't incorporate it into any official releases.

Getting the source of 9.6.10 will equally be just as unlikely, so without an engine rewrite like what's been done in 9.6.10, we are a bit stuck...

The most annoying thing is not knowing.
Was it just a few lines of code that needed changing, or are we talking a complete rework and recompile using new updated Mac, Win and Linux dependencies at the XCode / Visual Studio / GCC-compiler level? (Probably the latter)

[richmond62]

Was it just a few lines of code that needed changing, or are we talking a complete rework and recompile using new updated Mac, Win and Linux dependencies at the XCode / Visual Studio / GCC-compiler level? (Probably the latter)
Top

Well, at the risk of coming across as a right 'arrogant bit of shit', it was me who first reported the 'non' re LC 963 on Sonoma, and within 3 days Mark Waddingham [and, let's not be coy, he is the power behind the throne] released a version of 9.6.10 that ran on Sonoma: that does NOT look like anything overly complex:

1. Obviously MW worked out, very quickly indeed, what needed to be done.

2. Did what needed to be done in 'short order'.

Unfortunately, LiveCode do not see it in their interest [obviously do see OXT as some sort of competitor] to tell us how to 'retune the fiddle'.

AND, here is what are old friend and informant William Shakespeare (that well-known computer programmer) said: "here's the rub."

And the 'rub' is that, as LiveCode believe they can claw back some of the Open Source users of LC with both 9610 and the mysterious 'new GUI' of LC X, and, as such, are NOT going to to lob us any 'fricking bone' [pace Doctor Evil], as the feel that if "we" (funny word, that) might provide something that will stop OS-users forking out BIG BUCKS for their thing.

AND that would seem to tell us there is NO complete rework and recompile using new updated Mac, Win and Linux dependencies: just a few clever tweaks.

[FourthWorld]

AND that would seem to tell us there is NO complete rework and recompile using new updated Mac, Win and Linux dependencies: just a few clever tweaks.

How does one make engine tweaks without recompiling the engine?

[richmond62]

How does one make engine tweaks without recompiling the engine?

One doesn't, and that was a 'slip between cup and lip'.

Was it just a few lines of code that needed changing, or are we talking a complete rework

But, there is a lot of difference between 'a few lines of code' [followed by compiling the engine] and 'a complete rework' [followed by compiling the engine].

[richmond62]

LiveCode Panos has written this:

Unfortunately there is no workaround. On MacOS Sonoma it seems they have changed the way menus are treated, and this causes a crash in the affected versions of the engine c++ code.

And I have discovered that stacks that feature NO menus (as in stuff in the Mac Menubar) seem to work on MacOS 14.

So, I would suggest that people who need menus for their standalones use hamburger menus.
-

Screen Shot 2023-10-01 at 20.12.10.png (190.75 KiB) Viewed 2165 times

-

[richmond62]

Demonstration of a hamburger menu, without the 'benefit' of SVG images: assembled with LC 8.1.10 on MacOS 10.7 "Tired Lion":
-

Screen Shot 2023-10-03 at 1.04.56 pm.jpg (68.23 KiB) Viewed 2140 times

-
Certainly one way to have your cake and eat it.

One of the less obvious advantages of using hamburger menus is that menu-wise, this will result in greater consistency cross-platform.

[OpenXTalkPaul]

As I mentioned elsewhere....
Thanks to Richmond's sleuthing and upon cross referencing that with what Apple has actually changed in Cocoa/AppKit it seems highly likely that Apple's COMPLETE rewrite of NSMenu and company combined with custom (subclassing?) menubar altering done by the IDE menubar is the culprit here. By menu altering, what I mean is that it's most likely the stuff like removing the macOS standard window tabbing menu items that come with the default menu bar normally provided by the OS, in lieu of actually supporting the OS's current standard, that is the crux of the problem. And so as long as long as no engine-built custom menu is used on Sonoma, the rest is the engine runs fine (maybe?). The chain of events in Home Stack's 'On StartUp' handler is when the menubar does its customizing so that would be why the crash is at the IDE splash screen.

I wonder if using the Mac native Status Menu extension also causes a crash? This uses FFI to create an NSMenu and then inserts it into the 'Status Menu' area of the mac's global system menubar. I cannot yet test that since I don't yet have Sonoma installed anywhere. And how about menu buttons? Those must also create NSMenus objects, are those effected?
Even if we cannot work around this without editing the engine source and recompiling Mac build, this will help narrow it down for when we get to that.

I was also thinking a stop-gap measure, until we can get it fixed on the Engine source level, could be an Extension Builder library that creates NSMenus and passes along notification from (and to?) those menus like a delegate, using ExBuilder's 'POST' syntax to send something like 'doMenu [pMenumessage]" to the calling stack. I've already done some messing about with that sort of thing anyway, simply because I wanted to use the native window tabbing menus provided by macOS (but hidden away by the Engine), which actually do work fine with stack windows if you can get those menus to show (which there was a trick that could make that happen in earlier versions). It's free functionality provided by the OS so why not use it? It seems like the only reason might have been because it would've been a feature only available on macOS?

Anyway, since it is most likely Apple's macOS14 NSMenu rewrite at the root of the problem it certainly would not affect running on any non-macOS platforms.

[OpenXTalkPaul]

I think I read somewhere recently that new version of NSMenu stuff had some changes where NSMenu can't be empty/void, or something like that...
Looking though some of the C++ / ObjC code now, seeing how on macOS it maps it's internal MCMenu stuff to the 'native' NSMenu stuff, and reading through the comments... there was some NSMenu-related memory leak patch done in 2019.

https://github.com/livecode/livecode/bl ... ac-menu.mm

Richmond does your menu-less test app have any menubar at all? I would think it should at least have some of the macOS-provided basic menus (File,Edit,View,Help, etc.).

[OpenXTalkPaul]

..I have timetabled October 15th for my attempt to get my Mac Mini back to MacOS 13 'Ventura'...

My hope is that by adding these in, that we might have something running.
I mention xCode14 as I think that's what 9.6.x is built in, and what the dependencies would be.
It should be available on that link under "Command line tools and old versions of Xcode"

The most recent MacOS I can run here is MacOS 12 Monterey.

If you can run macOS 12 then you should be able to use OpenCore patcher to run 14 fairly well, but that puts you into totally unsupported territory (but you will get all of the latest greatest security patches).

I don't think t 9.6.was built with Xcode 14, at least it wasn't in the past, but you can patch newer versions with SDKs to support building for older macOS versions (10.9+ in our case). I remember someone (Monte) building on 10.12 (That's 'Sierra' not 12.x). But I'm sure that nothing that comes just by installing with X-Code is going to fix this problem. I'm almost positive its related to the Sonoma Cocoa/AppKit w/ NSMenu rewrite.

[richmond62]

The 'funny' thing is that ALL the other third party apps that ran on MacOS 13 continue to run on MacOS 14, so it is obviously something that LiveCode 'done' that causes the problem.

[richmond62]

On Macintosh the /Contents/MacOS/LiveCode file of 9.6.10 weighs in at 32 MB, while the /Contents/MacOS/LiveCode-Community file of 9.6.3 weighs in at 16.3 MB. As I do NOT have access to the earlier recension of 9.6.10 (the one without the 'hot fix' to run on Sonoma - my stupidity, deleted 9.6.9), I have no way of determining if the apparent 'bloat' is just commercial or a result of the hot fix.

[richmond62]

Some of that bloat is the commercial registration stuff: I transferred the 'LiveCode' file out of 9.6.10 into 963 and renamed it "LiveCode-Community" and got a registration request.

I would assume that the Mac engine for standalones in 9.6.10 ALSO sorts out the problem (Menu problem), so comparing that with the 963 engine may also prove instructive.

[richmond62]

And so, MacOS 14.1 beta 2 . . .

. . . the splash screens of LC and OXT come and go in the blink of an eye, far, far faster than 14.1 beta 1 . . . bugger all good that it does though.

As I do not need my 2018 Mac Mini at them moment I will not be downgrading it to MacOS 13 ...

[richmond62]

MacOS 14,1 beta 3 . . .

The splash screens hang around longer than with the beta 2: but THAT is all.