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 17281 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 17234 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 17228 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 17228 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.

[tperry2x]

A bit of a random Hypercard video.
https://www.youtube.com/watch?v=FJZLi47Hff8

[richmond62]

Well, even though Eric Miller has a similar hairstyle to Richard Stallman at least he doesn't have the 'Farinelli's Last Concert' annoying voice.

Having attended a presentation by Richard Stallman about 20 years ago (at the Palace of Culture in Sofia), I can honestly say that it made me distinctly anti Open Source software at least until I could get Stallman out of my head.

To my mind this bloke (Eric Miller) spends so much time on the "meta-wibble" + silly similes ("The Gateway Drug of the 80s") that I started defocussing quite quickly.

At 21 minutes he's still burbling . . . come on man, get to the point.

Oh, Wow: at 21.30 t'other bloke starts . . .

24.44: something happens on screen.

25.40: a cat that chases your mouse.

I'm off to chase a cup of coffee and get back to the representation of a breathy voiced retroflex lateral approximant in Vedic Sanskrit and Devanagari script, which probably isn't very interesting to many people, but certainly holds more for me that these 2 blokes having the slowest moving whatever about Hypercard . . .
-

HL.png (1.19 KiB) Viewed 14460 times

-
. . . After all, if I really feel an urge I have Danny Goodman's mind-blowing prolix Complete HC book & HyperCard installed on a machine where I can play around with it.

The advantage, from my point of view at least, is that I can sort out a glyph for the breathy voiced retroflex lateral approximant in FontForge, churn out the font, load up my Devawriter Pro source stack, make a button featuring the glyph, insert it on the appropriate card in the stack, save the thing, and run off standalones in less time than 'Laurel and Hardy' wibble on about not very much in that film.

Try saying "breathy voiced retroflex lateral approximant" without getting 'breathy'.

[richmond62]

The advantage, from my point of view at least, is that I can sort out

in 35 minutes: damn sight better than listening to those 2 wibbling on for 58 minutes: sorry, NOT!

They don't even seem to mention anything about programming-qua-programming in HC.

Here's a series that really DOES teach HyperCard programming:

https://youtu.be/eotIlE082DE?list=PL1GQ ... LvFGlF7yF5

As the presenter is a hairy guy called Eric, he may be the Eric Miller in your video: BUT he is ON topic with a lot less extraneous noise.

[tperry2x]

Yes, same guy - different day.
This illustrates my point on how it's hard to keep a YouTube video both:

A: interesting so the user doesn't nod off or click away
B: the difficulty of keeping the video on-topic

[OpenXTalkPaul]

Yet another thread on ycombinator praising Hyper Sim and some lamenting that there's no modern HyperCard, smh.
https://news.ycombinator.com/item?id=40793924

I still see articles and threads like this a few times a year.

[richmond62]

As far as I can see a lot of those people moaning that there is no 'modern' HyperCard are, frankly, just plain lazy: I bet they perform web searches containing the word 'HyperCard'; it has never occurring to them that not all of us give a damn about what the thing is called, all we want is the thing ('CheesePlate' anyone?), and that they could make just a bit of an effort . . .

I arrived in Scotland just as those happy people flew a plane into the world trade center, having had a 'fine romance' with Toolbook for 2 years.

There I am in a 100% Macintosh EFL 'tank' hired to make EFL software with no programming anything supplied. MacOS 10.0.

30 minutes later I find MetaCard, 2 hours later I find Runtime Revolution.

Searching for 'HyperCard' on the internet, if you are looking for stuff for contemporary computers is just a waste of time.

[OpenXTalkPaul]

30 minutes later I find MetaCard, 2 hours later I find Runtime Revolution.

Searching for 'HyperCard' on the internet, if you are looking for stuff for contemporary computers is just a waste of time.

I never heard of either back then. I'm sure I was looking, maybe I didn't search that hard since I was able to continue using HyperCard up until around 2006 (or maybe I saw the MetaCard price and then ignored it completely). I didn't move from macOS 9 to OS X until 10.2 (Panther). IMO it wasn't release-ready for prime-time yet until 10.2 came out. For a time there I did try to get into using AppleScriptObjC (ASOC) with interface builder but it was pretty far from real-time intuitiveness compared to building a UI in an xCard environment.

Also some people like the retro-aesthetics of using 1-bit UI. I've seen someone recently making "standalone' desktop "apps" from HC Stack + HC + macOS emulator as their 'engine'. It can work surprisingly well.

https://bribrikendall.itch.io/blah-blob

https://ryantrawick.itch.io/hyper-pt