The basis for an xtalk engine [I/we] control

[tperry2x]

The rapid visible progress you are making is absolutely awesome to watch from the sidelines.

Thank you Kelly, much appreciated.

Hah, excellent! I was thinking the same about 'graphic'... Preferably it's sideways-compatible with OXT community engines?

It might not be. Can you even do curves for shapes in the community engines? - I didn't think you could.

As far as tool palettes go:
1) I'd like a bunch of separate palettes that focus on one specific sort of task, such as
object creation ('Tools'),
object arrangement (alignment/distribution/angle),
text editing,
etc.

This was my thinking with being inspired by the Adobe type palette above - it groups buttons into sections/categories, then you click them to see variations of that tool. (Two clicks needed though to get to the tool you need - 3 if the palette is collapsed... so I really don't know the best way to implement this)

I think the OXT/LC CE property inspector had too many things crammed into it.

Yes, I absolutely agree. Something that looks to be happening again with Create. I don't want to go that route.

2) I'd like it if there was a special key-combo to make them all go away when I want that screen real-estate back

Yes, I was wondering about adding ctrl + [key] for lots of things. Hiding/showing of Tools could be one of them, as could shortcuts to choose the actual tools themselves. I've experimented with this a bit already (using shortcuts I mean) - you can already do ctrl + return instead of clicking the 'run' button in the message box.
When toggling all tool palettes, I know the likes of Adobe use tab (or used to) - we probably don't want to use that. Will have a think.

I certainly don't want it to be like the 3D software Blender. If you watch a blender tutorial video, it's full of people pressing all manner of keys without any pause or explanation of what they do. It's confusing and infuriating if you don't know what key is supposed to do what.

3) small / unobtrusive if possible, IMO the Control Strip was great example. The things that use to be in the Control Strip are now in 'status menu items' that live in the top right corner of the global system menu, like sound volume pop-up menu. But the control strip took up less space than because it could be collapsed.

Yes, precisely. It got out of the way when you didn't need it, but it was there when you did. It's probably what inspired the OSX dock in a lot of ways. Now every OS seems to have one.

4) If they could be flexible enough to be usable on a phone-screen that would be fantastic!

I've not even tested any of this on a phone. Hadn't even considered that, but will try it at some point. That's a great shout.

If you could make it like QuarkXpress 4.2 (best version) that would be great. I'm biased there because I used Quark extensively for nearly two decades.

Ugh, Quark. There's a bit of software I'd rather consign to the history books. Me and Quark go way back. Countless lost work because of Quark 4, and 5. Quark files on MacOS 9 disappearing in front of your eyes when you hit save, to vanish without a trace. InDesign was the best thing to happen back then, the repro studio I was working in switched and we never looked back.

I'm really looking forward to some sort of picture box / pixel image object. I've done 'DIFF' mergers to inject my 'image' object, but you keep releasing updates and adding my changes to them repeatedly is just not worth doing. So I'll just wait until you get to that.

haha, yes - sorry. I'm kind of working through a to-do-list (there's the one I've already shared in that folder in ODF format), but it's happening in an order that makes sense (in my head).

There's a lot of options that can be used with the <img> elements nowadays. You can use SVG as an image now!

Almost too many options!

...there's additional element <picture> that can be used to provide alternative images tailored to the layout orientation or for high-density displays ('retina, 4K/8K screens). There's far more options that could be use than we've had with the inherited engine's 'image' control.

I need to have a read up on this! (note to self)

I was thinking 'Images' should be treated as 'engine'-wide resources, separate from an 'image control' (a picture box that images can be displayed in). Buttons can have images too, a background could have a repeating image as a pattern as well, so images kind of need to considered as a multimedia asset, like a sound sample or a movie clip.

I was wondering about the logistics of how we actually do this.

If we had an "images" folder in the root of the interpreter directory, such as:

list.png (97.54 KiB) Viewed 12390 times

That's great, and I'm sure I could pull images from there.
However, what about eventually when someone wants to create their stack, and let's say I've got image object support by then, how do we actually get the images the stack author has used to copy into this "images" folder for loading?
I was wondering about having a subfolder called "stacktemp" or something like that. When a stack gets loaded, all the stacks resources like images and sounds get bundled into this folder so the stack can load them. It needs to do a kind of unpack when the stack is loaded, then pack it all up again when it's saved.
I'm thinking of keeping JSON format for the stack itself as that's working well, but I wonder about having it all being enclosed in a single file - like a zip archive (with a wxstack extension) - but I don't even know if that's possible yet.

There's a lot to work out before I get to that point of course. All stuff to consider though!

[tperry2x]

I was wondering about the logistics of how we actually do this.
...what about eventually when someone wants to create their stack, and let's say I've got image object support by then, how do we actually get the images the stack author has used to copy into this "images" folder for loading?
I was wondering about having a subfolder called "stacktemp" or something like that. When a stack gets loaded, all the stacks resources like images and sounds get bundled into this folder so the stack can load them. It needs to do a kind of unpack when the stack is loaded, then pack it all up again when it's saved.
I'm thinking of keeping JSON format for the stack itself as that's working well, but I wonder about having it all being enclosed in a single file - like a zip archive (with a wxstack extension) - but I don't even know if that's possible yet.

Answering my own question here somewhat.
My current idea is to pack everything into a JSON blob bin file when the stack is saved.
When the stack is loaded, it unpacks the blob bin file and we have everything we need.

The problem with that though is if you want your stacks to be readable in the likes of github, because the bin files certainly aren't.

blob.html.zip

(1.45 KiB) Downloaded 194 times

Edit: I also have a Plan B.

(This is a more complex method, but is easier for the user) - and probably easier for me in the long run
We can keep everything as a JSON file, so nice and easy and no multiple packing / unpacking required.
You'd just have to ignore the binary string in github if you were editing the JSON manually.
All other properties could be human-readable though:

image to JSON data.html.zip

(1.36 KiB) Downloaded 197 times

Of course, that ugly binary string only appears when you insert an image into what would be your stack.

Also, even though that "image to JSON data.html" page in a browser will handle the loading of this JSON-ised image data (which would be our entire stack file with buttons, fields, scripts etc), it causes most text editors to lock up (or to seriously think a lot!)

not-nice-looking.png (71.66 KiB) Viewed 12239 times

The 5924 character string I've circled. Believe it or not, that's this image:

tiny.png (4.34 KiB) Viewed 12222 times

I hate to think what a large image would be represented as.

[OpenXTalkPaul]

I'm thinking of keeping JSON format for the stack itself as that's working well, but I wonder about having it all being enclosed in a single file - like a zip archive (with a wxstack extension) - but I don't even know if that's possible yet.

Answering my own question here somewhat.
My current idea is to pack everything into a JSON blob bin file when the stack is saved.
When the stack is loaded, it unpacks the blob bin file and we have everything we need.

The problem with that though is if you want your stacks to be readable in the likes of github, because the bin files certainly aren't.

If you use the FileReader API there is a method .readAsDataURL(file); that wraps the binary as a Data URI which can then be directly used as an <img src= value, and can be embedded into html page or written to your JSON format. Since the binary has been encoded then ASCII safe text, it should be no problem for GitHub, Diff tools, or any other version control. The browser engine should automatically handle decoding and caching the image to it's web cache. The only issues I can think of with that might be size limits, but all recent major browsers support at the very least a 512Kb maximum, and the actual file-size for a binrary is increased somewhat by applying the base64 encoding needed for Data URIs to work, but that matters a bit less if the images are smaller or is not being transmitted over a network.

[OpenXTalkPaul]

That's another good thing about 'an xtalk engine [I/we] control', maybe the best thing about it actually. If your xTalk scripts/stacks can be functional with a different xTalk interpreter, then your they are unshackled from Engines past and their terms and conditions.

[tperry2x]

...the actual file-size for a binrary is increased somewhat by applying the base64 encoding needed for Data URIs to work, but that matters a bit less if the images are smaller or is not being transmitted over a network.

Yes, it's not really the size of the files I was worried about, it was the processing lag of them in a text editor. Base64 encoding seems to fix this. I'm currently trying out compression like zLib, LZString. I would have used Brotli but that's a plugin that isn't part of the standard javascript suite, so that's out.

Here, I'm testing with the JSON encoders I put together earlier:

compression-test-page.png (23.02 KiB) Viewed 12089 times

You are spot-on. Base64 encoding them first does increase the filesize, but at least that way they are web-safe / don't have strange character encoding. That should reduce the possibility of any corruption (especially on image files), so it's a small price to pay for reliability.

The top window in this screenshot is the un-encoded, raw (no Base64) data of the image object.
The bottom window is our encoded data string, which will survive internet transfer. (plus it's a lot easier on the eyes).

compare.png (96.34 KiB) Viewed 12089 times

files.png (34.56 KiB) Viewed 12089 times

I'm inclined to go with lzString or zLib as both are part of the standard javascript suite. (no extra plugins required, and no BS regarding licensing).

If anyone is reading this thinking, why does this matter - I won't see that code. No, hopefully you won't need to ever. The idea is you'll do it all in the browser GUI. This is just the underpinnings that will go into making the image object reliable hopefully.

[tperry2x]

I've moved some posts that were in this topic to here instead, as this topic is about the browser based version of an IDE.
This topic I moved it to is about the LCC-engine based one we inherited, which OXT / OXT Lite is based on.

Please continue discussions about our classic IDE there, just so we don't get muddled. No point discussing what's in the old IDE in this topic.

[tperry2x]

That's another good thing about 'an xtalk engine [I/we] control', maybe the best thing about it actually. If your xTalk scripts/stacks can be functional with a different xTalk interpreter, then they are unshackled from Engines past and their terms and conditions.

I could not agree more
I do hope I can make something that's at least useable. (I've already made my LCD Clock stack in it as a test) - the one I made for Android.

EDIT: (that raises a few more things I need to correct of course!)

test-clock-new-stack.png (39.03 KiB) Viewed 10520 times

You've also reminded me to go test this on some mobile devices...

This is on my daughter's iPad, didn't think it would work but it did.

IMG_3068.png (136.13 KiB) Viewed 12034 times

IMG_3069.png (107.73 KiB) Viewed 12034 times

It's a bit maddening to type anything though as it keeps trying to autocorrect any scripting. A few tweaks would be in order.

Haha, android not so much

Screenshot_20250326-202604_Firefox Focus.jpg (91.54 KiB) Viewed 12017 times

[OpenXTalkPaul]

This is on my daughter's iPad, didn't think it would work but it did.

It's a bit maddening to type anything though as it keeps trying to autocorrect any scripting. A few tweaks would be in order.

Right you can turn it on/off host text completion and autocorrect / spell checking with the right attributes on input elements.

Code: Select all

 <input type="text" spellcheck="false" autocapitalize="none" autocorrect="off" autocomplete="off" >
 

https://developer.mozilla.org/en-US/doc ... utocorrect
https://blog.whatwg.org/the-road-to-htm ... llchecking

Haha, android not so much

Android does run on Linux kernel so that could be considered correct.

[OpenXTalkPaul]

Save for later:
HTMLCanvasElement: toDataURL() can be used to get aa DataURL from an source image using canvas rendering (could be used for 'export snapshot' or similar xTalk syntax)
https://developer.mozilla.org/en-US/doc ... /toDataURL

Might be a good idea to use <canvas> elements for anything that has to be rendered and may take additional time to load (like extra large images).
https://developer.mozilla.org/en-US/doc ... ent/canvas

Using an offscreen canvas
A canvas can be rendered using the OffscreenCanvas API where the document and canvas are decoupled. The benefit is that a worker thread can handle canvas rendering and the main thread of your web application is not blocked by canvas operations. By parallelizing work, other UI elements of your web application will remain responsive even if you are running complex graphics on an offscreen canvas. For more information, see the OffscreenCanvas API documentation.

(emphasis mine)

[tperry2x]

Android does run on Linux kernel so that could be considered correct.

Haha, true. I think I'd rather it returning "Android" though. That's one for the list.

Might be a good idea to use <canvas> elements for anything that has to be rendered and may take additional time to load (like extra large images).

Yes, definitely. Will try and build that in when I have a moment.

Version 127
Added to the mouseup and mousedown handlers.
Any objects created (and the card for that matter), now understands which mouse button is being clicked.

Code: Select all

on mousedown thebutton
   put thebutton
   -- will return 1 for the left mouse button
   -- will return 2 for the middle clickwheel
   -- will return 3 for the right mouse button
end mousedown

[richmond62]

put thebutton

Over 'here': MacOS 15.4, OXT Lite 1.10:
-

moose.jpg (5.25 KiB) Viewed 11685 times

-
My kinky mouse with 5 buttons ONLY returns 1, 2, and 3: so the other 2 buttons are no use at all, at least inwith the IDE.

It would be super IF in the browser-thing if ALL buttons on a mouse (and there are mice out there with a lot of buttons) could be picked up.

[OpenXTalkPaul]

My kinky mouse with 5 buttons ONLY returns 1, 2, and 3: so the other 2 buttons are no use at all, at least inwith the IDE.

It would be super IF in the browser-thing if ALL buttons on a mouse (and there are mice out there with a lot of buttons) could be picked up.

That probably depends on what sort of signals the driver for that thing sends for those extra two buttons, because the max standard AFAIK is Unix 3-button mice.
If you can find a JS input test on the web that can detect a signal from them then you're golden.
https://unixpapa.com/js/testkey.html
https://w3c.github.io/uievents/tools/mo ... iewer.html

I believe all modern browsers support multi-touch input, like 4 finger touch-points detecting, but I'm sure that device does not send touch input signals (there are 'trackpads' that do). You probably really need to have a driver for that device installed, either official driver or otherwise 3rd party generic driver that can detect those buttons (like 'USBOverdrive" for example), with a control panel where you set what signal you want those buttons to send. Like the software that similar Microsoft or Logitech input devices with non-standard buttons come with.

[richmond62]

Button 5 works in the Brave Browser.

[OpenXTalkPaul]

I'm thinking of 'porting' my Piano Widget to HTML5 Path2D API, it's basically the same as LCB canvas drawing, and it is now widely supported across browsers engines. It would be easy to translate the LCB drawing code, messages it sends, and array structure it's built with. Not to toot my own horn too much but I did a LOT of work on that thing and it rendered well for me across platforms, and the keys shapes were accurate to real Piano keys and the math that spaced them out in variable amounts of octave groups across the screen correctly and colorized / highlighted them was damn near perfect.
https://developer.mozilla.org/en-US/docs/Web/API/Path2D
A <canvas> element and Path3D API basically gives you what the old SVGIcon widget thing is/was.

[Kdjanz]

If I recall I took a some flack from a few people for suggesting doing more work on the web related things, like working with Emscripten engine, but I'm glad we're getting there now with an xTalk wrapper around HTML5 & JS. I definitely see this as an opportunity to go beyond the xTalks that came before and a move to be more aligned with modern 'HyperMedia' standards.

As one of the nay sayers about the whole browser thing, I publicly repent. It is the only real way forward that will allow real development and growth of XTalk on a modern foundation. Like the discussion on SVG and bezier curves suggests, I would say that the aim should be for a superset of the LC Xtalk dialect - yes it will run most old stacks, but it can also do all these new and modern things that programmers expect in an environment these days. Why limit yourself when you have such a clean blank page to play on now?

Paul - you started picking apart the Emscripten tangle and noted that there was a much smaller and modern way of doing it now. Could I suggest you grab that area with both hands and wrestle it into something that will suit our shiny new engine/not-an-engine? We need that to make standalone stacks (if I am understanding correctly) and given my distaste for the bloated stinking mess that Electron is - it would be great to have something new and sleek to match the rest of the new stuff. As fun as the piano is, I think that modern Emscripten would be much more useful to more users.

Again - congratulations on such speedy progress and thanks to everyone.

Eager for betas, but willing to wait for a bit of UI on top of the guts.

[FourthWorld]

Just riffing here with a fresh cup of coffee...

OXT could provide a way to edit Beziers, but there are so many options available in dedicated graphics tools that ultimately it would mean a long process moving slowly toward reproducing a subset of Inkscape inside of OXT.

Meanwhile, Inkscape already exists and is awesome.

And Inkscape has extensibility mechanisms which allow one to automate SVG creation in whatever language you like.

So...

Imagine an OXT that integrates nicely with Inkscape, so that Inkscape becomes effectively the graphics editing mode.

Same could be done with GIMP and Krita for raster editing. They pretty much already are; no xTalk has ever dared to build those kinds of features internally.

This sort of "helper app" approach is already enjoyed by scripters using MS Studio and other external editors.

By focusing on integration and delivery of an interactive work, relying on best-of-breed tools for media editing, OXT development remains focused on its unique role, a hub in the center of an interactive studio.

This also has the opportunity to build bridges with other communities, the folks using those other tools.

No proprietary option can do this. Such a vision, bringing tools and their communities together for assembly and deployment, requires not only the mechanics of FOSS licensing, but more powerfully the FOSS ethos.

Sharing. Hundreds of people, each doing the part they do best, integrated into a workflow for delivering finished works which incorporate assets from each app in the system.

Integration seems the biggest opportunity, at least far greater in terms of ROI than reproduction.

Thoughts?

[TerryL]

Here's a quick mockup for an upperLeft tools palette to bash 'n hash. This could be mirrored in a pulldown Controls menu too. Maybe click or hold over a category and the appropriate panel could slide or popup to the right in horizonal as pictured, or vertical. Or maybe use only one panel and populate with appropriate icons. Just ideas to mull. I like the current desktop tools palette, I leave it open all the time. With one mouseDown/drag or dbl-click I get the control I want: simple and easy.

WebTalk is your thing and you can do what ever you please with it. If you want people to use it and be happy or at least accept, it should look familiar, something they're used to. Microsoft did a lot of test-group trials when developing the ribbon menu. While test groups found menuItems they wanted quicker, most people really dislike ribbon menus, preferring familiar pulldowns, EVEN if it takes them longer. MS never got that. In the same vein, I don't care for the Create IDE either, the tools palette and properties inspector are just too different and strange. There's no joy or fun in it. I see great software as offering a remarkable set of tools while staying out of the way as I use them.

[tperry2x]

Thank you Terry, yes - I couldn't agree more: I can't stand the Microsoft 'Ribbon'. I never remember where anything is. Doesn't help that it's different between the desktop app versions and the web app versions too. I've also fully read your tools palette idea (much appreciated) - I will come back to that.

[tperry2x]

Version 128
I'm mostly back-tracking with this version. (I want to make sure I squash any potential bugs as I go, rather than having them all build up and it be a monumental task to try and fix them).

The first of these is that I noticed that if you set the points of a graphic to something, then move the graphic, the stored points references were not getting updated properly (they were not changing). Now they do properly.

For example:

Code: Select all

create graphic "test"
put the points of graphic "test" -- returns 50,50,150,150 for example
set the left of graphic "test" to the left of graphic "test" +40
put the points of graphic "test" -- now returns 90,50,190,150 correctly.

sending messages fix:
If you had two buttons, one button called "one" has this script:

Code: Select all

on tHandler
   answer "success"
end tHandler

the other button has this script:

Code: Select all

on mouseup
   send tHandler to button "one"
end mouseup

This now works like it should - you'd get the tHandler message passed along the message chain properly to the "one" button and you'd get the answer "success" on screen.

mouse buttons:
In the last version, v127 - I implemented the detection of the mouse button (buttons 1=left,2=middle clickwheel and 3=right) - this is really just to support the most common of input devices (mice) but I'll expand upon HIDInput at a later stage for funky controllers.
The issue was that with the mouseup and mousedown messages, if you don't specify a parameter at the end, they should only be watching for the left mouse button. This is fixed, mainly so right-clicking for the contextual doesn't ever get blocked.

Multi-line "puts" into [variable]:
I've now got a multi-line put command in place. What I mean by this, is that you can do:

Code: Select all

put "a" into line 1 of tVar
put "b" into line 2 of tVar
put "c" into line 3 of tVar
put tVar
put "line1" into tVar2
put "line2" into line 2 of tVar2
put "line3" into line 3 of tVar2
put tVar2

which would return:

Code: Select all

a
b
c
line1
line2
line3

(as you'd expect) -- I know this doesn't seem like much, but it's actually quite complex to work out.

Empty literals.
For example, you can use:

Code: Select all

put empty into tString -- which clears the contents of the tString variable
-- It's effectively the same as using:
put "" into tString

Itemdelimiter and itemdel:
I've added itemdel as a synonym of itemdelimiter and added tests for this in the testing2.html page to check it's all working as it should.

String concatenation:
You can now do && to join two strings with a space, for example:

Code: Select all

put "a" & " " & "b" into tVarA
put "a" & space & "b" into tVarB
put "a" && "b" into tVarC
put tVarA
put tVarB
put tVarC

This would return:

Code: Select all

a b
a b
a b

(which is logical and makes sense now)

Dateitems order fix (oops!):
This was me being rather silly!
Previously, getting the dateitems would return something like:

Code: Select all

2025,3,28,6,8,14,24

When it should be returning this:

Code: Select all

2025,3,28,8,14,24,6

(I'd essentially mixed the day of the week up). Where 6 is shown, this is the numeric day of the week (friday, as Sunday is counted as 1). I'd mistakenly made this item 4 of the dateitems whereas it should come at the end as item 7. This was just a single line of code fix, but it's important to get it right.

Mentioning dateitems, you can now also convert between dates, seconds, and add values to strings and convert them back to dateitems (useful when comparing dates and durations) -- thanks to TerryL for this. I've added tests too for all these.
Example scripts would be:

Code: Select all

put the seconds into tDateNow
convert tDateNow to dateItems
put tDateNow -- returns 2025,3,28,8,21,53,6 for example
convert tDateNow to date
put tDateNow -- returns 3/28/2025

Or, an easier way:

Code: Select all

put the dateitems into tDateNow -- gets the seconds and converts to dateitems in one
put tDateNow -- would be 2025,3,28,8,21,53,6 for example
convert tDateNow to long date -- would be "Friday, March 28, 2025" for example

Then I was trying to trip it up:

Code: Select all

put the dateitems into tDateNow -- returns 2025,3,28,8,21,53,6 for example
convert tDateNow to seconds
put tDateNow && "(seconds now)"
add 86400 to tDateNow -- adds a day's-worth of seconds
put tDateNow && "(with added seconds)"
convert tDateNow to dateItems -- put it into the dateitems format we need
convert tDateNow to date
put tDateNow && "(should be +1 day from today)" -- would return 3/29/2025 (a day later)

cr and lf (and 'return'):
If I use this script:

Code: Select all

put "a" & return & "b" -- outputs "a" on the first line, "b" on the second.
put "a" & cr & "b" -- outputs "ab" only. Doesn't end up on two lines.
put "a" & lf & "b" -- outputs "a" on the first line, "b" on the second.

I wonder if lf (linefeed) is supposed to be used for browser based stuff instead of cr?
I went with lf as what I read online seemed to suggest that lf was standard. It's a single line addition to tweak this, so not a huge issue

[tperry2x]

I'm thinking of 'porting' my Piano Widget to HTML5 Path2D API...It would be easy to translate the LCB drawing code, messages it sends, and array structure it's built with.

That would be really cool. I think with v128 of webtalk (which I'll post in that shared folder with you this evening) - I wonder if this has all the hooks you need to start creating that as a JSON stack?
I'm working on the image object imminently, but v128 was just a bug fix. I'll move this post to the WebTalk topic if that's okay, just so we keep our 'desktop' IDE and the browser IDE topics apart.