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.