OpenXTalk Forums

richmond62 wrote: ↑Fri May 17, 2024 8:39 am Interestingly on Xubuntu:
-
PUTZ.png

You have to right-click and 'allow to open as an application'

You have to right-click and 'allow to open as an application'

Is that a fact?
- -
The executable bit HAS been set.

Well, yes - it is a fact. Okay....... good.
Is your chosen distro here able to run 32-bit programs, or is it a 64-bit only distro (with no 32-bit compatibility layer). I mention this as this is a 32-bit application:

Aaaaaah: will add 32-bit capability . . .

Xubuntu 24.04 appears to have dropped multiarch.

Running the Windows version with WINE:
- -
Notice the option to make a web-something!

Hey-Ho, Here We Go . . .
- - -
The result is presumably because LiveCode have blocked downloading the 'thingy' to run these files in a browser.

Yes, I thought they'd dropped 32-bit support a long time ago though.
I found it interesting that the paint tools work as expected.

I wonder if that web stuff code is not 'buried' somewhere in the open source versions . . . ?

I am certainly going to spend a bit of time fooling around with that web thing on one of my PPC Macs when I get home.

Building for the web with LC 963 Linux is not very satisfactory:
- -
The only 'advantage' about OXT Lite is that it didn't lead me to expect anything.
- -

Yes, we know the web targets are unfortunately very broken. (I've never found them to be at all viable for anything).

It might be a good idea to hide or remove that option from the standalone settings.

I'd been meaning to mention that to Paul about that at some point. I seem to be under the impression that Paul made progress in getting web versions of stacks to display in various ways. I wondered if we can utilise some / any / all of his techniques to built that into the web standalone targets - directly from the standalone builder in OXT?

I don't know what web output from Rev 3/4 was exactly, something called "revlet"?
Was it some sort of server-side engine? Could that revlet thing be related to GUI-less 'server' version of the FOSS engine?

At any rate, here is what we have for open source as far as running inside a web browser is concerned:

1) the server engine -- I've never really used this myself but I did go through some tutorial stuff somewhere. This very site allows for running these scripts ( which usually have the extension .lc ) so if someone wants to use that to make some interactive pages for the site we can them out there, perhaps with our own tutorials.

Also perhaps something like xTalk+Jupiter Notebooks on web could be made from the CLI? It would be great for trying some xTalk ideas while only having access to a browser. We live in an ever increasingly lock-down computer echo system now where we have to run stuff in a sandbox, that's why we need xTalk to be runable in web browsers.

2) the Emscripten version of the Engine:
This engine is basically like MetaCard ported to JS/Emscripten web asm, but to does have support widgets.
I've tested this engine a bunch.

This engine is a 30 mb .js file ( I made an un-minified (using Atom Beautify) line-break restored copy of the Engine .JS file so that it could be slightly bore human readable, that is 50mb file!). So this is quite large for a web app, but the engine should get cached by the browser engine, and thereafter the opening of additional webstacks should be much faster.
A zip that is like a virtual files system also gets loaded, this is your 'webstack'(s) it contains stacks and any other resources like fonts, for running the stack a browser engine. You can 'put the files'/folders to get list of this virtual-FS directory.
'Webstacks' can also have substacks so you can add 'palette' or menu stacks (one could add Tools, Message Box, etc.).
Ask/Answer is wired to use 'native' JS to do those dialog boxes, but I imagine including ask/answer stacks could be made to work.

Various engine syntax is sketchy or non-functional for example 'wait' commands do not seem to work, but 'send in x milliseconds' does work, so you need to make a timer script is you need timing.
The systemAppearance' doesn't work but it's easy to get that info from the browser engine. Likewise revSpeak commands don't work but it's easy enough to do TTS via web speech API.
Since the host environment is a sandbox you must use JS + HTML5 web APIs for reading and writing to local files.The end user must always allow or disallow the disc access which is a restriction of the sandbox.

Those work-arounds are possible because there is a global object created that allow for bi-directional communication between JS and xTalk.You can expose xTalk handlers to JS and JS functions can exposed to your stack

Because the Emscripten Engine runs in a browser as the platform, and therefore there is no window manager, stacks running in a browser window have no window frames. A good solution to this I think would be to make our own xTalk-library that is a stack window manager along with a supporting Window Frame Widget. The Window Frame Widget would adhere itself to a stack window, and can have the Window controller sort of buttons (close, minimize, expand, etc.) and use xtalk-script from XBuilder to send corresponding stack messages, and could can be used for palette windows. The idea of that widget is inspired by the Morphic UI used with SmallTalk(s) UI 'windows' in web browsers. Just the window frame bit.
As far as browser engine is concerned stacks are canvas layers, and using 'HTML5 Native Button' Widgets are on their own web canvas layers as well. Using xTalk <> JS we can manipulate both DOM objects in the outer webpage environment.

Quite a while back I set up a GtHub repo/Github Page to host a playground of sorts to test out / demo some of the Emscripten Engine's features.
https://openxtalk-org.github.io/OpenXTalk-Playground/

I also have on my drive here an experimental copy of the above webstack that has a couple of bits of the MetaCard UI added in, just as proof of concept. It would be great IMO to have a version of the IDE that runs inside of WebBrowsers. The biggest problem I think is the sandboxing, which is very similar to running as a Mobile App. I was looking for a way to create stack in memory (which is easy enough) in a way can then be passed to HTML5 File API for allowing user to save a stack file of their work. It's easy to allow save scripts out as text files so creating 'script-only' stacks is certainly do able, but I want it to be able to save binary UI stacks that get created. That's where I got a bit stuck and then never got around back to it.

3) HyperCard Simulator -- This 'engine' is basically an xTalk->JS transpiler, and I kind of LOVE it!
It has a section of itself that can be added to which is the SimScript, where you can wrap JS in xTalk handler structures and the call on them as you would any other xTalk handler (better still functions can be called as if they were global 'engine' properties, prefaced by 'the').

Its included xTalk implantation is based on HyperTalk and HyperCard 2.4 and its iIncluded XCMDs (such as AddColor) and it has a working 'wait' command. Also the 'SimScript' basically makes the syntax infinitely extensible in as far as you could do anything you could do with JS in a Browser. The SimScript sits at the top of the xTalk's message path, above the 'Home' stack script.

The whole thing is just made of HTML tags and JS. Even lines in a fld are implemented as <div> underneath. Because of this we can insert into these elements with any sort of web-content by using JS to manipulate the DOM objects that make up our 'stack', so for example you could implement a 'Player' control this way.
One could combine 'engine' .js with custom 'SimScript' and replace 'Home' stack HTML elements with your own stack content, to produce a 'standalone' .HTML

With either web 'engine' you could theoretically easily take that HTML+JS further by wrapping that in a small app wrapper for running on desktop platforms, potentially without sandbox restriction. I made a proof of concept Electron wrapped Emscripten Engine stack from the playground stack repo that I posted above.

Believe it or not, I'm slowly coming around to the idea that we need something running in a browser.
Yeah, I know - it took a while.
I guess I'm just set in my ways as far as wanting a conventional program that is 'installed' locally.

To that end, is it possible to have a file dump of everything that makes 'https://openxtalk-org.github.io/OpenXTalk-Playground/' tick? If this was being run locally from choosing file>open in the browser, and loading the html file to start, then this would be a lot faster. It'd be a half-way-house as a compromise. Platform agnostic, yet does not require internet access to use it.

I see what you mean about lots not being available. I wondered if it'd return the current desktop of the underlying OS, but I guess it's not aware of that being sandboxed. It's more robust than I first gave it credit for. It knows about the dateitems function for example:

tperry2x wrote: ↑Sat Jun 01, 2024 6:52 pm To that end, is it possible to have a file dump of everything that makes 'https://openxtalk-org.github.io/OpenXTalk-Playground/' tick? If this was being run locally from choosing file>open in the browser, and loading the html file to start, then this would be a lot faster. It'd be a half-way-house as a compromise. Platform agnostic, yet does not require internet access to use it.

Sure, the GitHub Repo for that Github hosted page is here:
https://github.com/OpenXTalk-org/OpenXTalk-Playground
Download the repo:
https://github.com/OpenXTalk-org/OpenXT ... s/main.zip

The resulting folder contains the original stack that the standalone webstack was deployed from.

FYI, The docs recommend compiling Emscripten Engine on Linux. There was some 'debranding' done to the Engine JS and template web page, but that was done in a code editor without doing any re-compiling process.

One thing about running this from local directory in a browser, you may have to turn on developer mode and disable its 'local file restrictions' otherwise the Engine's JS file might not load.

OpenXTalkPaul wrote: ↑Sun Jun 02, 2024 4:32 am One thing about running this from local directory in a browser, you may have to turn on developer mode and disable its 'local file restrictions' otherwise the Engine's JS file might not load.

I'm pretty sure I've got developer mode on (I'm actually running this in the developer edition of Firefox).
I don't get any errors, but I also don't get any further than this either: I hope I'm opening the right file. I couldn't see anything else that looked openable by a browser in that archive.

tperry2x wrote: ↑Sun Jun 02, 2024 7:28 am

OpenXTalkPaul wrote: ↑Sun Jun 02, 2024 4:32 am One thing about running this from local directory in a browser, you may have to turn on developer mode and disable its 'local file restrictions' otherwise the Engine's JS file might not load.

I'm pretty sure I've got developer mode on (I'm actually running this in the developer edition of Firefox).
I don't get any errors, but I also don't get any further than this either:
spinning-forever.gif

I hope I'm opening the right file. I couldn't see anything else that looked openable by a browser in that archive.

That's correct file: index.html
In Safari its in the main Developer Menu, but in Firefox this setting is a pain to get to and edit.

Go to url:"about:config" in the Firefox navigation bar
Then find the setting: security.fileuri.strict_origin_policy parameter
And toggle that to false, then reload that page and it should load the Engine JS after.

Malicious code could take advantage of this mechanism so be sure to turn that back off when you're not developing a websites locally.

Here's a interesting article about the problems with URLs:
https://webkit.org/blog/7086/url-parsing-in-webkit/
That's why its good to test stuff in different browser engines.

Hmmm. Okay, that does indeed work.
I generally use an appimage version of a browser for any testing like this, so it's sandboxed from the rest of the system.

It's not as simple as I'd hoped though. What I'd hoped to offer was a smooth, seamless way (eventually) for someone running xtalk in a browser. It's probably going to be an instant show stopper as many target users won't go changing settings in about:config.
So, if it's hosted online, it'll cut out that step but then the issue of the need for an active internet connection becomes apparent. So that might be a deal breaker too.

It kind of defeats the point of having something that's supposed to behave uniformly across multiple computers.
I mean, I know that's not a new thing. There's always been issues with browser compatibility that this article references. (One of my jobs once was to run an ecommerce site - ordering shoes, nothing glamorous - but they had to put in a load of JavaScript workarounds in case people were still using internet explorer 6, which famously might have been the least standards-compliant browser ever created.

Interesting that although that article was typed in 2016, it's probably just as relevant today with new emerging technologies - with Chrome going one way, Firefox another, and Edge using their own MSDN css standards. Lots of browsers will block other parts of this too - Firefox focus on mobile, brave etc.
It seems that in a way, it's more fragmented and less standards compliant than ever, simply because there's more browser choice out there.

Which kind of stops my idea of trying to offer a unified IDE and script editor via a browser.

The article also raises another very valid point that if something changes in a browser update, it can completely wreck the entire web engine.

So, I'm now wondering if the only true way of offering a unified, compatible experience is by offering the IDE as a distro that someone boots into, which at least means it'd behave the same as you are keeping the os static. That might break due to someone's exotic system hardware in their computer though, so seems you can't win.

tperry2x wrote: ↑Sun Jun 02, 2024 6:05 pm Hmmm. Okay, that does indeed work.
I generally use an appimage version of a browser for any testing like this, so it's sandboxed from the rest of the system.

It's not as simple as I'd hoped though. What I'd hoped to offer was a smooth, seamless way (eventually) for someone running xtalk in a browser. It's probably going to be an instant show stopper as many target users won't go changing settings in about:config.
So, if it's hosted online, it'll cut out that step but then the issue of the need for an active internet connection becomes apparent. So that might be a deal breaker too.

I think you are conflating two different goals here, you wanted to load that webstack from local directory, so you have to disable those restrictions regardless of which browser engine you're using, I believe they would all block loading external .JS files loading from relative paths on disk unless explicitly allowed to. For security reasons that should hold true for any website run from disk that has external script files.

This webstack was only set up to be run in a browser, mostly to test Widgets, JS<>xTalk, HTML5 APIs stuff, etc. and be able to test lines of xTalk with it to see what works in the Emscripten Engine and what doesn't.
I think maybe it could be made into more of like an online mini-IDE. Maybe it could even check if it's running in a Browser or running in Electron or some other desktop app wrapper and modify it's behavior according to how locked down the environment is.

if you wanted to make the Emscripten Engine into a desktop application, that's a different sort of goal really. You would set it up to run in a web-app wrapper such as Electron (I see I left some files in the repo from experimenting with that) where it could be allowed to run UN-sandboxed and also, because each Browser Window runs in it's own thread, theoretically you could do multiprocessing this way with multiple instances running in separate windows communicating with each other. It wouldn't be restricted from filesystem like running in a Web Browser, far from it. App Wrappers include functionality to help enable desktop features, it could even gain access to all Node.JS ecosystem with tons of packages available, including for using System API (such as Apple's CoreMIDI )

It's true, much of that would not be easy to figure out and get functional, getting it there would require lots of working at it... But I do still think that piggybacking xTalk on JS/Web Engine is the best way to ensure xTalk can run virtually on anything for a long time.

Electron app wrapper was developed in conjunction with Atom (now Pulsar), which has pretty powerful access. It can search inside files in directories and such.
https://www.electronjs.org

There's other web-app -> desktop app wrappers out there, but Electron has some nice desktop helper features included.