An JS implementation of XTalk script in HTML/DOM

Organizing tasks to work on, New Features Ideas, Building LCS & LCB Libraries & Widgets, Redecorating and Modifying the IDE, Hacking / Editing Tools, Compiling the Engine from Source, etc.
Post Reply
xAction
Posts: 281
Joined: Thu Sep 16, 2021 1:40 pm
Contact:

Re: An JS implementation of XTalk script in HTML/DOM

Post by xAction »

Sweet. How do we adapt that?
Did you contact them?
Lol from their Twitter feed:
outatouch.png
outatouch.png (268.02 KiB) Viewed 8121 times
Just dragging a browser widget into a stack adds 143 MB to the binary build via the externals folder.
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: An JS implementation of XTalk script in HTML/DOM

Post by OpenXTalkPaul »

I’m just starting to look at this more, it’s pretty cool and is built with async capabilities in mind (Promise variables that just work), and you can intermix with JS so you could theoretically use this in something like React Native engine on the desktop, which opens up a lot of possibilities! https://hyperscript.org/docs/#async

This is more reason to have some sort of openXTalk generic stack exchange format, be it XML,JSON, or a SQL Db , some new StakML we invent, the storage format doesn’t matter as much as making some sort of stack interchange format that can finally be some sort of an actual XTalk standard, with a I guess some minimal xTalk language set requirement. This way content can more easily be manipulated for different engines (I mean beyond a fork of LCC, anything xTalk or maybe xTalk-ish, that can recognize XTalk on some level, or can transpile to / from it.
xAction
Posts: 281
Joined: Thu Sep 16, 2021 1:40 pm
Contact:

Re: An JS implementation of XTalk script in HTML/DOM

Post by xAction »

Posted a little test stack of HTMLX/Hyperscript in a OXT browser object.

That part was easy, going to the other way, ie stack to web will be harder, I think worth it.

So about that stack storage format:

Why not just raw text and directories?
I was converting LC UI to Nuklear for Love enginejust before the open source was canceled, which killed the motivation of inviting the Love crowd to help with that effort.

My script was based on an old one and for some reason it had A LOT of redudancy, let's see if I can find that example.

Code: Select all

--- button "Button",card id 1002,sample
Button:rect(10,12,92,35)
Button:height(23)
Button:width(82)
Button:loc(51,23)
Button:short name("Button")
Button:ID("1003")
Button:label("Button Label")
Button:toolTip("button tooltip")
Button:style("standard")
Button:visible(true)
Button:showName(true)
Button:autoHilite(true)
Button:opaque(true)
Button:sharedHilite(true)
Button:traversalOn(false)
Button:showfocusBorder(true)
Button:icon(0)
Button:hiliteIcon(0)
Button:borderWidth(2)
Button:textAlign("center")
Button:blendLevel(0)
Button:ink("srcCopy")
The idea behind this particular format is that it would be converted to Lua GUIs.
14 years later I had to figure out how to translate to Nuklear.

How this all worked was I exported the property of all objects and it all got buried in appropriate folders
So
stackName/
stackName_script.txt
stackName_properties.txt

Actually for the stack properties I'd just stored a text file with the script to set it's properties. Not sure why I thought that was good idea.

stackName/stackName_UI/
stackName/stackName_UI/stackName_cards/
stackName/stackName_UI/stackName_cards/card_1002/
stackName/stackName_UI/stackName_cards/card_1002/button
etc for fields, images, scrollbars, graphics, widgets, groups

Those final directories contained the files with the properties as shown above.
I would sort the properties so large texts would be at the bottom of the list.
Although I was tempted to maybe make an exception for larger text type properties. I didn't store any images but I bet imageText property would be a mess.

Then there was a seperate directory for scripts, followed the same pattern of sub directories.
stackName/
stackName/stackName_Scripts/
stackName/stackName_Scripts/stackName_cards/card_1002/card_1002.txt

Oh yeah and another directory for custom properties, following the same structure.

This was all just to back things up in case a stack was corrupted, we had some way of dumping the syntax colored scripts to HTML for Scripter's Scrapbook (Aw looks like Flexible Learning retired...some HC related stacks in there)

Looking at in the forum it's an eyesore, but if you go look at your Mac desktop and dig through a few folders, it works just fine, and the idea was never to actually look at those files, unless you lost a function or handler somewhere, then you'd use your file search to dig around for some variable , function name or property to find the text file.

The stackName_ redudancy probably wasn't necessary, adding extra length to paths which windows cries at me when I'm archiving to external drives. It was probably put there just to make sure a drag and drop didn't replace files.

So why not directories and raw text? That's what Mac OS X...what are they called? Bundles are. Ah but now I recalled they were chock full of XML too.

Could bind the whole thing up in Zip and then read the zips.
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: An JS implementation of XTalk script in HTML/DOM

Post by OpenXTalkPaul »

The format you describe is similar to what StackSmith arrived at but without the sub directories, every object, image, layout CARD_ID1234.xml , sounds, scripts, separated out into a single folder .XSTK bundle, but could also use relative paths for sub directories if desired. That used OpenXION's StackImporter format, which is based on reverse engineering the RIFF-like chunks of that original binary Stack format.

The excellent HyperCard preview app I've been using extracts bpm images and a JSON (your fav) format of it's own, it labels "Controls" (classic controls) as 'Parts' instead of by control type,' but still it's at the familiar structure from "Application Browser", with stacks/substacks, card, backgrounds (groups), resources (embedded images, sounds, etc.), and GUI Controls all tagged up with their properties.

To this I'd like to add some <StackMeta> tag too, this would be used to store some basic info about the stack. Perhaps a description and preview image, some info about the stack's origins (originally created in HC?, MetsCard 2? LC5? LC8 with widgets?, Author info, License/GPLv., etc.)

In addition to supporting expanded-to-directories with each individual resource living in external files linked via xml, I'd like to have a flat, encapsulated format (ESTK), where even binary resources such as images/sounds/svg/html/midi/etc. are stored in tags within the same file, encoded as Base64 if necessary, and then expanded into memory during the XT-ML- to-Stack conversion process. Perhaps we need a <resource> tag, for any kind of binary asset, binary formatted stacks or even compiled bytecode! I've used this technique to embed Builder Extension into stacks that decode the Base64'd Builder Extension into a data variable and loads the extension from variable in memory, works great! I've also used this technique to embedded SVG compiled data on the end of "Script Only" files as just plain Base64 data tacked on to the tail of the files. This would be similar to EPS (Encapsulated PostScript) or how PDF stores XObjects, if anyone is familiar with that (I am, that's another stack you won't find in the Archive.org HC collection!).

Even going back to HyperCard Resources embedded binary resources could be stored this way (this was actually inherent to the classic macOS, we all loved hacking around with ResEdit, right?), which has been important for archival length use. Back when, many Stacks made extensive use on Xternal XCMD/XFCN extensibility to things like displaying full color images, communicating with hardware music devices, playing MOD sequences, palettes, custom dialogs, etc.

The same holds true now, for example there's at least five different ways to use SVG vector art in LCC/OXT... The SVG Path data (or even the whole SVG file could be stored as a tagged resource then can be applied anywhere in the stack using a Widget (SVG Icon, or HHGrid, or whatever), using drawingSvgCompileFile(pXmlFile) + Image box, converting the vectors into layers of Graphics controls (Someone actually wrote a stack that does this a long time ago) or inserted into a Browser Widget for rendering.

Perhaps most importantly I've already been working on scripts that do this, wrap up a stack like in encapsulated way, with ImageData, or the text of image, being encoded in Base64 and tagged as such.

I'd like to have variation gen support levels, with HyperCard 1.2 based features being used as the most basic XT1L reference platform ( 11KHz Mono 8bit samples for example). StacksML at this level should be abled to be converted to run on just about anything 80s retro, HC WASM on miniVMac.js, ViperCard, WyldCard, and be easily adaptable up to any modern xTalk implementation.

Followed by XT2GL generation level support, this would indicate use of mid-90s HC level, SuperCard 1,2,3x, up to MetaCard 2.4, Media Objects (?), up to HyperCard 2.4 with color support, media player control, etc.

Next would be XT3GL gen, this would mean it should be runnable on RunRev 2.5+ up to LC6, IDE Addons, custom properties, sub stacks, paletteStack, menuStack, front scripts, backscripts, script libraries, animation engine, etc.

Followed by XT4LGL level, this would mean it should be runnable on RunRev 7+ up to LC9, full unicode support, scriptonly stacks, builder lang, extensions, extensions, widgets, etc.

Eventually some XT5GL generation level, this would be whatever the future holds, perhaps web based event handler, message queuing JS frameworks becomes most common underlying engine, or some other WebAssembly engine, maybe built on top of something simple like ViperCard, or _HyperScript directly with REACT NATIVE providing the UI controls and messaging and we all get very comfortable mixing XT with JS freely? Who knows?
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: An JS implementation of XTalk script in HTML/DOM

Post by OpenXTalkPaul »

SO what we have in most xTalk's (or what they should be after), is this term I was just reading about "Application Virtualization", just as a VM is abstraction from the underlying hardware, an abstraction layer between Scriptable UI toolkit and it's underlying Software Engine, as well as abstraction of OS, and by extension hardware.

Hardware abstraction is what WASM is all about, portable middle-ware bytecode that can execute at native (OK at near native) speeds on any platform that can run it (so any platform with modern browser tech). It's also encapsulated, apps packaged for sandboxing (the way all Android apps run). I do think it IS strategically smart of LC Ltd. to concentrate on web assembly engine.

I'm interested in that too! WebAudio, WebMIDI, WebGL, WebSomeEngine, Some.js library, etc. access from an xTalk on any platform? Count me in!

https://en.wikipedia.org/wiki/Applicati ... ualization
Diagram of application virtualization
Illustration of an application running in a native environment and running in an application virtualization environment
Full application virtualization requires a virtualization layer.[2] Application virtualization layers replace part of the runtime environment normally provided by the operating system. The layer intercepts all disk operations of virtualized applications and transparently redirects them to a virtualized location, often a single file.[3] The application remains unaware that it accesses a virtual resource instead of a physical one. Since the application is now working with one file instead of many files spread throughout the system, it becomes easy to run the application on a different computer and previously incompatible applications can be run side by side.
With an encapsulated format, XT ML (?) STAKML(?) ESTK (?) we could have the App With GUI Props,Scripts,Resources, AND if desired could actually include an embedded Indesign MarkUp IDML file along with super-high-res-drum-scanned image for the prepress guy (at least in RGB Color if not CMYK!)!
Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests