Hypercard Simulator

[OpenXTalkPaul]

Aside from changing the background colour, and the speech works. Also the button that points to openxtalk.org works.
However, none of the other buttons do anything at http://openxtalk.org//WebStacks/HC3PlusPlus.html
Tested in Firefox and Opera (both fully updated).

Hmm looks fine on Mac Safari and Chrome and FireFox (Mac)
I guess I need to test on all the browsers and all platforms now.
I just tried them on my end and like you said, some of the buttons got broken.
It's the javascript that got broken. The way the simscript is stored is kind of weird as far as line breaks. If you use a 'beautifier' for code indentation it seems to break somethings. I've had to manually reedit this several times already. Might be better to make an OXT a stack that edits the HTML, then I can ensure line breaks are correct (cr/lf).

WebMidi support button also comes back with an alert which says "lame"

Hmmm? Firefox should support webMIDI! Safari is one of only few that don't.
Ah, that chunk of JS got messed up too.

II'll fix it real quick.

[tperry2x]

Okay...
Also tested in Firefox (Android 11), same result. Speech works and setting background colour, but nothing else.

Screenshot_20231217-195049_Firefox Focus.jpg (161.3 KiB) Viewed 1015 times

[OpenXTalkPaul]

Sorry, I didn't get to fix the broken JS today, I was sick with Flu and slept most of the day.

Here's something interesting to try:
https://wavacity.com

It's Audacity ported to Web ASM (along with wxWigdets)
The popular desktop audio recording/editing app runs pretty good for on the web.

[OpenXTalkPaul]

UH DUH!!!
The problem with those buttons not working turned out to be something super simple.
I had those buttons returning their info to the message box, instead of an 'answer' dialog, but the message box, both in the HyperSim and in OXT. is not normally included in a 'standalone' (or exported HTML in HyperSim's case). So they actually would've worked, but for that rookie mistake.
That demo should work now.
http://openxtalk.org//WebStacks/HC3PlusPlus.html

Actually the setting the cursor to a CSS-cursor thing is non-functional, but I do know how to make it work.
The other buttons should all work though.

Not sure if the handler that checks for WebMIDI broken, it is pretty lame itself. I did have it returning 'true' on Chrome and FireFox at one point, but now it doesn't. The handler uses pretty weak checking, it doesn't try to initialize the API, which requires per-site security policy approval to access. To make it useful for xTalk scripting would require a lot more work.
This site can check for WebMIDI API (and it scans the system for MIDI devices)
https://www.onlinemusictools.com/webmiditest/

[OpenXTalkPaul]

There is definitely something funky about the way line breaks are handled in that SimScript editor thing.

I can't figure it out, I've tried using cf & cr+lf, in edit mode the script looks fine, but after leaving edit mode the script collapses (or maybe its trying to clean up as it parses the lines?) loses its proper line order, sometimes putting all the lines of a handler onto one line, which might be OK for JavaSCript to ignore all whitespace but it's not OK for line delimited xTalk.

---------------------------------------------------------------------------------------------------------------------------
As far as license for this 'Engine' well it would be great if Dan offered a more clear license like GPLv3.
But he does grant users the access to the source, rights to copy 'and learn' from it, and to share their stacks web output without being legally tied to his Sim as far as there's no claim on the scripts the Sim user writes of being 'derivative work' (Unlike certain other licensers ).

But perhaps Dan will chime in with details since he's the licenser here?
I'd kind of like to know. I'm prepared to do the work of wrapping all the web APIs so we can all use them with xTalk.

I'm already planning to wrap more of web APIs for our OXT Emscripten engine but that is a bit of a different animal. It's basically a straight port from Desktop Engine (C++ to Emscripten) with some bridging for JS. Its Engine js file is 30mb so if it's not cached it loads a bit slow the first time opening it. HC Sim 'engine' is comparatively tiny (like 1/10th the size) and far more web native.

[OpenXTalkPaul]

Here's HCSim's terms and conditions for using the service provided, which is the storing of converted stacks in a hcsim account on their server ('the cloud') in a form that you can share with others via URL link.

https://hcsimulator.com/termsandconditions.html

HC sim's import rely's on code from Maconv, which is GPLv3
https://github.com/ParksProjets/Maconv/ ... er/LICENSE

I am not a lawyer but my understanding is that this project would inherit that GPLv3 license?
If so then that's the same license we have with the LiveCode Community Engines, so that's good.

[dandandandan]

Here's a copy of HyperSim with 'OXT Simscript Additions' (so far):
http://openxtalk.org//WebStacks/simulator.html

We seem to have UI colour issues unfortunately:
ui1.png

I'm particularly impressed that it can get the platform and the systemversion though
test1.png
result1.png

Will we have licensing issues using this?:
license.png

Hmm, that’s not right. What Linux and browser do you use? Almost all of the simulator bugs are because a browser does something I didn’t expect and it half-works.

[tperry2x]

Hmm, that’s not right. What Linux and browser do you use? Almost all of the simulator bugs are because a browser does something I didn’t expect and it half-works.

In those screenshots, it's Firefox 120.1 on MX Linux (Mate desktop) and Opera 105.
If I go back a few browser versions, (using an appimage) and open this in Firefox 108, then it works fine:

Screenshot_2023-12-19_06-34-07.png (164.95 KiB) Viewed 968 times

So I'm pretty sure it's an update to something they've done in Firefox that has broken something in the sim. Firefox have made a few sweeping changes of late - something in 119+ has also broken cpanel file upload for a few sites I manage, plus they have introduced other issues with the DOM object model.

But this is kind of what I was going on about, where a browser change can (and does) break things as browsers are a constant moving target. This is why I like the suggestion of Paul elsewhere to have a static OXT-Browser if we are thinking browser-based-route. Something that does not change and the code remains as static as possible.

Edit: This is Chrome on the same machine (same distro - MX linux, and Chrome 120)

chrome-ver.png (10.83 KiB) Viewed 962 times

Looks completely different (as it's supposed to look, I assume?)

Screenshot at 2023-12-19 10-32-40.png (130.93 KiB) Viewed 962 times

[dandandandan]

That version is a little old. You might try redownloading.

[tperry2x]

That version is a little old. You might try redownloading.

Sorry, I don't follow you.
That version of what is a little old?
Do you mean Firefox - if so, then yes. I was trying to demonstrate that it works in an older version. The first set of screenshots were in v120 which it didn't work in.
viewtopic.php?p=5251#p5251

As Firefox uses it's own rendering engine (gecko), whereas everything else pretty much uses webkit, it doesn't surprise me when something breaks. I'll have to try this in a variety of different browsers.

[OpenXTalkPaul]

What your'e talking about breaking is a fill color / some CSS styling, but you can replace the style of a button with an unchanging image (or whatever you want really since it's a regular HTML DOM element). The scripting transpiler is obviously still working fine, that's not going to break unless we break it or something changes in JavaScript standard. My point is that problem is purely cosmetic, and those sort of cosmetic problems are going to happen and did already happened in LC Community. Fonts changes in macOS screwing up formatting in stacks, darkMode making some controls look terrible on macOS (until editing their default props to fix), etc.

This is why I've been interested in abstracting away the control/part/control/NSObject/wxWidgetwhatever away from the xTalk language. The modern UI look of today changes with the days. I suppose you could o Richmond's route and build-in custom image based styles for every control, but I'm either going to want a OS 'native' look or I'm not going to put the time into doing that for most stacks. Like I said elsewhere, the Ui details are already somewhat abstracted away in xTalk with Answer/Ask which was later extended with Answer File(s), Folder(s), Color, Record, etc. likewise Buttons, Text Fields, Menus/Items, Popups, Palette, Modal, Modeless, etc. dialogs are to some extent.

I don't think that it is possible to get something that is future proof, even if you wrote it in pure ANSI-C or something, but our OXT engine(s) are already existing in the past so... It's probably the compiled Emscripten w/WebASM lib SDL included engine that has got the best shot of being a future proof engine. WebAssembly is not like old-school Assembly, it's not making architecture or CPU specific binaries.

It would be nice if you could re-import your exported Stack.HTML back into the Sim in order to fix up any glitches like that.
I haven't yet figured out how to manually (on a server) get stack content into the sim with out using an account system setup. Also I haven't been able to collect some of the icons images that the sim and home stack rely on. Are they coming from some HyperCard Artwork pack or numbered PNG files?

[OpenXTalkPaul]

This is also part of why I'm interested (again) in some sort of xIFF (xCardInterchangeFileFormat) that encapsulates resources used by a stack cards and preserves their spacial layout no mater what 'the engine' is underneath it's xTalk scripts. Then even if some of the xTalk syntax is incompatible in a different engine, at least scripts and the basics UI elements and layout will still be imported. Even if no usable xCard/xTalk engine exists in 30 years time, a plain text (binaries as bae64 encoded data URLs) file would still easily be parsable by whatever is available then (and probably some AI could figure out the clearly tagged formatting). That only works if there was such an infrastructure in place, and of course assumes the planet is not a hellscape by then.