Here's the proof of concept, and the sort of use-case I'm talking about:
https://livecodeshare.runrev.com/stack/977/Piano-Widget-Demo-1-3-6

That demo can work even if you don't have the Widget installed (and in fact that old demo is incompatible with the revised version and identifier string of the current piano widget), because there is a copy of the LCB compiled byte code module in the Stack 's [b]SCRIPT[/b] which can be decoded back into ram and then loaded into memory, ready to use without actually installing the widget module at all.

Similarly I have a stack that compiles full-color SVG Artwork into that draw-ready binary format that image controls can use, and it outputs them all as one big [b]script-only[/b] (text file) library stack that can be loaded fairly quickly and can render (54 color vector playing card) drawings into an image control one after the other at [b][i]blazing[/i][/b] speeds, because now those drawing datas are being stored in an array in RAM. Some stranger actually took the time to email me about how brilliant he thought that was, so I felt pretty good about that, lol.

[quote=richmond62 post_id=5234 time=1702803990 user_id=53]

1. Make sure that anything written in OXT (I mean OXT that is heavily dependent on LC 963) is openable by any other variety of xTalk: i.e. disable substacks.

I would argue this would be a very great mistake: I am not going to cut my legs off to compete in the Paralympics.
Substacks are a wonderful thing (dunno whether that's MetaCard or LC) that make a significant difference to what one can do with xTalk.
[/quote]
[quote=richmond62 post_id=5234 time=1702803990 user_id=53]
I wonder what are the advantages over storing resources "off screen" . . . none that I can see.
[/quote]
It depends a lot on [i]how[/i] they're stored off-screen and the engine that is storing and retrieving them, in the case of images are they being buffered into-memory and ready to render fast or not?

What I'm talking about is essentially the same thing as hiding an image on a card somewhere so that you can use it as an icon in a visible button on your card, but instead of having to go looking for that hidden button when I want to edit the pixels of that icon, I can go use a 'Resource Manger" which collects them all and puts them into a RSRC sub stack where I can easily edit, delete, or replace them from a list, a lot like the Icon/Object Libraries stack, but not just for Image objects... also for SVG Files (for use with 'drawing library') sounds samples, Polygons Points 'paths', SVG Paths (used all over the IDE in various widgets that you guys want to remove so badly). and custom data types too... and as proof of concept years ago in Piano Widget demo you can a store and load widget or library as encapsulated data, EVEN in a 'script-only' text 'stack' if encoded as Base64 (or ROT13 or similar).

There's quite a few advantages to having a dedicated 'Resource Manager' that I can imagine.
If I were to build such as stack, for one thing it would have conversion and EXPORT capabilities.

Here's an scenario:
I have a stack with lots of SVG Icon 'widgets' on various cards, and sub stacks and now I want to use them for a website about my stack, how can I export like 30 SVG Icons back to normal SVG files that I can use in a web page or edit in Inkscape or whatever? I could go through every object on the page and copy it's SVG Path string into a template SVG file, and then save each as an SVG, or I could use my resource manger stack to extract them all to files named after the controls name or custom names serialized numbered .svg files in just a few seconds vs. an hour or two. For one-bit line-art images it could store or export 'BPM' instead of only bing able to import those (which apparently LC converts to RGB which triples the data size). Now I want another set of these UI-Icons but as 1-bit images for some other project. This 'resource manger' would be capable of mass-rasterizing the SVG paths into pixel images too.

[quote=richmond62 post_id=5234 time=1702803990 user_id=53]
3. Save yourself an awful lot of bother and leave things as they are.
[/quote]
You guys are the ones who want to go backwards to the 90s/OOs (and some other people want to take it all the way back to the 1-bit or 16bit color days), with your desire to slim down by ditching LCB and widgets, with no-benefit in doing so that I can see, as SVG Paths are a LOT smaller than pixel images.

IMO the entire notion is just completely crazy, You ARE Going to break a lot of stacks that use them if you remove widgets.Personally I waited years for LCB to exist and then mature (partially). To me these things were the best things to happen with xTalk in a LONG time. Widgets give OXT a real object model bringing it a lot closer to real OOP (while still keeping it obfuscated away from any novice users) and with v9 wi/Foreign Function Interface brings it MUCH closer to being 'real' programming in-line with Python.

Really the whole push-back against these additions that seem to come from long-time members of the LC Community (not just you guys here) was just completely bizarre to me. I think there's a lot of curmudgenery in this community. Certainly there's a lot of strong opinions from all sides about what is pointless and what is worthwhile.

BTW, what 'widgets' besides 'Browser Widget' are 'broken on Linux"??? None that I'm aware of, my Piano Widget work great on ever Linux I've tried (and so does the Fluid Synth wrapper library (it's just not setup right in that .AppImage)

[quote=richmond62 post_id=5234 time=1702803990 user_id=53]
If you want to remove sub-stacks you will shaft OXT almost entirely.
[/quote]
I didn't say anything about removing sub-stacks, even if aI wanted to (which I don't) doing so would require rebuilding all of the engine(s) and would break thousands of existing stacks (so that would be pretty stupid)

I am interested in [b]importing AND exporting [/b] of content: pixel images, svg paths, sounds, scripts, card/page layout, etc. What I really want is an [b]Encapsulated, xTalk interchange file format[/b], as discussed by xTalk companies some 30+ years ago but never realized (and then made irrelevant a few years later by the advent of HTML/Web).
A lot has changed in those decades, and I think any design of such a standard encapsulated hypermedia format would look a lot more like HTML (again, I want the 'encapsulated' bit, unlike 99.9% of web pages).
If we treated like the standard it always should've been it could get to the point of having an 'official' RFC specification. If a handful of people could get WebMIDI to become a RFC and web standard (accept for with Apple Safari), in just 8 years time, then we could get 'XIFF' to be a standard too (XIML was already used, https://www.crunchbase.com/organization/ximl ). I would want to take into consideration the people who donated a lot of time into reverse engineering the original HC stack format. The output from those using that work (like HyperSim, StackSmith, HyperCardPreview) tend to be either JSON or XML based (AKA plain old universal ascii text data).

SC trivia: The Project file format includes a virtual resource fork within the data fork, where the program stores ICON, CLUT, XCMD, and other resources.

I asked Bill Appleton why he didn't just use the Resource Manager provided by Mac OS. He said he started to, but it's so generalized it just wasn't as performant as he wanted. So he wrote his own. :)

[quote=FourthWorld post_id=5278 time=1703010392 user_id=51]
I just put resources into a substack. I usually name it "RSRC" to distinguish it from user-facing stacks.

As for other xTalks that have substack, SuperCard, Toolbook, and Gain Momentum had them.

In SC the file was a "project" and each stack within it was a "window", but nomenclature and a small difference in the message path (SC does not treat the first window differently, as OXT does with main stack) aside, pretty much the same thing.
[/quote]

Thanks for the info Richard, I never could get into using SC's Project management setup, so I barely ever used it.
I do have a licence / copy of SC 4.7.3 (IIRC) somewhere (on a DVD-R backup).

"RSRC" Makes sense keeping the name like a 4-Char CODE.

I guess you could also consider HyperCard's /Start Using Stack "path:to:stack"' as sort of similar to 'sub-stacks', just stored in a separate file container, vs as MC/RR/LC embedding them into a single file. Although typically Dialog Boxes and Palettes and things sub-stacks are often used for, were embedded into stacks as external resources in the Resource Fork, a convenient feature of classic macOS I've often missed. I know > macOS X 10+ has NeXT bundles as an equivalent, but it just doesn't feel the same.

Since Apple has moved on from HFS to APFS, the decades deprecated resource forks are finally getting lost on Macs too, not just from mac-unfreindly zip utils or Windows FAT volumes. I've really noticed the data loss when trying to convert stacks on current Macs with APFS formatting vs. MacOS HFS+ volumes that still preserved them.

I just put resources into a substack. I usually name it "RSRC" to distinguish it from user-facing stacks.

As for other xTalks that have substack, SuperCard, Toolbook, and Gain Momentum had them.

In SC the file was a "project" and each stack within it was a "window", but nomenclature and a small difference in the message path (SC does not treat the first window differently, as OXT does with main stack) aside, pretty much the same thing.

[quote]I think OXT/LC are the only xTalk that support 'sub-stacks[/quote]

I think you are right.

So, it seems there are a number of ways you can go . . .

1. Make sure that anything written in OXT (I mean OXT that is heavily dependent on LC 963) is openable by any other variety of xTalk: i.e. disable substacks.

I would argue this would be a very great mistake: I am not going to cut my legs off to compete in the Paralympics.
Substacks are a wonderful thing (dunno whether that's MetaCard or LC) that make a significant difference to what one can do with xTalk.

2. Introduce your faux resource fork.

I wonder what are the advantages over storing resources "off screen" . . . none that I can see.

I wonder what are the advantages over storing resources in custom properties . . . none that I can see.

3. Save yourself an awful lot of bother and leave things as they are.

If you want to remove substacks you will shaft OXT almost entirely.

I think OXT/LC are the only xTalk that support 'sub-stacks, and but even with that there's no support for 'sub-stacks' in script-only stacks. Which is why I'm inclined to use text safe base64 encoding for resources (data URLs, as HyperSim does). But that is what I had in mind for storing them in a regular stack in OXT, I just planned to use a specific name for sub stack, Something obvious like 'RESOURCES OR 'RESFORK'' That a manager utility could import and export or manipulate in place the resources of a stack. There would be no enforcement or requirement and I would also make it also be able to scan all of the parts/controls of a stack/substacks for any other resources, but would look for this 'resfork' by default.

HC (HC Sim) and LC both allow you to easily iterate through 'parts' (Its a synonym of 'the controls' in LCS) of a card or stack.

I agree, I think a substack is probably best, - datagrids create extras in this way to store things.
You could also store it as a custom property on just about any object. You could even decide to make a hidden field and set as many custom properties to it as you'd like. As long as it's within the stack, and not some metadata file that has to be bundled along with it, then it'll survive web transfer - which I'm sure you know and I'm preaching to the converted, resource forks never did on classic MacOS.

Keep things simple: store your resources in a substack the end-user never sees if you feel it is necessary not to have them in your main stack.

So classic Mac OS had something called a Resource Fork, where chunks of data with 4-char type-codes could be stored along with a data which was in a separate data 'fork' of any file. The data fork is where you'd store the bulk of your data, the resource fork could be used for anything else, but it was often used for non-essential data such as a custom ICON, or low-res preview 'PICT' for a high resolution EPS file for example. Add-on code resources could also be stored along with a file in this way, the is exactly what XCMDs/XFCNs were, and also why your stack (usually) contained any add-ons it depended on. I'd like to emulate this feature (as part of an larger xTalk Interchange format idea). Of course we would have more OXT and web friendly resource types, 'WAV ', 'PNG ' or' GIFf', but also 'SVG ', 'WDGT'(widget?), or maybe types could be arbitrary?

I''d like some sort of standard system for xTalk that we could use similarly to encapsulate any sort of resource and embed them into our stacks (without having them be on the card hidden somewhere off-screen), perhaps in a sub-stack called 'Resources' or embedded in script as base64 special 'comment' or in a <Resources></Resources> and then have a Resource Manager to manage them (like the ResCopy XCMDs or ResEdit did). I've used base64 to embed binary resources into script-only stacks in the past and to include an on-the-fly loadable copy of a widget inside of its demo-stack's stack script. It takes no time at all these days to decode some small images or sound clips commonly found embedded in HC stacks, and some MetaCard/RevMedia old stacks too. I'd like to keep it to the most xTalk 'interchangeable' method if possible, probably Data URL format, which is a tag with some embedded base64 data.

I guess I'm calling a 'request for comments' on this idea.