MacOS 14 (Sonoma)

[richmond62]

All versions of LiveCode that worked on MacOS 13 start the launch screen and then crash.

The build of OXT does the same thing.

Don't have time just now, but THIS is probably my next move:

https://www.igeeksblog.com/how-to-downg ... sing-data/

As made a Time machine backup 15 minutes before installing MacOS 14.

HOWEVER, things do not look good for the future, especially as on MacOS 13.5 versions of LC all the way back to 8.0.0 worked
without a hitch.
-

SShot 2023-06-18 at 19.15.30.png (106.3 KiB) Viewed 9549 times

[richmond62]

Although, to be fair, there was a similar problem with an early public beta of MacOS 13, which was sorted out in later releases.

[tperry2x]

Those debug files and crash logs that Sonoma generates, would be handy if we knew exactly what it was objecting to. With Mac OS being such a moving target to deploy to (the underlying code base is constantly shifting - just look at how far the metal API has come). Now with Vulcan graphics engine, the move to ARM, the abandonment of 32bit code - it could be any one of these that is causing the issue. Perhaps even a legacy piece of cruft that the Livecode engine still relies upon.

No small task to go through that and find where, but in my view, OpenXTalk needs to be fully self-contained as much as possible. So any dependencies are not tied into the OS. So any code changes by Apple (or on other platforms) don't break OpenXTalk - otherwise we'll be fighting a never-ending-battle trying to support 3 major platforms (+ mobile architectures) using a volunteer team with no budget.

[richmond62]

The AppImage Paul produced for Linux was very clever.

I don't know if the same sort of thing can be done for Macintosh.

[richmond62]

I wonder about a distribution of OXT that is a Java thing so it can be run on almost any platform?

[tperry2x]

I wonder about a distribution of OXT that is a Java thing so it can be run on almost any platform?

Hmmm, a web-based version is all well and good - but perhaps leads us down the cloud software route. If that's the case, you have hosting servers to worry about and a whole extra layer of security to worry about (as it's exposed to everyone with a web-browser to potentially try and hack).

If it was a java package that ran on the users machine, kind of the way a .jar file does, that might be one way - however, might be better to then use a more modern and responsive language if we are re-coding anyway. Java isn't known for it's speed when compared to other languages, nor it's security with gaping security holes in the v8 engine as of late.

Whilst rewriting the whole thing in assembly would be a non-starter, (even if it would be fast) and too complex to undertake, a more modern language might only be good to use if it could keep compatibility. It depends on what target systems we are aiming for. As C++ will pretty much compile for anything, while more modern languages such as rust may rule out support for Mac OS 10.8 (if we are developing for 32bit or PPC).

I gather that the majority of Livecode (and therefore OpenXTalk) is pretty much written in itself, with only a comparatively small percentage being C++. This is probably because it's best supported across all the target platforms.

Although there's a huge movement of 'apps' moving to the cloud and being hosted, that's all fine until you lose internet connection. If you are someone who takes your computer to a quiet space to be able to think and code, you may well not have internet, so I think it needs to remain an offline solution.

Just my opinion, and we know what they are like. As everyone has one.

[richmond62]

Oh: I'm schizophrenic, so I always have 2 opinions about everything.

Or, put another way, I have the unfortunate ability to see both sides of most arguments.

Now, quite apart from my opinions: On Monday I am 'off' to visit my son in Latvia, who, being a very sensible person indeed
spends 50% of his time in a wooden shack out in the wilds with a piano (he's a composer), his girlfriend, several cats, and NO internet.

"Objously", as OXT is still at a fudgy stage, I will be using LC 963 on my 32-bit laptop running Debian 12 XFCE, or on my 64-bit laptop
running Xubuntu 23.whatever [haven't worked out which laptop to take: although I think I could POSE more with the 32-bit one] . . .

sans interweb.

AND, as my retirement plans involve either volunteer teaching in Ladkh/Sikkim or Botswana (not known for reliable internet),
the idea of an app 'in the cloud' just turns me right off.

[tperry2x]

...the idea of an app 'in the cloud' just turns me right off.

Exactly!

[FourthWorld]

the idea of an app 'in the cloud' just turns me right off.

Making desktop standalones is the one area where LC shines brightest.

On mobile the tradeoffs of its half-baked implementation (e.g., the number of steps they require just to make a scrolling field scroll) make it at best an "also ran" compared with other tools.

The web is the weakest of the three, expected given the constraints of emulating a desktop environment by rendering into a canvas object from a language interpreted by an interpreted language.

I don't understand the proposition that the LiveCode language is difficult to sell when it's named "LiveCode" but somehow becomes easier when it's renamed "Xavvi".

Dev constraints with OpenXTalk may be a blessing in disguise, at least for GPL fans, forcing the project to focus on the one area where it shines most brightly.

[richmond62]

when it's named "LiveCode" but somehow becomes easier when it's renamed "Xavvi".

Well, if that is ALL that the LiveCode people have done [renamed 'LiveCode'], then 'Xavvi' is not 'savvy' at all, just a con.

Frankly, the change of name from 'Runtime Revolution' to 'LiveCode' did nothing to me, and I wonder if there was a sudden uptake in people buying licences {I doubt it]. When my mother got married to my father she changed her name from McIntosh to Mathewson [well, she had been brought up in England - in Scotland, traditionally, married women do NOT change their family name], but she did not change: so, LiveCode changing its name should fool no-one: let's see if the product changes: after all, if not that will be the 3rd (or 4th) time that company will have pulled a fast one.

I spent quite a lot of time pointing out that LC (the company formerly known as 'Runtime Revolution') were, frankly, wasting its time pursuing the chimaera of an HTML 'thing': their first effort was crap, and so was (is?) their second one.

I spent quite a lot of time pointing out that LC (the company formerly known as 'Runtime Revolution') were, frankly, wasting its time pursuing FileMaker people.

AS to ANdroid and iOS: well, I, for one would NOT use LiveCode to deevlop for either of those families of devices as the 'fiddling around' seems endless.

Instead of going blue in the face trying to 'smuggle' a quart of desktop LivCode into the pint of a telephone, I'd far rather spend my time getting to grips with one of those development environments that goes straight to the target devices.

I spent quite a lot of time pointing out that LC (the company formerly known as 'Runtime Revolution') would get better results if it focussed on ironing out the hundreds of bugs that have been sitting around in RR/LC like encysted staphylococcus since about RR 2. something-or-other.

I pointed out that by not sorting out those bugs and the resultant constant use of 'work-arounds' in the forums and on the use-list LC was generating bad, bad PR for itself.

AND: I got lots of 'flak' because of my constantly 'negative' attitude: Well 'screw you', that 'negative attitude' consisted of a series of observations about things that stuck out of the LC website and their cavalier attitude to their much-vaunted 'community' like a syphilitic nose.

Had the overgrown adolescent (and we all know who that is) deigned to listen to anyone [and now, like some tuppeny-happeny guru, he is preaching about 'mentoring' - having previously mentioning that he has had mental problems] listened (whether to me, or the (possibly) more diplomatic voices saying the same thing) there might be no 'Xavvi' until LC itself was completely 'savvy': which it most certainly is NOT at the moment.

The sad truth is that 'all those voices' saying 'slow down and retrench' were the voices of people who, while not developing LiveCode, were using it in one capacity or another in their daily lives.

COMMUNITY

When I lived in the United States (1993 - 1996) I found that, unlike in European countries, in shops the people who worked there ALWAYS listened very carefully to what their customers wanted: this impressed me no end (and it did about 3 years ago when I went shopping in Philadelphia, Chicago and New York - 2 week whistle-stop trip). For all of LiveCode's use of American English spelling, LiveCode, the company doesn't even behave like a Scots company, it behaves like a company somewhere in the Balkans or Egypt [I know, I have lived and worked in both]. As the vast majority of LiveCode's "community' are either from North America, or have been in some way AmericaniZed, the oriental approach of LiveCode will begin to chafe increasingly, resulting in . . .

[richmond62]

Dev constraints with OpenXTalk may be a blessing in disguise, at least for GPL fans, forcing the project to focus on the one area where it shines most brightly.

Let OpenXTalk be THE programming environment for Linux, Window and Macintosh desktop machines and nothing else: there is a huge
'market', educational and otherise, out 'there' for exactly those desktop environments.

[richmond62]

Standalones built with "963" DO work on MacOS 14, Sonoma.

[tperry2x]

Standalones built with "963" DO work on MacOS 14, Sonoma.

So it's just the development environment that's got the issue... somewhere.

[richmond62]

I'm "off" in Riga [which is well worth a visit] so have not had the chance to install the third developer beta on my Mac Mini.

Has anyone else?

What gives with LC?

[richmond62]

The Windows 64-bit version of LC 963 will work with WINE on MacOS 14 beta 3:

https://forums.livecode.com/viewtopic.p ... 1&start=15

[OpenXTalkPaul]

The Windows 64-bit version of LC 963 will work with WINE on MacOS 14 beta 3:

https://forums.livecode.com/viewtopic.p ... 1&start=15

Well SOME of it will work, it won't be accessing any macOS native APIs running it inside a WINE wrapper.

[OpenXTalkPaul]

As for MacOS 14 (Sonoma)... the same thing happened last year (or was it the year before?) with problems running under macOS 13 betas, but by the time Apple actually released the thing it was sorted out and required no changes (as far as I can tell) to the OXT IDE. Hopefully 14 will be the same situation. At least Apple is still supporting Intel CPUs in MacOS 14 so that's good and means we should still be able to run OXT IDE on older Macs and Hackintoshes for some time to come.

[richmond62]

As for MacOS 14 (Sonoma)... the same thing happened last year (or was it the year before?) with problems running under macOS 13 betas

How true, how true . . .

But it is possible that things won't go the same way with MacOS 14

It is also playing 'silly buggers' with GIMP {another great love in my harem].

[richmond62]

Well SOME of it will work, it won't be accessing any macOS native APIs running it inside a WINE wrapper.

Should that matter?

Certainly, for my Devawriter Pro and the bumbly-kiddy guff for my school that is neither here nor there, as, my Devawriter Pro has, over the 14 years it has been on the go, has been back-and-forth between Linux and Macintosh about 6 times.

[richmond62]

HOWEVER . . . major negative gubbins:

A Mac standalone built with LC 963 Windows 64-bit under WINE on MacOS 14 will NOT run on MacOS 14.