OXT Lite Moving Forward

[richmond62]

Halfway there, as the "bile salts" green is pretty foul:
-

SShot 2023-11-21 at 14.41.54.png (17.2 KiB) Viewed 3169 times

-
Not at all clear where the 'sewage' is coming from.

[tperry2x]

Not 100% sure, depends on where you are up to with the patching, but you should find some more options for syntax colours in the preferences:

Screenshot at 2023-11-21 12-44-28.png (37.34 KiB) Viewed 3164 times

No, not the nicest hilight colour in the world. Is this from your system preferences?
So yes, I've just changed it.

Instead of using:

Code: Select all

put the platform && tSystemVersionNumber

to get:

Code: Select all

MacOS 14.2

You can now just use:

Code: Select all

put tSystemVersion

to get the same result. If that makes sense.

[richmond62]

That's really very useful indeed.

[micmac]

Here is what I have with 0.9.3

(its a opencore patched Montery)

Skærmbillede 2023-11-21 kl. 11.35.27.png (35.15 KiB) Viewed 3155 times

Mic

[tperry2x]

Hi Mic,
Do you have all the recent patches, as I've only just added this.
To check, please run this in the message box:

Code: Select all

edit the script of stack "home"

Starting on line 1539, you should have:

Screenshot at 2023-11-21 14-59-53.png (37.34 KiB) Viewed 3153 times

[micmac]

No tperry, but the build was downloaded after you mention it

So I suppose it will come to the build soon

Mic

[tperry2x]

I aim to release 0.94 soon, so that should clear up any confusion. Many thanks.
edit:
https://www.openxtalk.org/forum/viewtop ... 4646#p4646

[foxtrot47]

LC are shouting about how 9.6.11 can export for iOS 17.
Perhaps we should confine ourselves to a desktop IDE.

As much as I hate to admit it, most kids don't tend to think laptop and desktop first. They have iOS / Android devices in mind as soon as you mention a 'computer'.

I agree, kids are using what is given to them, and we can certainly expect them to favour those/similar devices in the future. However, I'd argue the question is worth exploring, especially in the context of the OpenXTalk Manifesto:

xTalk has always been about a user-centric, easy to understand, "natural language" English-like syntax, and as instant gratification as possible, "live reload" (constant just-in-time recompiling of bits of code) editing with a GUI toolkit that has most elements people would need to build any sort of "app" like collection of data and/or data-processing.

As I see it, Windows and Linux are the only two "modern" platforms that OpenXTalk could build for while still adhering to the principles associated with xTalk. Until a new engine is compiled, Mac Intel, Android, and iOS could largely be considered EOL/deprecated. Apple's offerings are also expensive, and not typically what I see in the majority of backpacks at my local community college.

By focusing efforts on the two platforms with the widest user reach (combined), as I see it, OpenXTalk would be in a better position to deliver on it's goals. The savings in technical debt associated with development, documentation, QA, community feedback, etc., would be considerable.

Plus, if a developer needs Android, iOS, or Mac apps, you can point them to LiveCode. OXT retains compatibility and interoperability, while the developer saves considerably on the cost of their annual LiveCode license. Depending on your perspective, that could be a win for both sides, or a great way to get LiveCode's attention.

The hope would be, over the next year or two, a skilful newcomer will bring future engines to life, thus expanding OXT's reach much further.

[richmond62]

the principles associated with xTalk

1. First of all it would be nice to know exactly what "the principles associated with xTalk" are.

2. I started fooling around with HyperCard 2.0 in 1993 on an LC 475 running macOS 7.1: surely that is where "the principles associated with xTalk" started.

Having, for my sins, had to compose EFL software using ToolBook 5 for Windows 2000 in, wait for it, 2001, I am well aware that that was NOT following "the principles associated with xTalk", and am thankful I will never have to repeat that experience again (and never have to have it 'approved' of by some incredibly ignorant person who only enjoys his seniority to me because his gradfather was a totally uneducated Bedu who happened to have crude oil in his back-garden and thought he knew all about Islam, but hadn't, unlike me, waded all the way through the Hadith and Fiqr, but, because although I HAD studied Islam in depth (at Uni')) I wasn't a Muslim, was able to ride roughshod over anything I might have to say).

3. Like it or not [and I am not particularly interested in those childish Mac versus Windows flame wars] Mac IS a major development platform, and how it might deviate from "the principles associated with xTalk" escapes me entirely.

4. Frankly "the principles associated with xTalk" looks like a throwaway tag like silly words such as 'modern' (which, when you analyse it means nothing); so it might behoove you to explain exactly what you mean when you state that MacOS and "the principles associated with xTalk" don't, somehow, coincide.

5. As to Linux:

5.1. I love Linux: my whole "hole-in-the-wall" EFL schoolette (have NO illusions as to its scale ~50 kids a year for the last 20 years) depends on and runs on Linux (Xubuntu): but in terms of 'WOT' the average Joe who might be our target uses: fergettit largely.

5.2. My laptops 'do' Linux (why waste your money on a hugely expensive Mac laptop when anyone with half a brain can have a machine doing much the same sort of thing with a Linux distro for about 10-20% of the price?), and my major achievement 'Devawriter Pro' [strictly for nutcases who dig Sanskrit] has spent about half its 14 year life being developed over 'there' in the Linux Vaikuntha Lokas.

To abandon any of these 3 platforms would be a serious backward step.

[tperry2x]

To abandon any of these 3 platforms would be a serious backward step.

This is absolutely why we need to think Macs and ARM, but I'm beating the same drum repeatedly here, and it's nothing that's not been said before.
If in the near future, Apple drop Rosetta 2 - and you know they will, just like Rosetta 1 went byebye, at which point the only new mac consumers can buy from apple will have an Arm chipset.
Then we can say that without an ARM engine, we are stymied, and have no mac support.
As much as I love macs (or rather, that should be in the past tense), what Apple has done in Big Sur and upwards is moving more towards an iOS interface on the desktop. Coupled with all the codesigning BS, gatekeeper and the like - it's more locked down and restrictive than ever from a developer's point of view.

Mac OS is currently a headache compared to Windows and Linux. The latter two behave beautifully compared to the Mac. This is why I have to put special install instructions in the DMG and workarounds that people can 'try', which just aren't needed for anything else. Doesn't look good when a bit of software asks you to tamper with your OS security settings just to get it to open. In my view, OXT support in mac os is already depreciated.

I'll continue supporting it as long as I can with OXT Lite releases, but increasingly, it feels like it's fighting me at every step of the way. Something I never thought I'd say about MacOS. It never used to feel that way using it. The Finder is now a sluggish memory hog too compared to what it once was. Bear in mind that it used to be about efficiency, but now even a Mac mini i5 2007 falls beneath the bar for Sonoma. (The graphics card just cannae take it captain!)

[richmond62]

Apple may be painting themselves into a corner with Paris Hilton and her ilk who have Macs the same way as they have Louis Vuitton handbags.

[tperry2x]

Speaking of which, you just reminded me.
Did you ever track down what was causing that 'sewage' highlight colour?

[richmond62]

I honestly couldn't say; here at home (iMac with MacOS 12.7) the Darkmode selection is awful:
-

Screenshot 2023-11-23 at 21.36.33.png (157.19 KiB) Viewed 3071 times

-
And by way of comparison:
-

Screenshot 2023-11-23 at 21.39.47.png (144.77 KiB) Viewed 3070 times

[tperry2x]

That top screenshot... You are still on 0.93 by the look of it.

[richmond62]

That top screenshot... You are still on 0.93 by the look of it.

Actually I'm on about 3 glasses of white wine.

Indeed: but, pardon my goofiness, but does this: https://www.tsites.co.uk/sites/openxtalk/changes.php

yield 0.94 for Mac?

Strike that: just unzipping it . . .
-

-
I know, I know, my mind is like a sewer: full of flotsam from the past.

[tperry2x]

It does indeed and has since about 9am this morning. (I don't have space to keep multiple versions online. So each release overwrites the previous one).

[richmond62]

Right-O, here we go . . . . . . . .
-

Screenshot 2023-11-23 at 21.56.38.png (55.57 KiB) Viewed 3063 times

-
AGAIN!

[foxtrot47]

1. First of all it would be nice to know exactly what "the principles associated with xTalk" are.

A fair point and I'm happy you brought up!

As a relative newcomer, I must admit that I made the mistake of associating the pinned Manifesto as "the" manifesto of OXT. My apologies, I was overcome with exuberance after seeing so many old bugs fixed. Plus, OXT pretty much solves my "how do you even FOSS this?" problem with a project.

I'll refer to these as "Paul's suggestions" from now on, so as not to continue the idea that clearly defined principles have been established:

• User-centric design
• Easy to understand, "natural language" English-like syntax
• Instant gratification as possible, "live reload"
• Constant just-in-time recompiling of bits of code
• Editing with a GUI toolkit that has most elements for building apps
• Suitable for data collection and/or data-processing applications

2. I started fooling around with HyperCard 2.0 in 1993 on an LC 475 running macOS 7.1: surely that is where "the principles associated with xTalk" started.

Absolutely! I don't know of anyone who would argue against that point. For me, Paul's suggestions embodied most of what I considered "the principles associated with xTalk". Since these principles are very much in-flux, I'll take some time to think of a more succinct answer to the question posed.

4. Frankly "the principles associated with xTalk" looks like a throwaway tag like silly words such as 'modern' (which, when you analyse it means nothing); so it might behoove you to explain exactly what you mean when you state that MacOS and "the principles associated with xTalk" don't, somehow, coincide.

My apologies, I should have stated my understanding of the current status of the Apple silicon engine. At the time of posting, I was under the impression that OXT did not yet have one, and was dependent on compatibility layer(s) when running on Apple silicon.

I also failed to explain that, predicated on my idea that OXT did not yet have an Apple silicon engine, the MacOS version of the IDE could see a similar fate as that of Hypercard stacks and standalones running in MacOS X. My own shareware accumulated reviews complaining of an outdated interface, long loading times, and excessive resource usage. Heck, one person even spotted the HyperCard underpinnings and told me to, "learn a real programming language".

I finally bought (read: could afford) an iBook to address complaints just after 10.2 Jaguar was released. My experience running HyperCard in Classic Mode in 2003 was reminiscent of the complaints levied at the current Mac OS engine:

"...coupled with all the codesigning BS, gatekeeper and the like - it's more locked down and restrictive than ever from a developer's point of view."

"Mac OS is currently a headache compared to Windows and Linux... I have to put special install instructions in the DMG and workarounds... just aren't needed for anything else."

"In my view, OXT support in mac os is already depreciated... it feels like it's fighting me at every step of the way... The Finder is now a sluggish memory hog too compared to what it once was."

Looking at Paul's suggestions, I would assess that the MacOS engine struggles to meet his first 4 points:

• User-centric design
• Easy to understand, "natural language" English-like syntax
• Instant gratification as possible, "live reload"
• Constant just-in-time recompiling of bits of code
• Editing with a GUI toolkit that has most elements for building apps
• Suitable for data collection and/or data-processing applications

Considering the Mac OS engine as "Supported" at this stage of OXT's development is tenuous. I'm as hopeful as everyone else that a newcomer with the necessary skills will chime in at any minute, but until that happens:

If in the near future, Apple drop Rosetta 2 - and you know they will, just like Rosetta 1 went byebye, at which point the only new mac consumers can buy from apple will have an Arm chipset.
Then we can say that without an ARM engine, we are stymied, and have no mac support.

While my mind can still be changed, I think Windows and Linux are the best path forward for "Supported" operating systems in a 1.0 release. Cursory research shows that Windows and Linux represent 70% of the worldwide desktop computer market. https://gs.statcounter.com/os-market-sh ... 202209-bar Imprecise as it is to calculate the true number, a variance of 10% still leaves room for healthy competition. Plus, Microsoft has yet to perfect Windows on ARM, so I feel confident that x86_64 will be safe for a few more years worth of hard-core, focused development.

To abandon any of these 3 platforms would be a serious backward step.

Alright, what if the following approach was taken instead:

• List Mac OS support as "Experimental"
• Development priorities (when not tackling crippling bugs): (1) Windows, (2) Linux, (3) Mac OS
• After say, 2 years, if no solution has been found, drop support for MacOS.
• If someone is able to deliver a working engine, list Mac OS Support as "Coming Soon!" and advertise that fact.

Would an approach like that be an acceptable compromise? Sort of a rough framework for considering new OXT engines, as that's bound to continue to come up.

[tperry2x]

Right-O, here we go . . . . . . . .
AGAIN!

Unfortunately, this comes as no surprise to me.

Foxtrot raises some very valid points above

what if the following approach was taken instead:

• List Mac OS support as "Experimental"
• Development priorities (when not tackling crippling bugs): (1) Windows, (2) Linux, (3) Mac OS
• After say, 2 years, if no solution has been found, drop support for MacOS.
• If someone is able to deliver a working engine, list Mac OS Support as "Coming Soon!" and advertise that fact.

It remains to be seen if Rosetta 2 will last for 2 years. Apple may announce they are pulling support earlier than that.
Rosetta 2 is not infallible either. It's good, but there's plenty of processor instructions it can't translate from the intel instruction set over to arm intel.
https://developer.apple.com/documentati ... nvironment

Besides, can I really put up of 2 years worth of "This app can't be opened and should be deleted".
0.9x versions of OpenXTalk are all experimental as far as I'm concerned. It does not deserve even contemplation of a 1.0 release until the most glaring engine bugs are worked out. I think that's where me, you (anyone) should be focusing their efforts now if you are looking for a task.
https://github.com/OpenXTalk-org/OpenXT ... 3.1/engine

[richmond62]

Well, possibly several very dirty weekends coming up.

Although, surely, the engine at the moment is still the 'unbesmirched' thing from LC 963 . . .

So, quite why it should start playing silly buggers now escapes me.