overclockedmind wrote: ↑Thu Jan 18, 2024 2:19 am
I can't really believe how much the code of the button to start/resume the game is so...HyperTalk-ish. Like code specific to a HC 2.x stack.
I'm fascinated. THAT I can code like.
You imported to LC... I went back and read through everything. What I don't get is, am I supposed to use that method to create, importing from "the before times?" It just feels like LC 7-9 would have laughed me right out of the room if I used that same code.
It's hard to explain. I'm gonna play around with some other stuff and try writing "that way."
Well the thing should run in LC 9.x as that's where I originally started to tweak it to get it running on this particular xTalk Engine. I used LC 6.7.5 or 6.6.5 on SnowLeo to import it.
But that this required minimal changes to get it to run on a completely different Engine, is kind of a testament to the clever tricks people had to use in order to get the HyperCard Engine to do what they wanted it to do. And it shows that our xTalk dialect is compatible (enough) to a lot of HyperCard scripts (it is still missing some HyperTalk functionality).
I understand that newer commercial versions of LiveCode have gone and fixed HC stack importing (previously broken since v7), which I guess was from their big post FOSS bug-hunt.
In OXT DPE on Mac if you open a HC .stak file in OXT DPE it will forward (and rename file with .stak) the open file message to HyperCardPreview (if it's installed).
I've also used 'stack-import' (command line tool) and HyperCardPrievew.app (which is an app written in Swift that can display stacks/cards and scripts, but without any execution engine) to convert simple stacks via cut and paste into OXT. These conversions produce stuff like XML,JSON,PNG,text, etc. for their resource counterparts formats.
HyperCard Simulator's import goes a step further in pulling in assets, it will even convert SND PICT ICON etc. resources (it's 'engine' also emulates a few common HyperCard XTernals like addColor), and then embeds their binary data (like a Resource fork would) encoded as text-transmit safe Base64 (like dataURL) in HTML structure. Which is a lot like what I was talking about trying to create as an 'interchange' format (actually I was going for a custom XML schema), a text<->UI answer to what a 'script-only' 'stack' is to a regular stack, a well-spec'ed out standard that people could write importer/exporters for relatively easily. Another idea was maybe this could use something like Qt's QML as a UI mark-up, then users could reuse the data/UI layouts for like a PyQT based project (collaborating across scripting languages as one example use-case) and probably import layouts from QML Python projects too... QML is a lot though, maybe overkill... sorry... rambling away now lol
