Left holding the flame.

[richmond62]

LiveCode have released a film with their CEO:

https://future.livecode.com/

LiveCode 10 is the last feature release of LiveCode "Classic". We will continue to maintain Classic (with bug fixes and OS compatibility only) until 2027.

This means that in 2-3 years LC will be the web-based thing it is becoming to the exclusion of any compatibility with what is now thought of as LiveCode.

The blue half of this masthead made me laugh so loudly I fell off my chair:
-

Screenshot 2024-07-24 at 14.25.16.png (59.37 KiB) Viewed 1609 times

-
What this really means is that, if things go on the way they are, in 2027 the ONLY xTalk IDEs (as we now understand them) that will be available will be those in the OXT family.
-
These videos are Wistia ones: personally I downloaded them using the Wistia plugin in the Brave browser so I could enlarge them, take screen shots, and generally analyse their content at my leisure.

[richmond62]

I have a degree in Philosophy which means that I have a poisonous turn of mind when I see statements of this sort:

We’ve increased our investment by 7x

https://livecode.com/livecode-future/

My first question is going to be "What investment was there before you multiplied it by seven?"

I could claim this, as, over the last year I have invested an average of 2 hours a month towards my Devawriter: but, just last week I 'multiplied' that to spend 24 hours: so I can claim that I "increased my investment 12 fold", which, while looking impressive, is actually nothing much at all.

Build complex workflows with ease.

'Ease' is such a subjective word: I wonder how my 94 year old Mum, with NO programming experience, would manage: equally so, any one of the 2 dozen 8-9 year olds who attend my language school.

It’s no code, without the limits.

This is distinctly odd, as right after that statement there is a screenshot with code in it:
-

Screenshot 2024-07-24 at 14.45.49.png (47.79 KiB) Viewed 1606 times

-

We’ve added multiple undo/redo throughout the IDE

That is a FANTASTIC addition.

[richmond62]

In light of at least one of the remarks over here

https://forums.livecode.com/viewtopic.php?f=9&t=39255

we very well might be left holding the flame, and, slowly, but surely, develop a slightly more serious following than the "four and a half" we have at the moment.

[tperry2x]

There is a quote on that forum, which reads:

Unless something dramatic happens with OpenXTalk (meaning they get external funding for dedicated development or there is an influx of C-developers to push engine development), that probably isn’t a great long term strategy.

Probably very true, however OXT (certainly the lite version), will continue to be free - of course - and allow anyone to develop apps for desktop OS, with no license required.

The only fly(s) in the ointment would be arm support and the MacOS menubar issue. If we had fixes for those two issues in the engine, then OXT would a much more favorable option. The other engine fixes / additions can come later of course, but those take priority.

This is also why I'm a fan of not completely redesigning everything, as it needs to at least look familiar.
I think we have a lot of users who download lite, but just aren't very vocal on here. It's certainly more than 4 (and a half) - more like a couple of hundred*.

* I'm basing that off my server logs for where the updates are retrieved from - (unique IPs), unless it's just a couple of classrooms worth of students somewhere, on OXT lite - all checking for updates

[richmond62]

It's certainly more than 4 (and a half) - more like a couple of hundred.

It would be extremely nice if they could show their heads above the trench.

[richmond62]

So: "here" we are:
-

Screenshot 2024-07-25 at 11.44.28.png (108.92 KiB) Viewed 1523 times

-

Screenshot 2024-07-25 at 11.46.40.png (92.5 KiB) Viewed 1523 times

-
And why does it seem odd that on this page:

https://livecode.com/livecode-future/

we've got this sort of thing:
-

Screenshot 2024-07-25 at 11.55.43.png (138.09 KiB) Viewed 1523 times

-
yet there seems no way to use that GUI with LC 10.0.0 RC 1?

As I can see only 1 possible advantage re LiveCode at the moment (= the Mac ARM engine), which is possibly in our pipeline (see post elsewhere: https://openxtalk.org/forum/viewtopic.php?p=9832#p9832), surely one (at least) of the ways to sell the new interface is to let potential customers play with it . . . at no cost to themselves.

[richmond62]

One of the things that brings me great joy is that the licensing and payments have, again, been completely restructured:

If you use Create to build apps for sale to the public, either via an app store or your own website, then you will need a developer seat plus you will make application payments on the revenue generated by the app. These payments will never be more than 5% of the app revenue, and only apply to revenue directly generated by the app. As the app earns more, the percentage required to be paid for the use of Create falls.

In another rather confusing way.

Our 'licensing and payment structure' looks better and better.

Although we have to find a way to raise some money to pay for an engine developer.

[tperry2x]

As with any task such as this, it's an investment on our part.
A developer who is seriously looking at an arm port would have done this kind of thing previously. Also, they'd be able to give you an accurate estimate of the costs required up-front before any work took place.

They would also have examples of previous successful ports to other processor architectures under their belt.

I don't see why the time scale of between 3-6 months was applied? Don't forget, you are asking someone (working on their own I'd assume), to achieve what a team of people were working on over at LC.

It might not be necessary, because if we could only get the thing to recompile, we'd perhaps know what we were missing. At the moment, the whac-a-mole analogy isn't too far off.

[richmond62]

As far as I understand, that chap might get a few people to work on that as he seems to think it can be done fairly quickly.

"3 - 6 months": well, I picked a random period as nobody else seems to be doing anything whatsoever in this direction.

[tperry2x]

As far as I understand, that chap might get a few people to work on that as he seems to think it can be done fairly quickly.

I'd like to hope so. There's hints in the engine's code that seem to imply it has the arm underpinnings already (in the 9.7.0-dp1 source), but without getting a successful compile on MacOS, I'd never know for sure.

I think the biggest hurdles are going to be adjusting the execution code as need be for ARM, and making ARM versions of the standalone build targets (as without being able to compile apps for ARM macs, then there's not much point), then the macOS 11+ menubar issue - also known as the "whack-a-mole spectacular".

[micmac]

then the macOS 11+ menubar issue - also known as the "whack-a-mole spectacular".

I remember the original patcher (also called Tom) offered to look at the engine code

Mic

[tperry2x]

I remember the original patcher (also called Tom) offered to look at the engine code
Mic

He did, and his efforts were very well received. I was especially thankful of his addition. It turns out though that it had unforseen issues with corrupted image data in built MacOS standalones.

I could replicate the error which first showed up on Richmond's Devawriter stack with the menubar patch in, when built into a standalone. (thread here)
But with the menubar patch removed, and rebuilt as a standalone - worked fine with no corruption of images.

So the patch did what it was supposed to, but had unintended consequences for standalones.

[OpenXTalkPaul]

There's hints in the engine's code that seem to imply it has the arm underpinnings already (in the 9.7.0-dp1 source)

There is iOS version(s) of the standalone engine, which are for running on ARM based Apple CPUs.
I don't know how much more difficult it would be to port the Mac IDE version of the engine to ARM.
Any code using CoreGraphics or various other Apple (C/Objective C) frameworks shouldn't need to be changed much, if at all. But I don't think they used ARC (Automatic Reference Counting) and so I imagine there may be hairy manual memory management stuff to deal with.

Apple offered support for developers to help port software to M-series when the transition was announced, not sure if they still do or if they charge a lot of coinage for the help.

[OpenXTalkPaul]

If I ever get me an M-series Mac I think the first thing I'll do is install Xcode and see if I can compile StackSmith to M-cpu native. I had no problem at all compiling that xTalk engine/IDE from source. Sure it needs bunch of work, it needs to use a portable cross-platform UI toolkit (GNUStep, Qt, Gtk or something) but the point is StackSmith & Hammer-Script may actually be a more easily workable option on Mac desktop.

[OpenXTalkPaul]

Has anyone tried to use 'prepare image' syntax as a possible work around to 'image corruption' problem with Sonoma-binary-patched engine? I'm still using the patched engine, and I've used 'prepare image' to fix what appeared to be image-display corruption with certain compressed images and for copying imageData from 'compiled SVG' Images.
Even if that doesn't work-around the problem, could we add Sonoma-patched binary as standalone deploy option for people like me who have stacks without any image displaying problems?

[tperry2x]

my previous post has been deleted (?) so I assume I'm not working on additional options for the standalone builder.

[richmond62]

my previous post has been deleted

By whom?

[richmond62]

Oh, and re Sonoma, Sequoia, and (presumably) 'Metasequoia'; as I am a selfish so-and-so and with THE PATCH have no probz whatsoever re standalones of my Devawriter Pro (because it has only what I'd like to term "instack menus"), I'd second this:

could we add Sonoma-patched binary as standalone deploy option for people like me who have stacks without any image displaying problems?

[OpenXTalkPaul]

my previous post has been deleted (?) so I assume I'm not working on additional options for the standalone builder.

That's strange, I don't think it was me, if it was it was an accident.
I posted something this afternoon and had to post again because it disappeared.

[tperry2x]

The more I look into this, the more confusing for users I think it will be.
I was going to have two x64 mac standalone apps in the runtime folder inside the IDE (one pre-patched) at one point, but this also adds another 30+ MB to the size of OXT Lite.

What I think I might do instead, is leave the two checkboxes as they are currently for Mac options, but have a third which just allows you to build for Sonoma+. When that's chosen, the build of the mac standalone runs through normally, but then also patches the standalone using the terminal/shell commands at the end. That might be the better approach.