OpenXTalk Forums

It's been a while since I did anything with this:

https://openxtalk-org.github.io/OXT_Res ... epot_Repo/

Which is what should (hopefully) show up in the OXT DPE IDE's Extension Manager "Repo" tab, which I replace the never-functional "Store" tab with in OXT DPE.

This sort of site is easy to publish as a"GitHub Pages" site and super easy to update it from the GitDesktop.app.

The problem with it is that it's a Browser Widget that displays this 'Webstack" has to download the almost 30mb OXT Emscripten Engine .js if it's not already in the Browser Widget's cache before the Webstack runs. The stack then pulls in its data from a tab-delimited text list and pulls in some image files that are in the same GtHub Page site. It would be faster if "Webstack" could use the copy of the Emscripten Engine that's already comes with the IDE, BUT it can't do that due to the 'Cross-Origin' security limitations, the Engine JS has to originate from the same source site that the page it runs inside of is on.

It's slow to load that 30MB JS file, even on a fast internet connection, and requires Browser Widget to display the resource lister webstack, so I want to change it to NOT use Browser Widget, instead use a purely stack based lister. Maybe similar to Richard Gaskin's LiveNet stack. This has the advantages of not needing any browser widget or any sort of webpage HTML/JS stuff at all and therefore the 'Cross-Origin' issues go away.

Giuthub pages I think is great for this idea because GitHub will translate GitHub Markdown into HTML before it serve them as web pages. You can also use regular HTML with GitHub Pages, but markdown .md is easier to format simple text lists as sort of directory listings, and its a basic enough sub-set of HTML formatting that we can easily use it like: set the HTMLText of Fld "ReposList".

The Tab delimited list of available Resources is pulled into the repo browser stack like so:
put URL "https://openxtalk-org.github.io/OXT_Res ... o/list.tsv' into tTabbedList
Look at in browser: https://openxtalk-org.github.io/OXT_Res ... o/list.tsv

That list contains 'columns' such as ResourceType (one of Widget,Library,Stack,URL,etc.), Title, Author, Description, etc. and Identifier (which is used to form a URL for an associated image and the download filename). It's a tabbed delimited text list because that's super easy to use and display with a datagrid. I use a stack with datagrid for editing the list (and this stack also did Base64 encoding for the Widget's binaries but encoding should not be needed).

There was another list I planned called Repos.tsv with the idea being that this list could point to other people's repos on their own server(s) with their own resource List.tsv
In the Browser stack you could navigate from the Main Repo list to these other repo's list and display those resources. It would be like a network of shared stacks using a common list format to share OXT related resources. Maybe a bit like Gopher:// protocol For you kids out there Gopher was pre-1st Web Browser, card catalog kind of content browsing (https://en.wikipedia.org/wiki/Gopher_(protocol) )

I was thinking this could be a multi-use stack. Remove the Extension Repo ('Store") tab from Extension Manager, and building it into this multi-use Resource Browser/Manager. It could also be used to list any new releases for various OXT distributions as an updater tool, and could replace the 'Sample Stacks" stack too, maybe it could even list recent topics on the forums.

This list might have list items with a bread crumb trail like these:
OXT Main> Releases> OXTLite103MacOS.dmg
OXT Main> Community_Widgets> Universal_Slider_Widget
OXT Main> Community_Libraries> HIDAPI
OXT Main> Community_Stacks> ListFieldExample.oxtstack
OXT Main> Community_Repos> Pauls_Experimental_Stacks> CursorDemo.oxtstack
OXT Main> Tom's_Stuff> BugDemoX.mp4
And unlike some other methods, this browsing stack would be small and fast to load the list, it could cache the resource and preview image once downloaded, ask the user to overwrite if file on disk already exists with older an older version number.

I'm just wondering if anyone else will actually participate in this idea, the formulation of the listing system, and then host some of their own content with List.tsv 'repo' on a server somewhere?

Um: "OXT DPE": 'Deep Purple Entrails'?

Thicko is missing something here.

richmond62 wrote: ↑Thu May 09, 2024 6:31 pm Um: "OXT DPE": 'Deep Purple Entrails'?

Thicko is missing something here.

DPE = Don't Panic! Edition ... although I'd be happy for it to have some of what was inside Jon Lord.

I'm hoping that Tom is willing to adopt something like this common community package browser in OXT Lite too.
I still think OXT needs some sort of package manager. I just used the one I put in place to install a widget the other day because it was still quicker than sifting though all the many repos I have saved or forked on GitHub.

I never seem to be quite sure if I have the latest build of OXT Lite or not so my thinking is Tom would just need to update his List.tsv on his own site then this browser stack reads his list (if the browser stack user has his repo enabled) after the main one and then links to his new downloads would show up in this browser stack as a newly available items. Updating the list is as simple as editing text files, or a text export from the datagrid in the list editing stack.

Currently each item in a resource directory consists of simply the filename.whatever, a description.txt, and optional preview image.png and optional logo.svg (which for extensions/widgets the icons are extracted/copied from the extension module by the list editor).
You can see example of the files pulled in by the current Resource webstack in directories here:
https://github.com/OpenXTalk-org/OXT_Re ... /Libraries
and here:
https://github.com/OpenXTalk-org/OXT_Re ... cs/Widgets

I try to keep putting the latest release on the downloads section for oxt, and thanks to php redirects, if you use the download link (and for some reason don't use the one on the forum, but if you stumble on the 'downloads' section of the openxtalk site), you'll now end up at the right page regardless.

You can also check for updates to get the 'latest ad-hoc patches'. My updates stack just reads a listings file, so it knows what files to grab. Simple.
V1.04 is the latest version of OXT Lite.
If you use the updates, it'll take you to build 202405050927 (which is the last set of updates I made public).
(9:27 on the 5th of May, 2024) You'll know when any particular version is up to date, as it'll say "No updates available. You are already up to date".

You can also turn on auto-update notifications in the preferences too: I'm very against using github now as it's not suitable for my purposes. It's over complicated and does not allow a gallery view of stacks as default. I'm against it because Microsoft have owned it since 2018 - and Microsoft increasingly cannot put together a user-friendly UI. *but that's only my opinion*, although you just have to look at Office/365, Windows 11, Teams, Outlook... to see how I reached that conclusion.

Back on topic, the reason I've kept sample stacks in Mega, is because not only does it provide the storage I need without the 'feature creep' I don't need, but it also shows a gallery view - so I can put sample stacks in there with a preview (example) and have found this the most accessible way as it can be accessed by anyone with a semi-modern web browser.

Anyway, here's how I retrieve file listings online in my updates stack: That gives me the URL to read.
I then read that URL for update info: After a bit of post-processing, this essentially lists a relevant subdirectory - and inside that subdirectory is a file which is a list of all the updates to get... It repeats for the number of files in the listing (with a bit of error-catching thrown in) Then it's also got a bit of logic a bit further down to test if we got what we need: But you could incorporate that into any stack or live list of content, as you rightly say, without invoking any broken browser stuff.
Note: I did try using libURLDownloadToFile, but found it was unreliable and a headache because it could easily be broken with timeout errors.

All the script for my "updater" stack is in card 1 of it. You can easily get to it if you check for updates, then open the 'Application Browser', and examine the script of card 1 of the 'updater' stack. I've commented it as I put it together, so hopefully it makes sense what it's doing. It does get a bit obfusicated further down where it starts putting the updater script syntax together for various platforms, but you shouldn't need that bit.

tperry2x wrote: ↑Thu May 09, 2024 7:54 pm I try to keep putting the latest release on the downloads page for oxt, and thanks to php redirects, if you use the download link (NOT on the forum, but on the openxtalk site), you'll end up at the right page.

You can also check for updates to get the 'latest ad-hoc patches'. My updates stack just reads a listings file, so it knows what files to grab. Simple.

Yes that's what I like about this, K,I.S.S. simple format, really only need a text editor to update.

I'm proposing to basically just proposing to use a format for such resource listings, use same column names / parameters to describe a OXT resource downloads form arbitrary servers (or from your own local drive's directory).

I want use simple system like this as a common 'protocol' for various IDE things, replacing Updaters, Extension 'Store', Example Stacks, and for any sort of xTalk related content really. I was thinking it could announcement resources with a description blurb and a URL link, like for when other xTalks (such as LC or HyperNext, HyperSim, etc. receive updates or something. These resource list could be wrapped as 'HTMLText' and made accessible from a web browser to download content too, but having it directly accessible in the IDE is the most important thing here. Stacks and Extension modules can both be loaded from a variable in memory, so that should allow for try-before-you-'buy' sort of test prior to saving the file. (Richard's LiveNet does that).

I want to use such a mechanism to replace the 'sample stacks' which currently still points to LC share site (which can be rather slow to list files). That stack allowed people with LC account to share stacks with a pict and description to their share server directly, this system would be more like a package manager that reads a lists of repos, and then later reads the listing files on each those repos as needed.

The user can have their own user repo list, so that they could add in their own private Repos stored on disk or local server.

I'm very against using github now as it's not suitable for my purpose

Perhaps I'm making my description of the system more confusing than need be. There would be absolutely no reason that anyone would need to use GitHub for this, you would be able to use any sever or local directory to host your listing / resources, you would be able to use a shared folder on Google Drive or similar cloud storage, they're just simple files, text, png, etc.
I just like Github for several reasons (one of them being of course being version control) and it hasn't changed much at all since Microsoft took it over. In some cases and the case of that resource manager page, I'm basically only using GitHub Pages as a free web site host. But with this simple stack-only browser method the files can be on any cloud file server or even pulled from a directory on local file storage (which is what my list editor does, making relative-URLs to the files that later get turned into full-URLs to download)

Note: I did try using libURLDownloadToFile, but found it was unreliable and a headache because it could easily be broken with timeout errors.

I did too, that's why I wound up building it in a webpage and then using the exposed JavaScript 'Handlers' (the same way that 'Extension 'Store' was originally setup) to communicate between the IDE and the webpage inside the Browser Widget. But I sort of knew that was overkill when I did it. I just haven't gotten around to building something better to replace it.

GitHub's web UI may not offer gallery view for screen shots (a Stack version could be scripted to display as a pict grid ), but GH Web UI does recognize many common file formats and displays them accordingly. For example the tabbed delimited data is displayed as a table in the GH web UI:
https://github.com/OpenXTalk-org/OXT_Re ... sRepos.tsv

The first row in that RepoList file is a list that points to directory on my Laptop that contains the offline version of the repo.
~/My OpenXtalk/ResList.tsv

How does your updater know what filenames to look for, based on what? How would it know how the next version would be named? This question is why I want to set specific conventions for naming for the repos listings like 'RepoList.tsv' which goes into the root directory of a repo, A RepoList just points to directories wherever they may be. The List.tsv is a at the root level of each repo and contains info about each of the files along with either a relative URL or full URL pointing to the resource to download.

I don't like the idea of demo stacks that I shared being hosted somewhere where I can't update them myself. That is the big problem as I see it with having a centralized host for all of the content as you have it here: https://mega.nz/folder/4O9zVLbQ#8LrRAQdF69cr1dghEfhIXg

OpenXTalkPaul wrote: ↑Thu May 09, 2024 9:56 pm How does your updater know what filenames to look for, based on what? How would it know how the next version would be named?

Quite simple really - it compares the current version string, looks against that to see what updates are available.
If I want to bump the version up, then the updater just modifies the version string and build number as needed. It does all that automatically, depending on the content of the 'updatepackage' folder. (I have one folder to change things in and read, rather than worrying about reading property information of individual files multiple times).

OpenXTalkPaul wrote: ↑Thu May 09, 2024 9:56 pm This question is why I want to set specific conventions for naming for the repos listings like 'RepoList.tsv' which goes into the root directory of a repo, A RepoList just points to directories wherever they may be. The List.tsv is a at the root level of each repo and contains info about each of the files along with either a relative URL or full URL pointing to the resource to download.

Sorry, I don't understand what you mean by Repo. Do you mean a github repo, or do you mean a tsv file that is already resident on your computer?
Having loads of tsv files seems like a lot of over complication, as all it will take is something to not be referenced correctly, or some typo, in one of those multiple tsv files for download errors to occur. But that's only my take on it. Up to you of course how you want to make your version work.

OpenXTalkPaul wrote: ↑Thu May 09, 2024 10:12 pm I don't like the idea of demo stacks that I shared being hosted somewhere where I can't update them myself. That is the big problem as I see it with having a centralized host for all of the content as you have it here: https://mega.nz/folder/4O9zVLbQ#8LrRAQdF69cr1dghEfhIXg

If you don't want them to be added there, I can remove them (I did ask first), but there's no harm with you ALSO hosting them somewhere else in your OXT deluxe version. My 'Lite' version is intended as only bug fixing and minimal changes, but feel free to 'go to town' of course on your version, that's entirely up to you.

tperry2x wrote: ↑Fri May 10, 2024 10:31 am

OpenXTalkPaul wrote: ↑Thu May 09, 2024 10:12 pm I don't like the idea of demo stacks that I shared being hosted somewhere where I can't update them myself. That is the big problem as I see it with having a centralized host for all of the content as you have it here: https://mega.nz/folder/4O9zVLbQ#8LrRAQdF69cr1dghEfhIXg

If you don't want them to be added there, I can remove them (I did ask first), but there's no harm with you ALSO hosting them somewhere else in your OXT deluxe version. My 'Lite' version is intended as only bug fixing and minimal changes, but feel free to 'go to town' of course on your version, that's entirely up to you.

No no it's fine to share them that's why I put them out in public... I just want to be able to update them whenever I add something new to those demo stacks, but then you'll still have the old version on your server. That's why I'd like to have a some sort of distributed/decentralized method for sharing resources that could be used by either OXT edition, and for the IDE users to also be able to have their own private package/stack repo on local storage too. My build could read in your shared resources, and yours could read in my list of stacks, widgets, libraries, URLs, code snippets, etc. A distributed network of community resources that could be downloaded to memory, tried-out, and installed or removed directly within the IDE (it should be a functional system, even on an old v7 build running on an $10 SoC board).

OpenXTalkPaul wrote: ↑Sat May 11, 2024 2:59 am No no it's fine to share them that's why I put them out in public...

Okay, thank you for clarifying. I didn't want to offend or anything, so glad I haven't.

OpenXTalkPaul wrote: ↑Sat May 11, 2024 2:59 am I just want to be able to update them whenever I add something new to those demo stacks, but then you'll still have the old version on your server.

That's true, although I have plenty of examples of that- with v1,v2,v3 etc - more so anyone can follow along with changes, as example stacks generally get more complicated as the versions increase. Sometimes a user only wants the bare minimum functionality that is in v1 to adapt, rather than the final version that they might have to sift through extra changes to find that same functionality. (I've probably not made that clear).

OpenXTalkPaul wrote: ↑Sat May 11, 2024 2:59 am That's why I'd like to have a some sort of distributed/decentralized method for sharing resources that could be used by either OXT edition, and for the IDE users to also be able to have their own private package/stack repo on local storage too.

I like the idea of that, so if I had an example stack that did that - I'd gladly add it to the help menu of OXT lite (under 'Lessons').

OpenXTalkPaul wrote: ↑Sat May 11, 2024 2:59 am My build could read in your shared resources, and yours could read in my list of stacks, widgets, libraries, URLs, code snippets, etc. A distributed network of community resources that could be downloaded to memory, tried-out, and installed or removed directly within the IDE...

Again, sounds a very good idea - like an 'addons manager'

OpenXTalkPaul wrote: ↑Sat May 11, 2024 2:59 am (it should be a functional system, even on an old v7 build running on an $10 SoC board).

That would be good, but didn't v7 have no widgets (or no 'widgets' as they currently are understood)?
I thought you were really in favour of keeping widgets, as when I was contemplating the puzzle of reading them in my revised inspector (which I'm still drawing a blank on btw), you mentioned it was a deal breaker to not have them. I don't mind either way to be honest, but I think if we are going to support them - then great, could you piece together a stack for me that retrieves widget properties from...say, the "segmented control" widget? (example using the old inspector) How do I retrieve this stuff through script?

I'm still in favour of simplfying widgets "for the rest of us" - so if a widget was simply a folder in the tools menu that you can drag off like any other tool to add to your stack, but if you want to edit that widget - you can poke around in the widget folder, in which you'll find the light/dark icon for the widget - the oxtscript file that does it's magic, and any other supporting files that it needs. It could also contain a 'widget.index' file (a text file) which declares all the properties it can have set, a list of all the files it references, and a description of what the widget is/does. This is also something we can read through script easily to get/set properties of.

Did you see that I took what was now a £20 HP chromebook and replaced the system with AntiX linux (removed ChromeOS completely) - this ran OXT Lite 1.04 brilliantly (although I was frustrated by the lack of screen space, and I love SOC boards for the education considerations), but I assume the issue on cheap SOC boards would be they might lack the video memory to drive a larger resolution.
Anyway, I'm wandering again.
I totally forgot that there was a 'Sample Stacks' tucked away in the extensions manager. Not that it does anything on Linux with a broken browser widget. (video here)

tperry2x wrote: ↑Sat May 11, 2024 6:02 am

OpenXTalkPaul wrote: ↑Sat May 11, 2024 2:59 am I just want to be able to update them whenever I add something new to those demo stacks, but then you'll still have the old version on your server.

That's true, although I have plenty of examples of that- with v1,v2,v3 etc - more so anyone can follow along with changes, as example stacks generally get more complicated as the versions increase. Sometimes a user only wants the bare minimum functionality that is in v1 to adapt, rather than the final version that they might have to sift through extra changes to find that same functionality. (I've probably not made that clear).

I agree about some people are just looking for the most basic example in a demo stack, I often look for such a stack to quickly get the idea (or remember the idea if haven't used it in a while) of how to use one particular syntax and nothing more. Although I think the examples given in the Dictionary entree are supposed to be that exact most basic thing, we know many examples are missing or maybe not very clear.
But I didn't mean for this to be about what sort of content you want to store in your stack repository.

What I'm thinking of is a system like the one used by KODI Media Center, formerly X-Box Media Center, but obviously not using python). I don't know if you're familiar with Kodi but it's been a quite popular app for sort-of-DIY media console UI for many years, and there are standalone Linux Distros have been built around it like LibreELEC (https://libreelec.tv/downloads/)

I already have the working experiments in place for extensions/widgets as that webstack, and a stack that helps generate and outputs the lists.tsv. it could be expanded to handle any sort of content links such as sample stacks. But as I said I'm going to rebuild the front-end to be a simple stack, and so I wanted to discuss it before going any further on that sub-project. In particular what sort of data about a shared resource should be included, or can be optionally included, etc. in the list of resources.
I want to keep it simple:
A single Repo List will be used by a stack UI in the IDE, each line of the file will be: repoName & tab & repoURL.
This stack will replace the Extension Manager's 'Sample Stacks, Snippets" (both of those have been empty, I guess place-holders, tabs on any platform not just Linux), and the formly non-functional "Store" tab, and also replace the 'revOnline"'s "sample stacks" stacks.
Resource list stored on the repo's server at the root of where your repo begins.
It will be simple tabbed delimited text (.tsv) no JSON XML or any of that mess.
Each list entry for a resource will at minimum include a relative URL pointing to a resource, any other info for the resource would be optional.
Optional info would be:
Name (could be the same as the filename), Short Description, Version (needed for extensions), Identifier (needed for extensions), Author, a URL related to a resource.
The along with the file you can optionally include additional files, something like:
filename.whatever
filename.whatever.desciption.txt
filename.whatever.screen.jpg , and perhaps also filename.whatever.screen2.jpg ...
filename.whatever.logo.svg
These files would be used for display in the UI when a resource is selected, a lot like the 'revOnline' UI.

Again, sounds a very good idea - like an 'addons manager'

Yes, like a Addon manager of sorts, but also for sharing demo stacks, code snippets, IDE releases, maybe also URL links to various other resources such as Webstack that's online somewhere (it might even be a stack built with HyperSimulator ) or perhaps even some website with lots of useful assets ( 'the noun project' SVG Icons site for example).

That would be good, but didn't v7 have no widgets (or no 'widgets' as they currently are understood)?
I thought you were really in favour of keeping widgets, as when I was contemplating the puzzle of reading them in my revised inspector (which I'm still drawing a blank on btw), you mentioned it was a deal breaker to not have them. I don't mind either way to be honest, but I think if we are going to support them - then great,

What I meant by 'deal breaker' is that without Extension support OpenXTalk would be far less interesting to me, and at that point I think I might as well start putting my efforts into working on some other FOSS xTalk, like a fork of StackSmith or ViperCard, something else like that. So I do want to keep supporting Extensions as much as possible.

However, I did use xTalk(s) and similar long before Extensions existed and I think I can be pretty pragmatic in working with what's available. I mean I did get real-time MIDI output working using several different methods before the Extensions were introduced, but with Extensions I now have much better method(s)!

I'd ABSOLUTELY LOVE IT if someone could build and release a version of the Engine based on v8 (widgets) or better v9 (widgets and foreign functions) that ran on RasberryPi (not to mention FreeBSD, SnowLeo, PowerPC CPUs, etc.), but there was only ever v6 and v7 based builds compiled for RPi (Raspbian Linux ARM), so that's what's available to work with on that platform, which means no extensions (but maybe externals). If xBrowser/revBrowser worked, which were Externals NOT extensions, on those builds that means you could still use JavaScript libraries and render Web content, SVG graphics, etc. The point is it's still worth having an xTalk engine on RPi, IMO.

I think I've always been in favor of pragamatic and holistic approach for the goal of a Free Open-Source xTalk.
At one point I even did do some exploring the idea of 'OXT Retro' Edition of the IDE that ran on Snow Leopard (which can run ups to the v8 Engine).

could you piece together a stack for me that retrieves widget properties from...say, the "segmented control" widget? (example using the old inspector)
How do I retrieve this stuff through script?

OK yes I'll work on that, and also I still need to post that text styling palette I made for you to check out.

I'm still in favour of simplfying widgets "for the rest of us" - so if a widget was simply a folder in the tools menu that you can drag off like any other tool to add to your stack, but if you want to edit that widget - you can poke around in the widget folder, in which you'll find the light/dark icon for the widget - the oxtscript file that does it's magic, and any other supporting files that it needs. It could also contain a 'widget.index' file (a text file) which declares all the properties it can have set, a list of all the files it references, and a description of what the widget is/does. This is also something we can read through script easily to get/set properties of.

So like the 'classic controls' or custom grouped controls, but in a way that users drag-drop to add them like with Widgets, and edit their custom properties using Prop Inspector?
My thinking on 'classic controls' and custom control groups as 'widgets' is that they are already essentially the same sort thing. But I was thinking for storing customized controls, we already have revObjectLibrary stack(s), and IMO thart should be turned into a palette that's more easily accessible when working on stacks. We have Drag-Drop added to that stack already.

Did you see that I took what was now a £20 HP chromebook and replaced the system with AntiX linux (removed ChromeOS completely) - this ran OXT Lite 1.04 brilliantly (although I was frustrated by the lack of screen space, and I love SOC boards for the education considerations), but I assume the issue on cheap SOC boards would be they might lack the video memory to drive a larger resolution.

No I missed that, that's awesome!
SoC boards are great for budget restricted Edu, and for hobbyists tinkerers on a budget as well.
I'm pretty sure there's SoC boards that support 4K resolution screens now and I also thought I had a v2 RPi running on at least an HDTV at 1080p (on 0.5v of electricity provided by USB).

It was my son's old ASUS sub-notebook (Chromebook-like) thing that I was experimenting with Elemental OS on, replacing Win 10 that it came with, my OXT App Image ran on it, but not with the correct UI theme and of course the Browser Widget problems, although Browser Widget did 'sort of' worked sometimes). My main takeaway at the time was that you could run an up to date lightweight Linux OS (and a rather macOS-like one at that) and the v9.x OXT engine reasonably well on very limited hardware (some version of low power-Intel Atom CPU I think with 32mb NAND 8GB ram).

Back on topic...

I believe I saw some advertisement that LC was going to add some sort of "'Script Based Widgets" or something to that effect but I haven't been keeping track of their progress so I don't know anything about how they've handled this similar concept to what you're getting at.
What I think OXT should do as far as 'script-based widgets' (for lack of a better terminology) is basically turn the 'Object Libraries" into a palette and then maybe use the same systems that are in place for Extension Builder Widgets and Libraries (which can already be Extension Builder or Script Based) as a package management format for those saved custom objects too. Also we could perhaps take a look at what was done with 'DropTools', and system promoted by "Sons of Thunder" pre-Extension Builder that was (is?) open to 3rd party development. https://droptools.sonsothunder.com/index.irev

I'm kind of linking this post with the other one, as they are both about extensions / stacks and resource management in a way.
As in how do we get the properties of widgets.
I had a look at that sons of thunder site. They've got some good stuff on there.
Specifically:
https://droptools.sonsothunder.com/prod ... ts-cp.irev

This table is exactly what I'm talking about. How do I find the equivalent of that information for [any] widget? I have been trying in vain, and have got as far as reading the keys, but no luck actually getting / setting the properties.

Edit: Think we are there now, with a working method:
viewtopic.php?p=8688#p8688

Properties and value ranges for widgets is largely beeing sorted out in that other thread, so I'm going to talk about packaging management here mostly (or try to).

Yes, there's some good stuff on Sons of Thunder site, but DropTools 'widget' system is broken, you can open most of the freebie 'widget' stacks though.

So how could we similarly implement 'stack/groups-of-classic-controls' based widgets?

Part of my reasoning for why in the past I've brought up the idea of creating some sort of xTalk UI XML mark-up library, like to go along with 'script-only'' stacks but for card/controls layout and properties. Perhaps this UI mark-up would be able to be appended on to the end of a script only stack to form a script-only widget? Maybe it could also use the same property meta tags currently only being used for Extension Widgets. I'm just spit-ballin' here.

I rather like the simplicity of revObject 'scrapbook' libraries, but that stack could be MUCH much better, for one thing I want to be able to rename entries after I've saved them to a library. it would be nice to be able to reorder that list too. The preview snapshots it generates when you save some objects look bad like they're in 'light' mode when using macOS's darkMode.

I also think moving that out into its own stack, separate from the revIcons libraries viewer, and making it a palette, I think would have me using that a lot more. I've already added drag-drop to place to it (though it's a little visually off, could use work) which made that stack more useful IMO.

If revObjects Library's allowed for some metadata, specifying info about a grouped-objects control's custom properties (and maybe allow to use PI editors on the placed instances?), then they would be a bit more like stack-based 'Widgets' right?

So I just took a peek at a 'script-only widget' shared elsewhere, and it looks a LOT like what I imagined it would be.

It's using the same sort of metadata found in our XTension Builder widgets, and the same sort of in-line documentation in revDocsParser format comment blocks. These use setProp and getProp script handlers for properties. Otherwise the code is setup similarly, sans Builder language, and using 'classic controls' to build its AI, objects must be created on the fly. And it also looks like you could edit the thing's properties in their (v10) Prop Inspector, because there's the same property defining metadata.

It seems underneath, this is not really a new concept. I think I would much rather have that XML UI markup so that I don't even need to write any scripts that create styled 'classic objects' on the fly, and instead have a library that does that part for me based on that markup I pass to it. With such as system I could then make a basic 'widget' (basic as in like a scripted search field) just using a chunk of XML markup.