OpenXTalk Forums

I've been looking into extending some capabilities on via Extension Builder, doing various tests with GTK,GDK,GIO, etc. and I've come to realize that a big problem facing the task of maintaining some sort of in-IDE web-browser-engine interaction as far as using WebKit2GTK is that the Linux engine is using or linked against GTK2, which is rather old now and not really maintained, and the default builds of WebKit2GTK you'd currently find in a Linux package manager like Synaptic are going to be built against GTK3 and/or GTK4 (someday soon to be GTK5). So it's much the same sort of problem of 'bit-rot' that the engines for macOS/Win desktop platforms face, where they're built for versions of the OS that are becoming past their expiration date and the cracks are starting to show through the layers of spackling over. I don't think there's anything that can be done about bit-rot. Technology marches on endlessly, and with computers that tends to breaks the functionality of older things eventually. Even if we think certain aspects of today's tech really seem like de-evolvution (the "Infomation Super-Highway" becomes the DIS-Infotmation Super-Highway" for example).

My realization of this really being the case for our Linux engine is because, while I can use GTK2 libraries just fine from xBuilder, if I change the dynamic bindings to link against GTK3 the engine crashes. After some Googling around I've come to the conclusion that you cannot mix GTK2 with GTK3 in any language, it will give you a compiler error if you do it in straight C. All the desktop engines are all outdated (and they were when we got them dumped to us) and need to be updated and recompiled, built against current system APIs. Unfortunately that likely means excluding some older systems. I'd like maintain support as far back as possible, but that's the reality of it.

So currently the options that come to mind for 'modernizing' web-interactivity capabilities for the Linux engine, preferably with Webkit, are these:
1) Try to update the engine source so that any GTK2 things point to GTK3 or 4 and recompile. I think that would be enough to allow Webkit2GTK (again, works with GTK3)
2) Try to Compile and include a version of Webkit built against GTK2 (yielding the library libwebkit-x11-1.0.so) which apparently is possible but perhaps not entirely stable. I thought it may be possible to use WPE (Webkit embeded) but apparently a GTK2 'back-end' for WPE does not exist
3) Try to update Chromium Embedded Framework to modern version (I believe that now uses 'Blink' version of Webkit), Chromium FOSS support was dropped by Google, but there are still some large companies that depend on it. Spotify currently hosts nightly builds of CEF.
4) Try binding to a different / mixing in a non-GTK UI framework. I'm specifically thinking about the quite popular Qt5 framework, which has it's own wrapper around Webkit2, but so too does WxWidgets (or whatever it's called now) and I'm sure some others (Free Pascal's 'LCL') might work without updating the Engine source. Qt5 is just the most popular of the GTK alternatives.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm ...the Linux engine is using or linked against GTK2, which is rather old now and not really maintained...

It is really old now, and I suppose it will disappear from being something that's included altogether one day.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm I don't think there's anything that can be done about bit-rot. Technology marches on endlessly, and with computers that tends to breaks the functionality of older things eventually...

Apart from ease of installation, I think perhaps this is why appimages / flatpack is a good idea. At least you can include things in case they disappear, but ultimately - you are 100% right - this all needs updating, that's the better fix.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm ...while I can use GTK2 libraries just fine...you cannot mix GTK2 with GTK3 in any language...

That makes perfect sense too, unfortunately.
You'd think it could have an if else to say, if GTK3/4 or 5 available, render using that - otherwise render using GTK2 (but that's hugely complicated to adjust on-the-fly as it affects things throughout the engine. So perhaps not.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm All the desktop engines are all outdated (and they were when we got them dumped to us) and need to be updated and recompiled...

Someone asked me already, are our engines 'stale' - "have we inherited a poisoned chalice". While I'd definitely say that's the case with the mac engine, I think it's just a case of bit-rot for Linux. What of Windows in that case. I think it still uses a smattering of dotnet 3.5, which is also old now.
I hope someone will absolutely prove me wrong on this, but I have my doubts if the Mac version can be compiled. That's the worst kind of bit-rot. This is because you can't open the various versions of xCode any longer to get them to initialise and register themselves with the rest of the dev environment on MacOS. I think that might be the end of the road for the engine on MacOS, unless of course - we default back to compiling on legacy hardware or a legacy VM version of MacOS.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm ...Try to update the engine source so that any GTK2 things point to GTK3 or 4 and recompile. I think that would be enough to allow Webkit2GTK (again, works with GTK3)...

In my opinion, I think that's the better approach. But not the most easy.
I certainly don't know enough about GTK source to start that yet.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm 2) Try to Compile and include a version of Webkit built against GTK2 (yielding the library libwebkit-x11-1.0.so)

The thing that puts me off about that is GTK2 will disappear sooner, and x11 too, which I know we are trying to move away from.

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm 3) Try to update Chromium Embedded Framework to modern version...Spotify currently hosts nightly builds of CEF.

Until they don't anymore, then we are a bit stuck again. Also, the sheer size of CEF is staggering and feels a bit like bloatware. (only my opinion)

OpenXTalkPaul wrote: ↑Sat Jan 25, 2025 7:32 pm 4) Try binding to a different / mixing in a non-GTK UI framework. I'm specifically thinking about the quite popular Qt5 framework, which has it's own wrapper around Webkit2, but so too does WxWidgets (or whatever it's called now) and I'm sure some others (Free Pascal's 'LCL') might work without updating the Engine source. Qt5 is just the most popular of the GTK alternatives.

Of course they are all possibles, but just depends on what is going to be easiest to support and balanced up with how long do we think each will stick around and remain current for?

Either way, the root of the issue is that the engine itself needs rewriting to not be such a pig to compile for - and to accept these changes. At the moment, I feel like changing too much is likely to bring the whole house of cards down.

But you are right - the engine needs modernising extensively. At the cost of our sanity perhaps.

But it also needs modernising with ease of updating in mind, so I know what you are thinking - webify it in a container, but then we have a whole lot of new problems there where we absolutely have to re-write everything. (Yes, we could use openxion etc, but the differences are just so vast in the syntax and what it supports compared to what our inherited engine can currently do, it may as well be a case of having to start afresh whatever route we went). That's a whole dedicated development team's work for the next 5+ years, easily. If I won the lottery, I still don't think that would cover it.

Ultimately it feels like all of the IDE changes (painting over the cracks is a good analogy), are just that. Painting the wall is pointless when the foundations are crumbling.

There are many serious issues, and they are only going to become more apparent as time passes. As you say, it is inevitable.
Perhaps we hold out hope that ChatGPT12 one day is smart enough to write us an engine in it's entirety, but as I've said before, who's going to sit and script/code anything at that point when they can probably just describe what they want the program to do and the computer just makes it happen.

In no particular order; that makes LC Create, OXT, Xcode, Visual Studio, Python (etc) completely irrelevant at that stage. There would effectively be no need for 'coders' / programmers at all.

My worry is that all the work we've both done is ultimately going to amount to nothing in the long term, except for some legacy application that someone will either have to run in a VM or boot into a custom distro which contains legacy libraries.

I know I've posted this image before, but it tells a story. How do we prevent it happening without a skilled set of C++ coders who can go in and fix everything?. Not just once, but continuously - and for what reward? Lots of thanks, but we have no cash to offer them.

My worry is that all the work we've both done is ultimately going to amount to nothing in the long term

Haven't you read Ecclesiastes or any philosopher actually! We all die in the end, sooner or later and our work and even the memory of us as a person will soon fade. There is no scoreboard and you can't win because there is no game. So do what you need to do to make yourself, the people around you and your little corner of the world better because that is all that you can count on.

Noob question from someone who does not know the intricacies of which I talk:

Is there the possibility of actually compiling a Mac engine just using current components? It would leave legacy Mac's behind and be different from the Windows and Linux engines, but it would be a Mac base that you could then build out from. For those with older machines, they could install a VM and use the Linux engine to do what they need to do in the environment that they are used to. Modern Mac users will not notice or miss the support for older Mac systems anyway. Yes, the Mac engine would be different from the other two. Yes, certain people would be excluded. But... as long as the user's stacks can work interchangeably on all three engines - well the Mac was always the odd man out anyway.

With a modern base that actually compiles consistently, you could then actually look forward to biting the real bullet and moving to ARM chip support which is the only thing that is really going to matter long term on the Mac side.

Just my thoughts on strategy from someone who can't really help the two of you who are doing the work.

Kelly

Kdjanz wrote: ↑Sun Jan 26, 2025 1:07 am Noob question from someone who does not know the intricacies of which I talk:

That makes two of us

Kdjanz wrote: ↑Sun Jan 26, 2025 1:07 am Is there the possibility of actually compiling a Mac engine just using current components?

Unfortnately this is what I'm currently trying, and it's where I think I'm going wrong. The issue is it won't build using current components, due to the source project being so far out of date.

Kdjanz wrote: ↑Sun Jan 26, 2025 1:07 am For those with older machines, they could install a VM and use the Linux engine to do what they need to do in the environment that they are used to.

It's probably a case of it'll compile somehow using older hardware. The engine seems to be geared towards much earlier releases of MacOS.

Kdjanz wrote: ↑Sun Jan 26, 2025 1:07 am ...as long as the user's stacks can work interchangeably on all three engines - well the Mac was always the odd man out anyway.

As the Windows engine is the least broken currently, I'm actually contemplating bundling OpenXTalk Lite in a wineskin wrapper, which means it'll work for 10.8 - all the way to MacOS 10.15... (Which on Big Sur, is when the engine noticably started to show it's age anyway).

Kdjanz wrote: ↑Sun Jan 26, 2025 1:07 am With a modern base that actually compiles consistently, you could then actually look forward to biting the real bullet and moving to ARM chip support which is the only thing that is really going to matter long term on the Mac side.

That would be wonderful, but there's so much requirement to older versions of xCode on the mac build.
Why does the xCodeproject require functioning versions of older xCode apps? The issue you run into there, is you can't run older versions of xCode anymore on all versions of MacOS. I have a nasty feeling, the only way around that is to start with a MacOS 10.10.5 install, run xCode 7.2.1 and download all the bits it needs, upgrade the OS in place to MacOS 10.11.5 - download xCode 8.2, run xCode 8.2 and download all the bits it needs. Then upgrade the OS to MacOS 10.12 - download xCode 8.3 and install that. Run xCode 8.3 and download all the bits that needs. Then, although it's not mentioned, I think xCode 11.3.1 is possibly the right version (it's a guess!!) - so download each MacOS update and install until we get to MacOS 10.14.4, where we can download xCode 11.3.1 - run that, let it download all it's chaff - then see if that compiles.

What a process!!

But no guarantees that would even work.
And the hardware to support that is going to take a bit of research, not impossible though.

Or, just run it in a wine wrapper. I know what I prefer at the moment
Would just need to get Wine to make functioning standalones, which I'm close to sorting.

tperry2x wrote: ↑Sat Jan 25, 2025 10:28 pm Perhaps we hold out hope that ChatGPT12 one day is smart enough to write us an engine in it's entirety, but as I've said before, who's going to sit and script/code anything at that point when they can probably just describe what they want the program to do and the computer just makes it happen.

In no particular order; that makes LC Create, OXT, Xcode, Visual Studio, Python (etc) completely irrelevant at that stage. There would effectively be no need for 'coders' / programmers at all.

Yes then 'coding' will become more like a genre or sphere of sort-of performance art or craftsmanship, like orchestra orchestration but with APIs. As someone who makes no money from coding, I'm kind of good with that. In fact I've kind of been hoping for that for a long time, but I also recognize that we'd better move into being some sort of 'Star Trek' egalitarian utopian society before then
"Siri, create an interface of on screen guitar with six on screen animated virtual guitar strings above a fret board, the strings will be in a standard tuning with the low E at octave 3 and with a two octave range of frets, and then allowing the user to strum the on screen strings with mouse or touchscreen, which then emits MIDI 2.0 expression data."
Let's see how attractive of a UI that AI would generate, better have darkMode

Moving towards an xTalk riding on top of a HTML5 Web Engine, wrapping as much of HTML5 as possible in an xTalk interpreter layer, that makes most sense to me for the limited resources available to us, and the most sense in regards to the sand boxed world today's computing unfortunately is. There's a lot of real advantages if it can be made to happen. When xTalk its already running in a browser environment, there's no fussing with 'Browser Widgets", you can just put another page into another canvas, using an 'iframe' and you can run a separate instance of 'the engine' (as demonstrated by HH experiments). Wrapping JS based APIs in an xTalk handler 'wrapper' can be quite simple as Dan Gelder's HC sim example proves. Being able to tap the vast JS echo-system of libraries and APIs and do hyperglot programming is a very nice feature.

I do agree, I mean - ultimately - being in the web removes a few hurdles.
But it also creates a few of it's own.

Edit: I did have a large long-winded post here about me trying to get started in OpenXTalk playgrounds and edit something, but ultimately - I just can't make any headway with it.

Ultimately I don’t really care about the engine. As long as it runs my legacy stacks and gives the same results as I got before then I’m a happy camper. I don’t care what language is behind the curtain as long as it looks the same outside. So if someone has a working engine (or even one that is 75-80% there) in some other language, then do the engine swap and get back on the road. Python or JS or whatever, does not matter to the punter who only writes xtalk. The important thing is that you folks who actually maintain the engine have something that you can work with and that will keep working over the next 20 - 30 years - if anyone is still xtalking then when that engine needs to be overhauled.

Kdjanz wrote: ↑Sun Jan 26, 2025 8:03 pm Ultimately I don’t really care about the engine. As long as it runs my legacy stacks and gives the same results as I got before then I’m a happy camper ... The important thing is that you folks who actually maintain the engine have something that you can work with...

These are very good points.
I don't really care how we do it, and I can't get away from one inescapable fact: there's nothing out there that exists, which is open source, and is as capable as the engine that we currently have.

• I can currently modify the source and compile the windows engine as I see fit.

• The windows engine is less broken than the others.

• The windows engine can be made to run on MacOS via wine (until they axe brew/homebrew)

• Because UTM exists, this gives Mac users on ARM processors a way to continue to run OXT. UTM is also codesigned and fully 'notarized' - meaning they've done all the Apple battle for us.

• The windows engine runs fine on Linux via an appimage or via wine installed via a package manager.

• Of course, this will run natively in Windows

• Given how Windows keeps compatibility going for programs, I think this will remain going long past MacOS has locked everyone into an iOS methodology on the desktop, and the Linux version fails to open due to GTK2 being unavailable.

• This solves our window focus errors in Linux, and it solves our video playback errors in Linux

• This also solves our weird menubar issues on MacOS (renaming menuitems and crashing).

(have done a few tweaks to a wine version of OXT Lite 1.10 this evening). Aside from the font (think I need "Segoe UI") - it now works, so I see this as a viable method of continuing to provide updated engines to all 3 platforms.

Granted, it doesn't solve making standalones for MacOS - but then, what else is there that makes standalones in xTalk currently? (it does produce working Linux standalones - until GTK2 goes of course). Needless to say it produces x32/x64 bit Windows standalones just fine.
I'm not worried about making MacOS standalones, as Apple have made that decision easy for me - they won't allow things to run which are created by small ad-hoc developers, so the Mac standalone tab can be disabled - or at least modified to mention it'll only build for OSX 10.9 through to MacOS 13.

It's just a Plan-B, that's all - but it's the best I can come up with in light of the circumstances. It's about time I faced the truth that keeping a Mac engine going is an uphill battle against Apple, and I'm not going to win.

Oh. The direction this thread is going is exactly what I was dreading.

So my hope that OXT would be my savior may come to nought.

Ah well perhaps it will remain a toy to while away a few hours in my declining years.

neville wrote: ↑Mon Jan 27, 2025 1:23 am Oh. The direction this thread is going is exactly what I was dreading.

I'm sorry to hear that, but I'm not sure what long term alternative we have for Mac users.

That idea would essentially give us a method of running it on all 3 platforms. I would alternatively go for a browser-based solution: Except nothing viable exists that is free-to-use, with comparable functions.

So what other way is there to run the IDE? Booting into a live USB/CD? (a live linux session)
That would also work, until GTK2 is pulled and one day we can't get it to run.

Then we are left with MacOS where everything is totally sandboxed, and Windows being the only platform that will run it.

I mean, this is the entire point of this thread - to discuss the long term future. We not only see examples throughout the dictionary of "Bit-Rot", where functions and commands no longer work as advertised. We are also going to see it with the entire IDE.

It's just my attempt at keeping something running. I'll fight with Sonoma, Sequoia, (Metasequoia, Redwood, Pine, MDF, Cardboard, ... whatever the MacOS is called) until I can't any longer. But it's useful to think about the long term future.

Kdjanz wrote: ↑Sun Jan 26, 2025 8:03 pm ...So if someone has a working engine (or even one that is 75-80% there) in some other language, then do the engine swap and get back on the road. Python or JS or whatever, does not matter to the punter who only writes xtalk...

I think we've listed every alternative xTalk-ish thing that exists. I keep coming back to the fact that they are either:

• Not free

• Don't work across all 3 main platforms

• Don't even offer 10% of the same feature set that we are accustomed to

• Are either incomplete (at best), or plain just don't work, and not showing any sign of future development

The wine wrapper, or running via wine - is just a way to run it, same as you would an electron wrapper in a webapp running on your desktop.

LC might be abandoning what they call "classic" in 2027, but I think MacOS will put the brakes on it before then anyway.

About the Mac...

What if the developer fee was payed. Then the app could be signed as I understand it. (and that is not much)

Mic

micmac wrote: ↑Mon Jan 27, 2025 9:42 am About the Mac...
What if the developer fee was payed. Then the app could be signed as I understand it. (and that is not much)

If the developer fee was paid (yearly), we end up with a valid developer certificate.
That gets us around the codesigning issue (possibly notarized with Apple too), so:

• stops the "Application is from an unknown developer"

• stops the "Application damaged" warnings.

However:

• It doesn't get us any further forward with compiling the engine successfully though. (The MacOS engine would essentially be frozen-in-time as it is, until the generated xcodeproject is fixed)

• It also doesn't fix the broken menus in Sonoma properly for standalones (or rather, at the expense of unpredictable/eratic image object rendering) - meaning you have to preload all images

• It doesn't give us a version that runs on ARM (not that running on Wine does either, but it merely sidesteps some of these issues).

Just to play devil's advocate . . .

There seem to be 2 concerns that are getting entangled:

1. The urge to get OXT running on more platforms than it does at the moment.

2. The urge to 'improve'/'upgrade' OXT.

#2 became such an obsession with the people "over the road" that they totally neglected their bug-reporting thing that was chock full of bug reports (and some of those bugs were quite serious).

At one point the people "over the road" obviously realised that they had neglected things for so long that the only way out of the situation without a lot of retrenchment, a lot of hard, tedious work, admissions of some long-term failings, and so on, was to dump the whole thing in favour of 'CREATE'.

The ONLY problem about 'CREATE' is, while that may be a clever idea, the people "over the road" have not learnt that endless, unrealised, or late, promises largely only result in something negative.

The OTHER funny thing about 'CREATE' is that, at present, it relies to a very large extent to deliver about 75% of those features on the thing they are supposedly dumping.

*Personally I view #2 as something that can be put on hold almost completely at the moment while time and effort is devoted to #1.

#1.1 A MacOS ARM engine and/or something based on HTML (i.e. something that CAN be downloaded and kept on a non-internet connected Mac).

#1.2 Ubuntu (and derivatives: Xubuntu, Kubuntu) usable versions: MX Linux is "all very sexy", but it ain't mainstream in the Linux world.

#1.3 The ability to spin-off standalones for ALL the platforms the IDE runs on from all platforms (c.f. spinning off a Mac-standalone from other platforms at the moment).

As has been pointed out; the current engines we have are BETTER than any obvious alternatives: so describing them as 'Crap' doesn't really help anyone (especially anyone poking around hereabouts to start using the thing), and I would suggest that the discussions that ARE going on, and are PROBABLY necessary, should be toned down and less trenchant.

I would also suggest that not too much blood, sweat, and tears be wasted for an "all things to all men" goal when most of the people "out there" are not using any form of xTalk, let alone heard about it.

OXT/LC is extremely good in quite a few niche areas, used by people in those niche fields: and it might just be those people who need to be targetted . . .

Where the "flying fadoomers" are all the people who were using LCC who vanished overnight when KM made his extremely tactless video?

Unless they were all really as fickle as fickle does, they are sitting around watching what is going on over here . . .

Let's start a list at what OXT is good at, and good for, and NOT a list of where it falls short of some illusory 'perfection'.

------

I am NOT a "computer whizz", but I am someone who uses OXT/LC on an almost daily basis for somethings that the IDE is best for: and
the people "over the road", apart from KM's huge lack of empathy (and one can track his adventures with therapy as it is all over the internet), main 'sin' is that they really did not give a damn about anyone except for about 10-20 "up the top" developers, who, while being undoubtedly very clever at using LC for "real programming" (whatever that is supposed to be), cannot be considered in any way a significant 'installed base'.

Unlike most of those niche users I am like the dog that gets its teeth in your bottom and won't let go: consider me as the 'other' type of end-user who will NOT go way.

think MacOS will put the brakes on it before then anyway.

No: MacOS won't put 'the brakes' on anything, and they should not be blamed.

What MacOS WILL do is go the way it is already going but more so for 3 fairly obvious reasons:

1. Apple computers are fast becoming machines NOT for programming.

2. Apple products are fast becoming things that do NOT resemble what I consider 'computers' any more in much the same way as HyperStudio 5 has lost what I believe are 75% of the strengths that HyperStudio 4.5 had.

3. An Apple product is something you have in the same way as you have a dwarf dog jammed under your oxter, a Louis Vuitton handbag on the other shoulder, and a Paris Hilton knock-off behind the wheel of your second four-wheel drive. Oh, and an iMac is just the sort of thing to hang your gold toilet chain on when you go to your round bed at night with your 3 catamites.

On that note, I'm just popping out for my 'Noctoplasty' session (big in Bulgaria): I really think that those 2 inch extensions in silver with Apple logos in black Swarovski crystals will be just the thing to go with the tattoo of Tim Cook on my left buttock.

That last statement should be taken with a bucket of pate-de-foie-gras soaked vomit.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am There seem to be 2 concerns that are getting entangled:
1. The urge to get OXT running on more platforms than it does at the moment.

Not really, that's not the reason I advocate running it on Wine. It's rather to keep a method of running it when GTK2 is dropped from Linux, and possibly when Apple decide that non-app-store apps are forbidden (although this might affect wine too).

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am 2. The urge to 'improve'/'upgrade' OXT.

Some things need fixing in the engine. They can't be externalised into script, due to the design of the engine.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am #2 became such an obsession with the people "over the road" that they totally neglected their bug-reporting thing that was chock full of bug reports (and some of those bugs were quite serious).

Most of those things (having downloaded all their bug report section), were bugs that needed to be sorted out in the engine.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am At one point the people "over the road" obviously realised that they had neglected things for so long that the only way out of the situation without a lot of retrenchment, a lot of hard, tedious work, admissions of some long-term failings, and so on, was to dump the whole thing in favour of 'CREATE'.

Or, possibly they've realised that carrying on trying to maintain three separate codebases (MacOS, Windows, Linux) is too much work. To have something in-browser also sidesteps Apple's continued BS and web apps are the way everything is pointing.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am The ONLY problem about 'CREATE' is, while that may be a clever idea, the people "over the road" have not learnt that endless, unrealised, or late, promises largely only results in something negative.

Yes, promising something - and not delivering it, ultimately just hurts everyone who might have made their own set of assurances based on what they THOUGHT they could deliver. If the company making the IDE lets you down, as a developer you have to let your end users down. Neither makes for good-feeling between all involved, and makes everyone look amateurish at best.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am The OTHER funny thing about 'CREATE' is that, at present, it relies to a very large extent to deliver about 75% of those features on the thing they are supposedly dumping.

Well, see above point I suppose.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am *Personally I view #2 as something that can be put on hold almost completely at the moment while time and effort is devoted to #1.

The two are linked. IF we were aiming for more platforms (which I'm not necessarily, just keeping the ones we have working), then if you were to target other platforms, there are changes that need to have to happen in-engine to make that work. The two go hand in hand.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am #1.1 A MacOS ARM engine and/or something based on HTML (i.e. something that CAN be downloaded and kept on a non-internet connected Mac).

This is also why the web-approach has it's advantages, as myself and Paul have mulled over many a time. It becomes largely platform-agnostic at that point. Although, I have found I can't get any of the "emscripten" (offline web stuff) to actually run from a local drive in a browser properly.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am #1.2 Ubuntu (and derivatives: Xubuntu, Kubuntu) usable versions: MX Linux is "all very sexy", but it ain't mainstream in the Linux world.

MX is essentially Debian underneath. Debian, well - you can't really get more mainstream than that. The various varieties / flavours of all these distros usually come down to not much more than choice of desktop session and window manager combo.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am #1.3 The ability to spin-off standalones for ALL the platforms the IDE runs on from all platforms (c.f. spinning off a Mac-standalone from other platforms at the moment).

I don't see how LC Create is going to accomplish this task either - as you can only codesign true mac standalones on a mac. The only way would be if it downloads some kind of uniform web archive with everything needed inside it to run locally in a browser. It isn't what you'd call a true Mac App at that point either.
This is also why standalones for MacOS generated on Linux or Windows (or wine) don't produce working Mac Apps, as they lack the codesigning info. (of course, you can open these on earlier versions of MacOS).

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am As has been pointed out; the current engines we have are BETTER than any obvious alternatives: so describing them as 'Crap' doesn't really help anyone (especially anyone poking around hereabouts to start using the thing), and I would suggest that the discussions that ARE going on, and are PROBABLY necessary, should be toned down and less trenchant.

I get why people are frustrated. What other discussions are going on? I'm only aware of this one - so lets have everything out in the open? I understand particularly Mac users want a Mac app or nothing, whereas Linux users are used to having to run wine for certain programs. No changes needed for Windows users.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am I would also suggest that not too much blood, sweat, and tears be wasted for an "all things to all men" goal when most of the people "out there" are not using any form of xTalk, let alone heard about it.

No, granted - there's probably only about a handful of people ready to throw their hat into the ring, roll up their sleeves and participate in any development - the rest are just on the sidelines observing (or just posting without any constructive alternatives or example fixes). However, it should be plain to all and sundry that the engine needs a C++ developer(s). Which we can't pay for. But then, we have said this all a year ago.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am OXT/LC is extremely good in quite a few niche areas, used by people in those niche fields: and it might just be those people who need to be targetted . . .

We are taking a niche product and making it more niche, has to be said. Perhaps that's why there's a distinct lack of anything else 'finished' or at comparable development currently.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am Where the "flying fadoomers" are all the people who were using LCC who vanished overnight when KM made his extremely tactless video?

They may have moved on to Python, Swift, or something else.

richmond62 wrote: ↑Mon Jan 27, 2025 10:05 am Unless they were all really as fickle as fickle does, they are sitting around watching what is going on over here . . .

See above. Quite possible. I don't buy the idea that we have over 2000 'bots' or 'entities'.

richmond62 wrote: ↑Mon Jan 27, 2025 10:15 am

think MacOS will put the brakes on it before then anyway.

No: MacOS won't put 'the brakes' on anything, and they should not be blamed.

Do you not think so? - Judging by past form, it really would not surprise me.

richmond62 wrote: ↑Mon Jan 27, 2025 10:15 am What MacOS WILL do is go the way it is already going but more so for 3 fairly obvious reasons:

1. Apple computers are fast becoming machines NOT for programming.

2. Apple products are fast becoming things that do NOT resemble what I consider 'computers' any more in much the same way as HyperStudio 5 has lost what I believe are 75% of the strengths that HyperStudio 4.5 had.

3. An Apple product is something you have in the same way as you have a dwarf dog jammed under your oxter, a Louis Vuitton handbag on the other shoulder, and a Paris Hilton knock-off behind the wheel of your second four-wheel drive. Oh, and an iMac is just the sort of thing to hang your gold toilet chain on when you go to your round bed at night with your 3 catamites.

So if that is the case, why are we even worrying about supporting Mac users?
From my point of view, it's to give the largest possible audience and availability of the language to users. That is what a browser based version would do. But that doesn't exist for OXT. That's why I think LC have gone the route they've gone with Create. I can't fault their logic on that one, however much I don't agree with the methodology.