Xtalk in a browser, again... thoughts and issues

[tperry2x]

The biggest problem with I/O is using that to import export a stack. It can create and edit stacks in its virtual filesystem (in the browser's cache) but I haven't figured out a way to get at the raw-binary data of those newly created stack files in memory so that I can export it as a stack file via web APIs. Unless it's a script-only stack in which case it's just a regular text file (the OXT playground already has a demo of export/saving a text file).

That's good. Kind of what I was thinking is having the electron-wrapper-IDE ready to save a script-only stack. Your electron-based IDE would show a blank new stack window - like a normal project. You drag a button in, and let's say you position it at the loc of 200,100 manually (for argument's sake).

Behind the scenes, the electron-wrapper-IDE is writing:

Code: Select all

on startup
   create button "Button"
   set the loc of button "Button" to 200,100
end startup

So you save your script-only stack as 'test.oxtscript' - however, each time you open the stack - you'd see the button in card 1 of the stack because it's assembled the stack for you in realtime (like what the revTools stack does).

In this way, you build your stack normally with GUI tools and palettes - the same way you do, it's just 'reassembled' from the script-only-stack each time it's opened, if that makes sense?

Modern Web Engines come with a lot of built-in APIs already, from which we can pull in information about the environment it's running on, such as things like checking the platform, architecture, darkmode, etc. are easy to get from these web engines which would mean less need to use the shell() anyway. Support for multi-media playing, text-to-speech, gamepad input, WebAudio, WebMIDI, SVG animations, and much more already come included with most web frameworks.

That's cool - it gives a solid foundation for getting a lot of information (should the user need to run shell commands).

Just been trying iOS builds - as I was curious as to how iOS would render 'classic controls' - pretty much the same as Android as it turns out - so these would need rethinking to look nice. Plus you need to pay for a provisioning profile from Apple to do it properly, but that's an alternate way of developing an arm engine I thought - because once the iOS app exists, you can actually run this as an arm app on your MacOS desktop.

Just playing with ideas at the moment.

ios-dev.jpg (261.98 KiB) Viewed 3011 times

[OpenXTalkPaul]

The problem with Emscripten engine and saving a stack created within it, seems to be that it does not seem to truly write a stack file to it's virtual filesystem, where it could then be read back into variable as binary data, which is what I need to be in order to pass to the web file API so that it can be saved by the user to their downloads / local storage.

That is one of the reasons I was so keen on the idea of using or creating some generic 'stack' file format, from almost the very beginning of OXT: viewtopic.php?t=152&hilit=Stack+Interchange+Format
Just like the interchange format proposed in the early days of HyperCard clones: viewtopic.php?t=299&hilit=Interchange

But more recently I was thinking as a base format I would just go with what Dan Gelder came up with as far as "stack" format, which is that it's basically a HyperCard 2 format but translated to a web page with custom tag elements (which might not have built in support 10+ year older browsers), <stack-part>,<button-part>,<card-part>,<background-part>, etc. Which could be expanded further, for example there's no <group-part> (but <backgound-part> is basically the same thing), there's no <slider-part> (HC 2.4 did'n't have a built-in slider control, if you wanted one you had to roll your own or use an Xternal).
I have a proof-of concept stack that can re-create OXT controls as these HTML 'parts' (not perfectly accurately of course but close enough) from OXT IDE as opposed to using HyperCard Simulator. If I had the time to I wanted (still want to) write some OXT scripts that can read these stack.hlml files and then recreated them in the IDE, as well as export to .html (and while exporting also embedd the JS X-talk interpreter / engine).

[OpenXTalkPaul]

That's good. Kind of what I was thinking is having the electron-wrapper-IDE ready to save a script-only stack. Your electron-based IDE would show a blank new stack window - like a normal project. You drag a button in, and let's say you position it at the loc of 200,100 manually (for argument's sake).

Behind the scenes, the electron-wrapper-IDE is writing:

Code: Select all

on startup
   create button "Button"
   set the loc of button "Button" to 200,100
end startup

So you save your script-only stack as 'test.oxtscript' - however, each time you open the stack - you'd see the button in card 1 of the stack because it's assembled the stack for you in realtime (like what the revTools stack does).

n this way, you build your stack normally with GUI tools and palettes - the same way you do, it's just 'reassembled' from the script-only-stack each time it's opened, if that makes sense?

Yes that makes sense.
There is a script stack in one of the IDE repos that's called Scriptifier, that takes a GUI binary stack and creates script-only behavior scripts extracted from the original stack. More recently I found a script (in Monte's repos IIRC) that I think was meant to be the GUI compliment to that, creating a script only stack that recreates its UI on-the-fly on startup. That is basically the same idea you're talking about, same as the script-only versions of the 'Tools' palette. So might want to look at that before starting anything from scratch.

The stack file sandbox problem with Emscripten running in the browser might NOT even be a problem for the Emscripten engine when it's running inside an Electron Wrapper, because Electron has it's own seperate File IO APIs that can directly access the filesystem (permissions permitting), no more sandboxed than any other desktop app.

That's cool - it gives a solid foundation for getting a lot of information (should the user need to run shell commands).

Exactly, having a nice foundation makes things easier, and the huge-mega-corp companies like Apple, Google, MS get to maintain it. There's a lot of 'plus-side' to piggy-backing an xTalk interpreter on top of a Web Engine.

Just been trying iOS builds - as I was curious as to how iOS would render 'classic controls' - pretty much the same as Android as it turns out - so these would need rethinking to look nice. Plus you need to pay for a provisioning profile from Apple to do it properly, but that's an alternate way of developing an arm engine I thought - because once the iOS app exists, you can actually run this as an arm app on your MacOS desktop.

Yes, and the Emscripten engine is a LOT like the mobile engines, defaults to MOTIF (on OXT Playground I changed it to use macOS Classic lookAndFeel), as well as being similarly sandboxed. That's another reason why I wanted to make widget versions of the set of 'classic controls' and also there's no Window Manager added Window Frames and so I wanted to make a window-frame-Widget that would come pre-scripted and ready to adhere to a stack as a stand-in for the missing stack window frames.

As an experiment months back, I did add a menu and bits of the OpenSource MetaCard IDE to the OXT Playground webstack: https://openxtalk-org.github.io/OpenXTalk-Playground/

Screenshot 2024-11-20 at 8.44.12 PM.png (404.67 KiB) Viewed 2999 times

Some other those things aren't (yet) functional but some of it is.

[tperry2x]

...there's no Window Manager added Window Frames and so I wanted to make a window-frame-Widget that would come pre-scripted and ready to adhere to a stack as a stand-in for the missing stack window frames.

When you consider the current variations in Linux window managers and how they deal (or not) with window focus, and been finding various versions of MacOS treat window focus differently too, not having window frames as such seems like a good thing

Some other those things aren't (yet) functional but some of it is.

It's coming along well, just wish I knew how to help with it.

[richmond62]

Straight outta Compton:
-

SShot 2024-11-21 at 9.57.50.png (15.35 KiB) Viewed 2938 times

-
Whoops: MetaCard.

This 'recycling' seems a very good idea:

1. Saves you time.

2. Makes people like me get 'warm fuzzies' and feel more positive towards what you are doing.

[tperry2x]

I like this, and it's indeed something I can add to OXT Lite in a very similar fashion.

Silly question time:

nav.png (17.63 KiB) Viewed 2892 times

I'm assuming the area I've circled in red is the recent navigation?
Not sure which button here does what.

[tperry2x]

Hi Paul.
Rather than risk messing up any of the great work you'd done on the openxtalk-playground, I've put this demo together of saving json content of a file.

test.png (4.79 KiB) Viewed 2891 times

On my test, if you draw a rectangle on the screen with what I'm generously calling my button tool, then click on it, you can type some text into my makeshift script editor. You can then use the save and load buttons on what would be a stack. (You'll have to use your imagination somewhat )

Does that help at all?

web-test.7z

(2 KiB) Downloaded 59 times

And here's a sample JSON file (which could be your 'stack' file) I created with it:

saved-stack.json.7z

(292 Bytes) Downloaded 60 times

For anyone trying this out, you don't need web access at all. Just a browser not even connected to the internet.
Keep everything in the same folder, just open the index.html

it uses Javascript and CSS. Nothing much more fancy than that.

[OpenXTalkPaul]

For anyone trying this out, you don't need web access at all. Just a browser not even connected to the internet.
Keep everything in the same folder, just open the index.html

it uses Javascript and CSS. Nothing much more fancy than that.

Figuring out the stack import/export in web sandbox problem was a big stumbling block for me, but getting the other bits of MetaCard or similar IDE parts work correctly on the web would be helpful too.
Additionally if there's some syntax that doesn't work correctly, or returns bad values (exp. 'systemAppearance' always returns 'light' in Emscripten engine) and you can find some JavaScript examples that do the same thing, that would be great.

Any help is appreciated, thanks.
The stack file that the OXT Web Playground was built from in its repo if you want to play around with it. I don't know what you mean by that? if you break your copy of the stack it doesn't affect any other copies of it (which I'm sure you know), so have at it!

Using a JSON format may be another option. HyperCard simulator I think uses ULI's stack-import format (outputs JSON) as an intermediate step between HC stack and the HTML format.

You can open some web pages off-line, but if the page uses external resources like .js / .css rather than embedding them into the html file, you might have loading problems. However, most browsers have a developer menu where you can turn 'local file restrictions' and then it should work, just make sure to disable it again when your done for security reasons.
Also, you could always run a webserver locally (even without internet) and then access it through 127.0.0.1:80, that's how those webapp wrappers work, and I think the IDE does that to when you use the 'test' run button for the Enscripten 'standalone'.

By the way, you should replace the template files for Emscripten in the 'runtime' folder with my versions, because OXT still has an LC branded web-page when you build an Emscipten standalone.

[OpenXTalkPaul]

Another plus to using Emscripten I think is the fact that each 'stack' gets run in its own thread, so instant multi-threaded, like they're running separate instances of the same app, but Electron app wrapper comes with a JS API that allows the webpage windows to send/receive messages to each other,

Also, I'll have to upload the experiments I did with HCSim, because I already wrote some scripts that convert some OXT controls into Dan's html format. Also my modified t 'simscript' of the HC sim JS, already has some syntax additions beyond HC 2.4 (such as 'the systemAppearance ') to that 'Engine'. The 'Engine for that' is really a BNF grammar to xTalk translator with implimentation 'back end' duty in JavaScript. It's pretty easy to map some javascript function to use from xTalk syntax.

[tperry2x]

Any help is appreciated, thanks.
The stack file that the OXT Web Playground was built from in its repo if you want to play around with it. I don't know what you mean by that? if you break your copy of the stack it doesn't affect any other copies of it (which I'm sure you know), so have at it!

Well, without meaning to go back over old ground and bore everyone, I really have this mental block when it comes to github. I have tried again, and again, and again, and again (honest!) but I really just don't understand it. You could tell me until you are blue in the face, but it's just going to be my insurmountable hurdle - something I just can't get over.
I have no idea if what I'm editing would affect your code, or how to save my changes & prevent them being lost. Or how to delete something that I might have typed and submitted in error. Meh - I actually feel slightly sick going back over all this again, and I'll typically do all I can to stay out of github.
I've already wasted too much of my life trying to make sense of it. That's no reflection on you, or anyone who's tried to show me. That's purely on me and my inability to grasp how it works. I've watched Lynda.com videos on it (before it became linkedinlearning) and I've even got a whole set of tutorial demo videos on it. None of it makes sense (I actually fell asleep at the computer watching it - sitting bolt upright in the chair). That'll give you an idea of how I regard it. That's not an exaggeration, it very much happened to my Mrs' ammusement.

You can open some web pages off-line, but if the page uses external resources like .js / .css rather than embedding them into the html file, you might have loading problems.

I get where you are coming from with that, as I know browsers are getting tighter at loading things locally, but I'd not done anything special settings-wise. I've tried that simple json-saving stack of mine above in Firefox, Safari and Edge - and they seem to have no issues running the javascript from a locally hosted instance, rather than online. I was purely trying to utilise the benefits of using the browser as the 'engine' if you like, but having the files I'm editing as locally stored (rather than remotely stored) at the same time. Yes, I know - I'm set in my ways.

Also, you could always run a webserver locally (even without internet) and then access it through 127.0.0.1:80, that's how those webapp wrappers work, and I think the IDE does that to when you use the 'test' run button for the Enscripten 'standalone'.

I've never got the enscripten engine to show... well, anything except this:

Screenshot at 2024-11-21 21-56-17.png (7.24 KiB) Viewed 2833 times

I just assumed that's as far as it ever got?

[tperry2x]

Another plus to using Emscripten I think is the fact that each 'stack' gets run in its own thread, so instant multi-threaded, like they're running separate instances of the same app, but Electron app wrapper comes with a JS API that allows the webpage windows to send/receive messages to each other,

I like the sound of that, as it seems like that would be beneficial for preventing loops which might seemingly make the IDE seem unresponsive or slow. I take it you'd not have to do "send in [x] [time]" anymore if you were running a loop - and while a loop is running in a button, you could click another button to start something running there simultaneously as well?

Also, I'll have to upload the experiments I did with HCSim, because I already wrote some scripts that convert some OXT controls into Dan's html format. Also my modified t 'simscript' of the HC sim JS, already has some syntax additions beyond HC 2.4 (such as 'the systemAppearance ') to that 'Engine'. The 'Engine for that' is really a BNF grammar to xTalk translator with implimentation 'back end' duty in JavaScript. It's pretty easy to map some javascript function to use from xTalk syntax.

I think it would probably be best if I come up with 'snippets' of code. Or, just pootle around with my own experiments. I'll continue to comment my code throughout, and if there was something useful that works for you - you are of course welcome to take any part of it. I'll probably create a privately shared folder for this, because while the OXT engine has the GPL3 underpinnings of LC, my versions are not based on any of their code - and I don't give LC permission to use any of that (because ultimately it's my time and effort I'm putting in) and that's not to benefit a closed source project.

[OpenXTalkPaul]

I've never got the enscripten engine to show... well, anything except this:
Screenshot at 2024-11-21 21-56-17.png
I just assumed that's as far as it ever got?

Copy my whole folder from the IDE /Runtime/Emscripten/
Because I 'unbranded' both the html loader page template (replaced spinning LC SVG Logo with an SVG of generic stack icon) and may have adjusted somethings inside the Engine standalone .JS file too. I changed Standalone files names in the process, and I think I may have had to modify the Emscritpen Standlone Builder stack too for it to look for the new generic names. That renaming is probably why your version of the Standalone Builder stack can't find the files.

Don't worry about GitHub.
I don't use Git from the command line at all (the way it's really meant to be used), I mostly use GitDesktop to sync a local copy to GitHub's servers (which give each set of push changes a unique identifier automatically). And I've never done a 'regression' the way it's supposed to be done (at least not without someone helping me do it from the command line), instead I'll use GUI in GitDesktop or the web UI to go back to the previous 'push' and then redownload the old version of a file that I've since messed up and overwrote. There's a way to do that in a single Git command-line but I can't be bothered with that (I guess I would be forced to learn it if I was actually a professional developer). Best to not push a messed up version to begin with, but of course that happens. If you make your own 'clone' of a repo, you can push all the bad files to it you want and I can choose to not to emerge your changes into my original copy of the repo, that way you have your own experimental development version of the rep, no harm to the originals unless I pull in changes from your fork of the repo, if that makes sense. Additionally, I tend to make a local copies of a file that I'm about to work on, that way I can always revert to it (without GitHub being involved).
Maybe I should do my own video training series on: 'how to be too lazy to actually learn Git command lines, yet still use GitHub".

[OpenXTalkPaul]

Oh and all you really need to download is the stack file that made the playground standlone:
https://github.com/OpenXTalk-org/OpenXT ... d.oxtstack

EDIT: That's not quite true, I've added some JavaScript to the container page for demo purposes (to support realtime MIDI music performing with the Piano widget), so you need the index.html in there ( https://github.com/OpenXTalk-org/OpenXT ... index.html) and if you want to create music you'd need the webaudio-tinysynth.js file ( https://github.com/OpenXTalk-org/OpenXT ... nysynth.js ) and the boing.wav file (https://github.com/OpenXTalk-org/OpenXT ... /Boing.wav) used by the sound play demo buttons.

[OpenXTalkPaul]

Just like the interchange format proposed in the early days of HyperCard clones:

Adding a link to that previous comment:
viewtopic.php?t=299&hilit=Interchange

[OpenXTalkPaul]

Some more thoughts on this.
A combination of HyperSim or similar xTalk<->JS 'engine' along with HTMX + _HyperScript ( https://github.com/bigskysoftware/_hyperscript ) could be all that we would need to go far in this direction.
Those three JS libraries combined would be less than a single megabyte of downloading, 1/28th the size of the Emscripten engine. Could do a lot of eye-candy FX with _HyperScript (plus that's still an xTalk).

[tperry2x]

Have tried this morning.
The only way I could download that folder from github was going to here (a completely third-party site offering a way to download a folder).

Then pasting in the URL:

Code: Select all

https://github.com/OpenXTalk-org/OpenXtalk-IDE-DontPanicEdition/tree/OpenXTalk-develop-1.963.1/IDE%20Bundle/Contents/Tools/Runtime/Emscripten/js

That begins downloading all the files which come through as a 60MB ~(ish) zip file.
I uncompressed these into the runtime folder at:
[location of installed IDE]/Runtime/Emscripten/js/

But unfortunately I still get the same error:


I may just wait to try it in your OXT RCx 'heavy' version, so not to worry.

[tperry2x]

Thanks for that link to bigskysoftware's hyperscript Paul.
Good find. I'm downloading it, having found something I can download, here.
Comes in at 34MB, but will have a play.

[tperry2x]

Have had a play, and couldn't really get anything running. I did look at their source, and the way they approach their interpreter does give me a few different ways I could achieve something similar though. Again, whether it'll ever be at a useful stage is another matter altogether.

[OpenXTalkPaul]

Have tried this morning.
The only way I could download that folder from github was going to here (a completely third-party site offering a way to download a folder).

Then pasting in the URL:

Code: Select all

https://github.com/OpenXTalk-org/OpenXtalk-IDE-DontPanicEdition/tree/OpenXTalk-develop-1.963.1/IDE%20Bundle/Contents/Tools/Runtime/Emscripten/js

That's it, that's the JS file of the Emscripten Engine (with 'de-branded modifications) you could also get that and a host HTML page by downloading the 'Playground' Repo, which also contains the stack version that the playground 'standalone' was built from.
https://github.com/OpenXTalk-org/OpenXTalk-Playground/

Screenshot 2024-12-16 at 4.47.48 PM.png (623.07 KiB) Viewed 1432 times

The only additional modification I made was to the host page (compared to the version in my 'runtime/emscripten/" folder was to import the JS library TinySynth to enable MIDI music note play.

The Emscripten Engine standalones deploy as a set of three files:
index.html -- the loader webpage
standalone-community-9.6.3.js -- the Emscripten (asm.js based) Engine javascript file.
standalone-community-9.6.3.html.mem -- THIS is a virtual file system for the web sandboxed. It's like a 'memory overlay' that contains your stack files(s), extensions, fonts, and anything else that may have been included when the standalone was built.
https://github.com/OpenXTalk-org/OpenXTalk-Playground/


The only additional modification I made was to the host page (compared to the version in my 'runtime/emscripten/" folder was to import the JS library TinySynth to enable MIDI music note play.

The Emscripten Engine standalones deploy as a set of three files:
index.html -- the loader webpage
standalone-community-9.6.3.js -- the Emscripten (asm.js based) Engine javascript file.
standalone-community-9.6.3.html.mem -- THIS is a virtual file system for the web sandboxed. It's like a 'memory overlay' that contains your stack files(s), extensions, fonts, and anything else that may have been included when the standalone was built.
https://github.com/OpenXTalk-org/OpenXT ... /main/docs

[OpenXTalkPaul]

The main snag I can see about those profiles being there is that 'naughty' types like myself can pump out standalones pretending to be a member of the LiveCode team: so they definitely have to be removed.

That would be a pity wouldn't it.
Why am I doing LC's bug-fixing for them?

I do't think you could 'pump out standalones pretending to be a member of the LiveCode team', for that you would need to codesign with their developer account certificate (depending on platform), this just appears to be saved Standalone build settings (?).