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).