July 29th 2022 (one year since last official community release)
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
July 29th 2022 (one year since last official community release)
We are now exactly at one year since last official community release (LCC 9.6.3)
In honor of this marker (and instead of a full multi-platform release, more on that below), I've created a GitHub pages website that anyone with a modern web browser can use to play around with the OpenXTalk Emscripten Engine.
Try it out here:
https://openxtalk-org.github.io/OpenXTalk-Playground/
Source files here:
https://github.com/OpenXTalk-org/OpenXTalk-Playground
The playground app was/is 'built' as web app directly from my working OXT IDE which have been / are being modified, and then dumped into a GitHub Repo with GitHub 'Pages' turned on.
This is the result of taking my first 'deep dive' into the Emscripten engine, promted by the need to De/Rebrand the thing (which was pretty simple to do). I also un-minified the Engine's JS to make it more human to readable, but the 'prettified' version is over 50MBs! I wonder if we can't gain load speed by breaking it into smaller chunks and then loading it asynchronously into the webpage? Then we could perhaps optimize it or otherwise modify the bits and pieces along the way?
Anyway there's a few demos in there of manipulating the .outerHTML of the engine's host web page from xTalk.
And using 'do tMyScript as javaScript' to call HTML5 APIs to create a (non-rev)'speak' command (try say "Hello World"). There's facilities to make testing out the (default included) syntax much easier, you can type at the 'output' console area under the Emscripten mainStack window in the web page (where you can copy/paste like normal) and then click one of the buttons in the stack to transfer-in to the app the text, execute that text as either xTalkScript or javaScript or just transfer data between the web and your web app relatively easily. The 'output' console is also the log and is where the message box output comes out when you use 'put' without a target container, and I plan to add more to that, such as event listeners. There could be a working 'AnswerFile' that uses the HTML5 FileManager API and 'data URLs' (which are URL's with base64 encoded data streams attached). Modern web browsers, combined with HTML5, and tools like llvm, WebASM, Emscripten, have evolved into, well... basically they ARE app engines nowadays!
I find it very interesting that the engine actually can open multiple stacks / substacks and they load into there own canvas areas within the web page (which is effectively your 'screen' as far as the engine is concerned). And you can, by default create scripted buttons from scripts. I imagine we can add-in some of the IDE to have some mobile / web version of the IDE (in fact that was eluded to in an LC blog post sometime around 2016).
I think it would be interesting experiment to try to wrap one of these 'web apps' in a desktop JS app wrapper engine. We can even make some deploy options in the HTML5 tab of the Standalone Builder stack, where you could maybe have different loader pages to use, or add some JS script libraries to the builds.
I see an enormous amount of untapped potential in the HTML5 engine. There's no reason that we can't load other WebASM compiled things to use to controlled from our stacks. In fact that's exactly how I plan to implement PlaySentence Musical Performance strings in my web stacks, there's some extremely cool sound synthesizers, virtual sound modules and such that run on and can be controlled with JS!
In honor of this marker (and instead of a full multi-platform release, more on that below), I've created a GitHub pages website that anyone with a modern web browser can use to play around with the OpenXTalk Emscripten Engine.
Try it out here:
https://openxtalk-org.github.io/OpenXTalk-Playground/
Source files here:
https://github.com/OpenXTalk-org/OpenXTalk-Playground
The playground app was/is 'built' as web app directly from my working OXT IDE which have been / are being modified, and then dumped into a GitHub Repo with GitHub 'Pages' turned on.
This is the result of taking my first 'deep dive' into the Emscripten engine, promted by the need to De/Rebrand the thing (which was pretty simple to do). I also un-minified the Engine's JS to make it more human to readable, but the 'prettified' version is over 50MBs! I wonder if we can't gain load speed by breaking it into smaller chunks and then loading it asynchronously into the webpage? Then we could perhaps optimize it or otherwise modify the bits and pieces along the way?
Anyway there's a few demos in there of manipulating the .outerHTML of the engine's host web page from xTalk.
And using 'do tMyScript as javaScript' to call HTML5 APIs to create a (non-rev)'speak' command (try say "Hello World"). There's facilities to make testing out the (default included) syntax much easier, you can type at the 'output' console area under the Emscripten mainStack window in the web page (where you can copy/paste like normal) and then click one of the buttons in the stack to transfer-in to the app the text, execute that text as either xTalkScript or javaScript or just transfer data between the web and your web app relatively easily. The 'output' console is also the log and is where the message box output comes out when you use 'put' without a target container, and I plan to add more to that, such as event listeners. There could be a working 'AnswerFile' that uses the HTML5 FileManager API and 'data URLs' (which are URL's with base64 encoded data streams attached). Modern web browsers, combined with HTML5, and tools like llvm, WebASM, Emscripten, have evolved into, well... basically they ARE app engines nowadays!
I find it very interesting that the engine actually can open multiple stacks / substacks and they load into there own canvas areas within the web page (which is effectively your 'screen' as far as the engine is concerned). And you can, by default create scripted buttons from scripts. I imagine we can add-in some of the IDE to have some mobile / web version of the IDE (in fact that was eluded to in an LC blog post sometime around 2016).
I think it would be interesting experiment to try to wrap one of these 'web apps' in a desktop JS app wrapper engine. We can even make some deploy options in the HTML5 tab of the Standalone Builder stack, where you could maybe have different loader pages to use, or add some JS script libraries to the builds.
I see an enormous amount of untapped potential in the HTML5 engine. There's no reason that we can't load other WebASM compiled things to use to controlled from our stacks. In fact that's exactly how I plan to implement PlaySentence Musical Performance strings in my web stacks, there's some extremely cool sound synthesizers, virtual sound modules and such that run on and can be controlled with JS!
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
Also of interest is the 'HTML5 'Native' button widget, which creates itself as a canvas layer on top of the main Stack's canvas, if this could be modified to add an element ID, then I suppose we could control that Canvas contents from JS?
I'm certainly going to be starting a 'HTML5 Tools' library of general useful things for your web builds.
I already know the basics, how to Export/Import Text,Images and SVG Graphics, and manipulate elements in the outer web page, add download link... etc.
I think we should be able to dynamically load JS libraries into the web page from CDN / JS package manager URL into our page and then be able to call those methods from JS via xTalk do scripts and vice versa calling xTalkScript from JS with the stack's javaScriptHandlers property (which get exposed to JS by the xTalk engine, they're 'exported symbols'). Basically your web apps main-stack could just be a menubar that communicate with external libraries, even for your user interface (complete with some cool nice CSS animation effects)! Load up / appended some HXML and xTalk style _Hyperscript, inserted into your page markup on-the-fly! Lots of possibilities!
I'm certainly going to be starting a 'HTML5 Tools' library of general useful things for your web builds.
I already know the basics, how to Export/Import Text,Images and SVG Graphics, and manipulate elements in the outer web page, add download link... etc.
I think we should be able to dynamically load JS libraries into the web page from CDN / JS package manager URL into our page and then be able to call those methods from JS via xTalk do scripts and vice versa calling xTalkScript from JS with the stack's javaScriptHandlers property (which get exposed to JS by the xTalk engine, they're 'exported symbols'). Basically your web apps main-stack could just be a menubar that communicate with external libraries, even for your user interface (complete with some cool nice CSS animation effects)! Load up / appended some HXML and xTalk style _Hyperscript, inserted into your page markup on-the-fly! Lots of possibilities!
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
Fields
-
and?
- -
Well, the Close button works . . .
- -
That is impressive!
-
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
OK
-
Now . . .
How do I start a new stack, drag objects onto it, edit the scripts of each object?
OK, OK; perhaps I am being cruel considering the amount of work you have already done.
https://richmondmathewson.owlstown.net/
- overclockedmind
- Posts: 300
- Joined: Sat Apr 30, 2022 9:05 pm
- Location: Midwest US
- Contact:
Re: July 29th 2022 (one year since last official community release)
I think that's some pretty awesome stuff, definitely enough to remind us of how things once were (and quite a bit of new hotness to boot.) Also the idea of pre-built "stuff" that we could say "do widget.js as JavaScript" being sort of an "#include <stdio.h>" in C (which pretty much is the gamut of my C knowledge or I'd be helping wayyy more, LOL.)
What skillsets, language knowledges, etc does one need to really get "up in" this thing? I may just learn it, I have been waffling between Java and some variant of C for ages.
Are we going to have an app still with the de-branded layout (the IDE?) Thank you for every one of the fixes that everyone's made.
It's driving me nuts that I'm just knowledgeable enough to almost, ALMOST build it just from the directions.
What skillsets, language knowledges, etc does one need to really get "up in" this thing? I may just learn it, I have been waffling between Java and some variant of C for ages.
Are we going to have an app still with the de-branded layout (the IDE?) Thank you for every one of the fixes that everyone's made.
It's driving me nuts that I'm just knowledgeable enough to almost, ALMOST build it just from the directions.
MBA (Early 2015, 8GB/512G SSD, Monterey 12.7.2)
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
This is where I am having a problem as . . .Are we going to have an app still with the de-branded layout (the IDE?)
I really wish I had the know-how and the time to actively contribute; all I can do is promise
that as soon a dephlogisticated IDE becomes available I will start a series of "hold-my-hand"
simple programming projects over here.
https://richmondmathewson.owlstown.net/
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
I pushed an update to the playground demos this morning. There's now a working function to 'export' SVG Path Strings (as used by various widgets) to the HTML DOM (the trick here is that SVG has it's own name-space and so slightly different JS needed to be used). I want to add some HTML5 FileManager API stuff but those won't work on all browsers (certain mobile browsers). But there's also the add-download-link-to-HTML-DOM method for creating file out put (see the text save demo, but could do any sort of mime/filetype).
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
Is that a fact?
Are we going to have an app still with the de-branded layout (the IDE?)
https://richmondmathewson.owlstown.net/
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
Currently I'm using this to do tests even from my iPad (or even from Cel Phone when my wife drags me out to the store with here, lol) to see what can be done with just the default Emscripten engine as it was inherited, without additional stacks added to the deploy. Some quick tests in the playground (some scripts to try should be in fields already), shows that you can indeed 'create btn myButton;set the script of btn myButton to "on mouseUp;answer hello; end mouseUp;" and it does in fact create a working button on-the-fly. I'm pretty sure we could add-in more pieces of the IDE, there is a template folder that HTML5 standalone builder handler uses where you can add additional files to your deployments, there can be also a secondary _auxillary_files (iirc) folder where your xtalk script/builder libraries/widgets, images, sounds, and any other resources can get included. I plan to do some tests with included (revTools replacement stack) oxtTools sometime this week.richmond62 wrote: ↑Sat Jul 30, 2022 8:59 am SShot 2022-07-30 at 11.56.32.png
-
OK
-
Now . . .
How do I start a new stack, drag objects onto it, edit the scripts of each object?
OK, OK; perhaps I am being cruel considering the amount of work you have already done.
I think if we might even be able to 'send in' GUI/Binary stacks, load them into memory, Base64 decoded or whatnot from URL source=data: (data URLs), and similarly save out newly created stacks to your local device storage.
That substack was really just an area were I could put in different widgets or UI controls and see how they work in the web engine. The classic 'tabs' control does not render correctly (better to use the newer tabs widget I think). I just left that SVG widget with 'star' in there for now. Obviously we don't get any built in window management as normally provided compliments an operating system, so we will need to add our own window titlebars/move/close-boxes, window minimizations, and any of that sort of thing from scratch if we want those things.
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
YES! In fact this current dive into the Emscripten Engine is a result of needing to mess around / modify it in order to remove the commercial branding that was attached (which was really just two logos SVGs). I keeped in the little "download this Web Stack") button/function which, if you unzip that resulting standalone.zip file, you should have in one of those folders a copy of the actual stack (renamed), that you can load into the IDE. OR you could just download the OpenXTalkPlayground.oxtstack file (rename it with .livecode for opening in LCC) from the GitHub link (see first post).richmond62 wrote: ↑Mon Aug 01, 2022 8:14 pm Is that a fact?
Are we going to have an app still with the de-branded layout (the IDE?)
Anyway the playground is built from a base of these files I'm modified, deploying from OXT IDE the way you see it, no commercial co. logos. I'm just considering if anything else, small things, could be added in to make it a littler nicer to start out with, something like adding some event handlers to the .outerHTML, I think before I'd consider this part ready.
Some of this is just brainstorming and researching modern JavaScript (because I haven't used all that much JavaScript not in many years, and some of that was for Adobe scripting or VDP Printing, not much to do with web stuff) and HTML5 APIs as support varies across different browsers, then trying XT & JS code snippets in the "playground' to see what possibilities are readily available (and across the different browsers).
Currently I'd like to get something working to dynamically load JS scripts into our page DOM, so that we can load up some JS library just by pasting in a URL for the lib into a field and clicking a button, preferably with a callback to our XTalk to let us know when the JS <script> has finished being loaded so we can know when we can call it's functions (with 'do myJS as javascript').
Yes, this would be a bit like C #include for XT+JS, but better in that we can dynamically load a library only when we actually need to use it.
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
This reminds me that I still have to put those pre-built binaries (that required to build from source) up so people can download them. I wouldn't sweat failing at building engine(s) from source, the existing instructions aren't that great, and the Windows OS build instructions are only as good as it is because Trevor DeVore took some time to write better/updated instructions some time around 2017.overclockedmind wrote: ↑Mon Aug 01, 2022 4:27 am It's driving me nuts that I'm just knowledgeable enough to almost, ALMOST build it just from the directions.
The Emscripten Engine however is one big super-phat JavaScript.js library (weighting in a whopping 59MB, or 29MB minified), but parts of that js might be precompiled byte-code, I'm not sure.overclockedmind wrote: ↑Mon Aug 01, 2022 4:27 am What skillsets, language knowledges, etc does one need to really get "up in" this thing? I may just learn it, I have been waffling between Java and some variant of C for ages.
Now I know some people considered 29MB (and then additionally any stacks /resources data you add in), to be a lot for a web page, but most people stream probably at least that much from YouTube, plus stream a commercial or two, just to listen to some song, so I don't think that 29mb is so much of a deal breaker these days.
I was just reading about running Python bottled up to run entirely client-side in browser. That requires about 12MB initially and then if you add in any packages to do anything useful (and FYI, not all Python packages will work in-browser), you're going to get a larger deploy with that too, so I think this Emscripten engine is fairly competitive in that regards and our engine here comes packed with GUI and other useful stuff from the start and stays in your cache so you don't have to keep downloading when you go to a different web stack!
- overclockedmind
- Posts: 300
- Joined: Sat Apr 30, 2022 9:05 pm
- Location: Midwest US
- Contact:
Re: July 29th 2022 (one year since last official community release)
Yes, we're looking for those. If you build those, and more goes in afterward, hey, that's cool. But we want to be unhitched from the LiveCode "wagon."OpenXTalkPaul wrote: ↑Mon Aug 01, 2022 10:14 pmThis reminds me that I still have to put those pre-built binaries (that required to build from source) up so people can download them. I wouldn't sweat failing at building engine(s) from source, the existing instructions aren't that great, and the Windows OS build instructions are only as good as it is because Trevor DeVore took some time to write better/updated instructions some time around 2017.overclockedmind wrote: ↑Mon Aug 01, 2022 4:27 am It's driving me nuts that I'm just knowledgeable enough to almost, ALMOST build it just from the directions.
Please do a buildset of the IDE we can use for Windows, Linux, and macOS. It's fine if the Linux build is an .AppImage (like the screenshot you posted some time ago.)
MBA (Early 2015, 8GB/512G SSD, Monterey 12.7.2)
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
Playing around with the playground stack a bit more today.
I think it's funny that a some critical things don't work or don't work correctly in the Emscripten engine, yet setting the 'lookandfeel' property for emulated OS control styles works, well partially, if you set lookandfeel to "Appearance Manager" the Emscripten engine crashes, but you can set it to "Motif" (default for Emscripten, and Android),"Macintosh" (we're talking 1990s MacOS classic look), or "Windows 95" (LOL) and the appearance of scrollbars and other controls change accordingly. Too bad none of that has been updated since the 1990s it seems.
I also updated the demo sub-stack to be a movable/sizable window (with homebrewed window control decorations).
Unfortunately if you use any HTML5 "native" buttons, they will be on a canvas layer above everything, any stack windows. This isn't quite so strange when you consider that this is the way "Native" control widgets behave on desktop platforms as well, so at least that's consistent.
If you use Safari's developer menus, you can look at the layering of canvas elements (in 3D!)
Strangely the layering in the developer tools looks almost correct ("Set Web Page Color" should be really be below the Piano Widget), but the way the Engine renders it does not match that layering either, and our "HTML5 Native" button ("Set Web Page Color") is drawn on top of everything else!
I think it's funny that a some critical things don't work or don't work correctly in the Emscripten engine, yet setting the 'lookandfeel' property for emulated OS control styles works, well partially, if you set lookandfeel to "Appearance Manager" the Emscripten engine crashes, but you can set it to "Motif" (default for Emscripten, and Android),"Macintosh" (we're talking 1990s MacOS classic look), or "Windows 95" (LOL) and the appearance of scrollbars and other controls change accordingly. Too bad none of that has been updated since the 1990s it seems.
I also updated the demo sub-stack to be a movable/sizable window (with homebrewed window control decorations).
Unfortunately if you use any HTML5 "native" buttons, they will be on a canvas layer above everything, any stack windows. This isn't quite so strange when you consider that this is the way "Native" control widgets behave on desktop platforms as well, so at least that's consistent.
If you use Safari's developer menus, you can look at the layering of canvas elements (in 3D!)
Strangely the layering in the developer tools looks almost correct ("Set Web Page Color" should be really be below the Piano Widget), but the way the Engine renders it does not match that layering either, and our "HTML5 Native" button ("Set Web Page Color") is drawn on top of everything else!
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
I am a relatively pedestrian sort of fellow who has been using HyperCard - MetaCard - Revolution - LiveCode for about 29 years
[with side excursions into Director and ToolBook] for a wide variety of software products: commercially, in University and school settings,
and for fun.
I also teach children 8- 17 introductory programming short courses every Summer using BBC BASIC and LiveCode.
I shall continue to do both of those things using LiveCode 9.6.3 Open Source unless you, or anyone else, can produce:
1. A feature identical IDE that has all references to LiveCode removed.
That is ALL that I am looking for at present.
I believe there are a large number of people who would be delighted with just that.
So whether one can look at layers in 3D or anything else is nothing but a seemingly pointless distraction from
that aim at the moment.
I will apologise if that comes across as rude,as it is not meant in that way: BUT what it is meant to be
is my saying in the strongest possible way that I think you have allowed yourself to get badly distracted
from what was your stated aim when you started out on this venture.
All the extra things (which are, undoubtedly, very clever and add wonderful possibilities to xTalk) should
wait until the stated aim has been completed.
[with side excursions into Director and ToolBook] for a wide variety of software products: commercially, in University and school settings,
and for fun.
I also teach children 8- 17 introductory programming short courses every Summer using BBC BASIC and LiveCode.
I shall continue to do both of those things using LiveCode 9.6.3 Open Source unless you, or anyone else, can produce:
1. A feature identical IDE that has all references to LiveCode removed.
That is ALL that I am looking for at present.
I believe there are a large number of people who would be delighted with just that.
So whether one can look at layers in 3D or anything else is nothing but a seemingly pointless distraction from
that aim at the moment.
I will apologise if that comes across as rude,as it is not meant in that way: BUT what it is meant to be
is my saying in the strongest possible way that I think you have allowed yourself to get badly distracted
from what was your stated aim when you started out on this venture.
All the extra things (which are, undoubtedly, very clever and add wonderful possibilities to xTalk) should
wait until the stated aim has been completed.
https://richmondmathewson.owlstown.net/
-
- Posts: 124
- Joined: Mon Sep 13, 2021 9:46 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
Dittorichmond62 wrote: ↑Tue Aug 02, 2022 7:00 pm BUT what it is meant to be
is my saying in the strongest possible way that I think you have allowed yourself to get badly distracted
from what was your stated aim when you started out on this venture.
All the extra things (which are, undoubtedly, very clever and add wonderful possibilities to xTalk) should
wait until the stated aim has been completed.
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
That is still the primary goal.1. A feature identical IDE that has all references to LiveCode removed.
That is ALL that I am looking for at present.
I believe there are a large number of people who would be delighted with just that.
Actually the goal is specifically an IDE that is significantly differentiated from its progenitor, so as to not confuse any customers or potential customers of a certain commercial product.
I think you've missed the point entirely. That post isn't about looking at HTML canvas layers (in 3D!).So whether one can look at layers in 3D or anything else is nothing but a seemingly pointless distraction from
that aim at the moment.
I will apologise if that comes across as rude,as it is not meant in that way: BUT what it is meant to be
is my saying in the strongest possible way that I think you have allowed yourself to get badly distracted
from what was your stated aim when you started out on this venture.
All the extra things (which are, undoubtedly, very clever and add wonderful possibilities to xTalk) should
wait until the stated aim has been completed.
It's about how the 'Native' elements created by the Emscripten xTalk Engine are layered, with the HTML5 'Native' Widget being layered ABOVE the sub-stack window that I opened, which is a problem if you want your web-stacks to have substacks UI elements such as a custom dialog box while also using HTML5 'Native' Elements (any sort of graphical HTML5 widget).
I don't see this as distraction at all, I see this is part of evaluating the state of our xTalk Emscripten engine as it was left to the community. And this evaluation was prompted by the need to edit that Engine .js so that there wasn't an LC logo in the bottom-right corner of it (where it used to say 'Download this App'), as well as replace the logo and spinner graphics that are included by default, possibly edit the Standalone Builder Stack to remove the eye burning neon-green. Also the Emscripten deploy tab is entirely devoid of deployment options, which needs to change (eventually). At minimum I've like to have the ability to include embedded or linked-in .js scripts into our deployments outer HTML, and options for edit/replacing the template Emscripten template script-only stack (which becomes boot, start-up stack, like the 'Home' stack is for the IDE) in your HTML deployments.
I'd also like to create some how-to docs for deploying to GitHub .io pages using a normal GitHub repo.
But I understand the concern. The reality is that the only thing that I can promise is that I will keep at this for as long as I possibly can, and do so for as many hours as I can without skirting my other, RL obligations (too much
![Wink ;)](./images/smilies/icon_e_wink.gif)
My plan for the rest of this month is to work at getting the GitHub repos up-to-date with the latest changes, including an unbranded Emscripten deploy option, and build som packages so people don't have to apply these changes from the files on GitHub (which you could do yourself if you really wanted to, they are mostly drop-in replacements).
There's only so many hours in a day and I already have a 'day-job' (that actually pays bills), I also have a family, house, animals that I try to care for, not to mention one other hobby that is really important to me, so I do whatever I have time for whenever I can fine time for it. The OXTWebPlayground stack allows me (AND anyone esle from 'the community'!) to real-world test the Emscripten engine from any device with a modern HTML5 browser from anywhere, then report back here (also from anywhere with internet), so that's REALLY helpful! And if I can come up with quick solutions or additions while I'm at it then IMO that's all the better for the community. For example the "impressive" TTS 'say' command took about 2 minutes, seriously! A quick google search, then pasting in one line of javascript and clicking a button to see if it worked, which I DID FROM MY PHONE WHILE IN A MOVING VEHICLE! Can you get any more efficient use of otherwise wasted time staring out the window than that? (not that staring-out windows while thinking about things isn't a valuable exercise for the imagination
![Wink ;)](./images/smilies/icon_e_wink.gif)
Anyway I'm starting to think that HTML5/Emscripten/WebAssembly stuff is really going to be useful going forward, WebAssembly isn't really just about using the web as a sandboxed VM, It's about intermediate ByteCode that is inherently very portable / platform agnostic! And that can be used sans-browser! You can compile some C++ code to WebAssembly a byte-code module and run it via CLI app from any platform capable of running a modern web-browser (so maybe not LG WebOS, formerly PalmOS, which is in their TVs? My LG TV got broken a while back).
I have to go mow my lawn now
![Sad :(](./images/smilies/icon_e_sad.gif)
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
Several people have communicated with me privately and are in complete agreement with me that almost everything is merely a distraction at the moment, and will continue to be until you can provide
after which you can carry on, and we will all pile on in here with lots of supporting material.A feature identical IDE that has all references to LiveCode removed.
https://richmondmathewson.owlstown.net/
- OpenXTalkPaul
- Posts: 1604
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
Well I wish they would say that more publicly so I know what the consensus is. That's part of the value of having a community. I was just skimming this (FreeBSD related) article about that:richmond62 wrote: ↑Sat Aug 06, 2022 2:39 pm Several people have communicated with me privately and are in complete agreement with me that almost everything is merely a distraction at the moment, and will continue to be until you can provide
after which you can carry on, and we will all pile on in here with lots of supporting material.A feature identical IDE that has all references to LiveCode removed.
https://klarasystems.com/articles/contr ... velopment/
In case you missed (the edit):
My plan for the rest of this month is to work at getting the GitHub repos up-to-date with the latest changes, including an unbranded Emscripten deploy option, and build some packages so people don't have to apply these changes from the files on GitHub (which one could do themself if they really wanted to, they are mostly drop-in replacements).
- richmond62
- Posts: 2818
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: July 29th 2022 (one year since last official community release)
Maybe they don't have the brass neck that I do.Well I wish they would say that more publicly so I know what the consensus is.
![Smile :)](./images/smilies/icon_e_smile.gif)
And 'consensus' may be overdoing things as we're talk about myself + 3: you may have noticed that there are very, very
few people still looking at these forums.
I suspect this is because, to a large extent, you, having produced a very good, 98% IDE for Linux, then went off
on all sorts of abstruse tangents without checking whether anyone apart from yourself was interetsed in them.
https://richmondmathewson.owlstown.net/
-
- Posts: 22
- Joined: Thu Sep 16, 2021 2:15 pm
- Contact:
Re: July 29th 2022 (one year since last official community release)
I am happy to make it +4 but also say this:
a) Paul can play around with any code that he likes to. He is the one to decide about his time.
b) As has been stated by some people last September here, of course a top-reliable debranded edition without _any_ feature changes would be the necessary first step. It does not make sense to repeat this so often if it does not resonate.
c) As has also been said, a further edition foremostly and most importantly has to include a re-compiled engine. The public engine code has not been touched yet by anyone to any effect it seems and will be rotting away beyond rescue in a not-too-distant future depending on platform. It would take a much different effort than the one here to keep that from happening. It needs surely more than one guy, and the group would have to focus on a goal and stick to it.
a) Paul can play around with any code that he likes to. He is the one to decide about his time.
b) As has been stated by some people last September here, of course a top-reliable debranded edition without _any_ feature changes would be the necessary first step. It does not make sense to repeat this so often if it does not resonate.
c) As has also been said, a further edition foremostly and most importantly has to include a re-compiled engine. The public engine code has not been touched yet by anyone to any effect it seems and will be rotting away beyond rescue in a not-too-distant future depending on platform. It would take a much different effort than the one here to keep that from happening. It needs surely more than one guy, and the group would have to focus on a goal and stick to it.
Who is online
Users browsing this forum: No registered users and 1 guest