Page 8 of 13
Re: The basis for an xtalk engine [I/we] control
Posted: Mon Mar 24, 2025 9:36 am
by tperry2x
richmond62 wrote: ↑Mon Mar 24, 2025 9:32 am
A 'dirty' question that bubbled up in my brain:
Is the web-xTalk thing JUST an html interpreter floating in a web-page?
That's simplifying it a LOT, but kind of.
It's a HyperTalk/xTalk parser which interprets to Javascript, which then sits in an HTML page. (which is platform-agnostic and does not require internet access). The browser is our 'engine' in this context, but the user types xTalk script. The bits "paddling underneath the surface" are Javascript and CSS. (Javascript for processing, CSS for styling).
Hence why a few posts back, I was able to run it in the likes of
Haiku, old versions of
MacOS, newer (to me) versions of
MacOS, upto current
Windows 11 etc. There's no reason it wouldn't work on an Arm mac either.
There's a very similar flow of processes returned with both approaches.

- similar-steps.png (33.65 KiB) Viewed 13287 times
The advantage of going browser route is there's suddenly more platforms this opens it up to.
The disadvantage is we lose a lot of the lower-level command-line only stuff, unless we go the wrapper/container route that Paul previously mentioned.
Re: The basis for an xtalk engine [I/we] control
Posted: Mon Mar 24, 2025 11:36 am
by richmond62
So that presupposes the end-user (either of the 'IDE' or a standalone inwith a browser window) has javascript installed on their machine: and, presumably if they don't, the thing will detect that and direct the end-user to where they can download and install Javascript (unless it is already embedded in the browser).
Re: The basis for an xtalk engine [I/we] control
Posted: Mon Mar 24, 2025 11:42 am
by tperry2x
richmond62 wrote: ↑Mon Mar 24, 2025 11:36 am
So that presupposes the end-user (either of the 'IDE' or a standalone inwith a browser window) has javascript installed on their machine: and, presumably if they don't, the thing will detect that and direct the end-user to where they can download and install Javascript (unless it is already embedded in the browser).
Javascript (not java) is built into the browser as a core technology. It's not something you can add, the browser either supports javascript or just won't load the page properly. This is why using an old browser which doesn't support newer javascript functions (
Safari on MacOS 10.14 is broken) -
while it works in Firefox. Nothing can be done to fix Safari on MacOS 10.14 as it's out of date and now legacy, which is why something like Waterfox Classic will run it on OSX 10.7 still - because the support is 'baked in' into the browser.
It's also the same reason sites like github and mega don't load under old versions of safari now, but will continue to run on Firefox and various forks of it, which have updated javascript support.
Re: The basis for an xtalk engine [I/we] control
Posted: Mon Mar 24, 2025 8:35 pm
by TerryL
Reviewed the WebTalk Doc-113 pdf. All great progress, most impressive. What can WE do to help you if we know nothing of javascript? A few suggestions if not already done, or if even possible:
- put item -1 of "a,b,c" --count from end of string
- sort lines of tList numeric descending by word 1 of each --'by <expression> of each' item/line is useful
- sort items/lines dateTime --to go with default text and numeric.
- answer/ask: titled "My Test Dialog" --dialog title is common option
- itemDel --synonym for itemDelimiter
- && --concatinate with space
- cr --synonym for return
- vScrollbar property true/false, hScrollbar property true/false
- set the vScroll of fld "Test" to "0" --I think these are pixels, "0"=top, "10000" or any large number =bottom, same for hScroll
- the short date --synonym for the date and date()
- convert date() to seconds --to compare dates
- convert date() to dateItems --yr,mo,dy,hr,mi,sc,dow
- repeat for each item/line i in tList --alternative to 'repeat with i ='
- put mod(-7,3) --should return -1. mod(7,-3) should return 1.
- put round(10.5678,3) --10.568, round with precision
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 2:07 am
by OpenXTalkPaul
Please add to createFieldMatch createButtonMatch lines the in interpreter to add abbreviations to the regex string
Code: Select all
const createButtonMatch = script.match(/^create\s+button|btn\s+"([^"]+)"$/i);
const createFieldMatch = script.match(/^create\s+field|fld\s+"([^"]+)"$/i);
so scripts can use the abbrev. form:
Also BUG: if you create multiple objects of a kind, like multiple buttons or fields, one can right click and delete each of them except for the last one.
Again I think it's probably best to use some kind of global object indexing part/control number for all of the part/control/webtalkObjects. Specially if there will be ability to have multiple cards and stacks loaded at some point. There could easily be multiple objects with the same name, specially if there's some default name assigned to new objects.
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 3:00 am
by OpenXTalkPaul
Popular buzzword "responsive design"

- Screenshot 2025-03-24 at 10.47.44 PM.png (158.33 KiB) Viewed 13065 times
I was testing the save / load stack (JSON), then I edited the JSON with a text editor, changed 'px' (pixels) to a variable-width percentage and it works just fine, just like a web page would. Now that is
NOT something the inherited OXT Community engine supports, at least not without fiddling around with the geometry library, but using a browser engine as our runtime we get "responsive design'' capabilities just by changing those characters!
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 9:48 am
by tperry2x
OpenXTalkPaul wrote: ↑Tue Mar 25, 2025 3:00 am
Popular buzzword "responsive design"
Screenshot 2025-03-24 at 10.47.44 PM.png
I was testing the save / load stack (JSON), then I edited the JSON with a text editor, changed 'px' (pixels) to a variable-width percentage and it works just fine, just like a web page would. Now that is
NOT something the inherited OXT Community engine supports, at least not without fiddling around with the geometry library, but using a browser engine as our runtime we get "responsive design'' capabilities just by changing those characters!
Glad you like it!
I'm trying to think ahead when I do this stuff - (I know, unheard of right!?

) - you get what I mean though. No point adding something that is hard to edit in the future, and since I'm working from my own blank canvas (no pun intended), then it's much more understandable to me rather than correcting someone else's code). This is precisely the reason I didn't assume px / pixels because percentages are used in browsers too. You raise a good point actually: I haven't checked if it supports em widths at all. For example, "margin-left: 1em" - I don't know how it'd respond to that.

Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 9:52 am
by tperry2x
Version 124
Code: Select all
create fld "test" -- now understands 'fld' as a shorthand for "field"
Corrected this function:
Code: Select all
put "potatoes" into me -- previously didn't work if used in the script of an object.
This is now fixed and would put "potatoes" into a field for example.
Code: Select all
put "test" into line 2 of field "test" -- this now works properly (multi-line)
Code: Select all
on mousedown
put the angle of fld a +1 into tAngle
set the angle of fld "a" to tAngle at 20,20 -- sets the hinge point at 20,20 px of the object
end mousedown
alternatively:
Code: Select all
on mousedown
put the angle of fld a +1 into tAngle
set the angle of fld "a" to tAngle -- sets the hinge point at the middle of the object
end mousedown
Code: Select all
put the topleft of fld "test" -- didn't work
(neither did topright, bottomleft, bottomright).
These are now reported correctly. You should be able to use any of these such as:
Code: Select all
set the bottom of fld "test" to 20
set the top of fld "test" to 12
set the topleft of fld "test" to 40,20
set the topright of fld "test" to 50,10
set the bottomright of fld "test" to 400,200
set the bottomleft of fld "test" to 10,100
This follows the same way HyperTalk worked for positioning objects. (in other words, not very logically: topleft is actually left then top (and so on) - but I've kept that for 'compatibility' with what xTalk scripters might be used to. (I'm trying to play nicely).
added intersect for objects:
Code: Select all
put intersect(button "a", button "b") -- returns true or false
if I type:
Code: Select all
put slash -- should return "/" without quotes
put space -- should return " " without quotes
put QUOTE -- should return a quote character
put comma -- should return a "," without quotes
Added card scripting and backgroundColor / backgroundColour getting/setting of the card:
Code: Select all
on mousedown
set the backgroundcolor of this card to "yellow" -- in button script
end mousedown
on opencard
-- implemented the 'on opencard' message handler
answer "Thank you for trying out my stack!"
end opencard
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 9:54 am
by tperry2x
Version 125
Added support for:
Code: Select all
create btn "btnName" -- we could only use "create button..." previously.
Added the start of graphic objects:
Code: Select all
create graphic "lineA"
set the points of graphic "lineA" to 40,40,160,160
set the lineSize of graphic "lineA" to 5

- graphics.png (14.21 KiB) Viewed 12985 times
In case anyone is wondering, I'm sticking to SVG drawing conventions here, so the JSON of this in the saved stack inside the file looks like:

- the-json.png (13.22 KiB) Viewed 12985 times
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 10:11 am
by tperry2x
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
Reviewed the WebTalk Doc-113 pdf. All great progress, most impressive. What can WE do to help you if we know nothing of javascript? A few suggestions if not already done, or if even possible:
Thanks Terry. I'm happy plodding along for the moment. But thanks for the offer, and this kind of thing is very helpful as it does let me know what I might have overlooked or forgotten to check for:
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- put item -1 of "a,b,c" --count from end of string
This works "out of the box", returns c.
Actually,
there is something that I need help with...
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- sort lines of tList numeric descending by word 1 of each --'by <expression> of each' item/line is useful
That's a good point. I already have sort items of x by ascending/descending but hadn't added line sorting yet
Code: Select all
put "b,a,c" into tLines
sort items of tLines ascending
put tLines -- outputs a,b,c
But then, I've only
just added multi-line support 
.
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
set the itemdel to "/"
I did start looking at this, but I'm getting the "error: too much recursion" message back. (I built that recursion check in at an early stage so I didn't lock up the browser

)
However, this works:
so it's probably just a matter of getting the interpreter to understand the short form of the itemdelimiter (itemdelim) as you rightly say.
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- && --concatinate with space
Yes - I like that idea. I have recently added the 'space' keyword, but being able to do:
Code: Select all
put "a" && "b" into tString -- tString contains "a b"
That would also be handy.
(These are all good suggestions by the way, much appreciated).
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- the short date --synonym for the date and date()
I already have:
I will add "put the short date" as an option.
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- convert date() to seconds --to compare dates
- convert date() to dateItems --yr,mo,dy,hr,mi,sc,dow
I had only just started on the dateitems function, so at the moment if you just use:
you'll get back a list of:
I will expand upon this to take dates and things as parameters.
Although, I should add - you can already do a bit of dateItems conversion:
Code: Select all
put the dateItems into tDateBits
convert tDateBits to the long date
put tDateBits
This will output (for example): Tuesday, March 25, 2025
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- put mod(-7,3) --should return -1.
mod(7,-3) should return 1.

This is going to be down to my bad maths.
Code: Select all
put mod(-7,3) -- returns 2
put mod(7,-3) -- returns -2
TerryL wrote: ↑Mon Mar 24, 2025 8:35 pm
- put round(10.5678,3) --10.568, round with precision
You can kind of do this already, but in a slightly more long-winded way.
Code: Select all
put round(10.5678) into tRound
put format(tRound, "#.#")
I'm sure I could combine and simplify that to match your example.
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 10:55 am
by tperry2x
OpenXTalkPaul wrote: ↑Tue Mar 25, 2025 2:07 am
Please add to createFieldMatch createButtonMatch lines the in interpreter ... so scripts can use the abbrev. form:

Haha, our posts crossed - already done that.
OpenXTalkPaul wrote: ↑Tue Mar 25, 2025 2:07 am
Again I think it's probably best to use some kind of global object indexing part/control number for all of the part/control/webtalkObjects. Specially if there will be ability to have multiple cards and stacks loaded at some point. There could easily be multiple objects with the same name, specially if there's some default name assigned to new objects.
These are represented by unique ID at the moment in the WebObjects DOM mapping, but I know what you mean: I can run:
Code: Select all
create button "test"
create button "test"
And I get two buttons. Both have unique IDs as you can see from the browser inspector:

- multiples.png (4.21 KiB) Viewed 12956 times
But I get what you mean - ideally it should at least bring up an error which says "Error: button "test" already exists"
OpenXTalkPaul wrote: ↑Tue Mar 25, 2025 2:07 am
Also BUG: if you create multiple objects of a kind, like multiple buttons or fields, one can right click and delete each of them except for the last one.
Okay - I'll look at that. I also want to build in "selection handles" or "resizer dots" - whatever you'd like to call them, so it shows what object you might have selected and allow you to adjust the size of them with the mouse (other than just via script as you can do at the moment).
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 11:32 am
by tperry2x
richmond62 wrote: ↑Tue Mar 25, 2025 11:13 am
In OXT 'KREATE' are you going to have a toolbar with objects, or is the whole thing going to run on a command line (messageBox)?
Haha, I'm not going with any OXT naming scheme currently. I mean, that's not to say I won't make a 'sanctioned fork' of it specifically for this site and this project of course. (see what I mean by sanctioned where I mention the license on the last page of the documentation PDFs) - I haven't hard-coded the name of this project anywhere in the code. At the moment, it doesn't really have a title - other than what appears in the browser's titlebar. There's no 'branding' other than my icon. (I know you didn't ask that, but it's a good point).
Anyway, no: this won't be command-line only. Not at all.
I'm just not at the stage where I'm ready to add floating tool palettes or an inspector yet. That's partly why I wouldn't yet deem it worthy of mainstream release.
However, I have been thinking about it.
Given that most people's screens are landscape orientation (an assumption I know), the aspect is normally set up wider than it is tall. I don't think it makes much sense to have a vertical tools palette because that just gets in the way.
(Why would you possibly add things that were fixed in place and get in the way on the left or the right of the screen when that space is valuable?).
I was actually thinking of something very similar to this idea:

- control-strip.gif (6.25 KiB) Viewed 12927 times
The control-strip from earlier versions of MacOS (what I'd call a '
real mac'

). I'd have the tools laid out horizontally and you could click it to hide and show (as the way it works in MacOS 9, as per the gif). The advantage of that is it gets out of your way when you don't need it, and it's the right orientation for most people's screens from the get-go. (No, I haven't thought about giving myself extra headache and making it adjustable) - it's only an idea in my head at the moment.
This is only a quick mockup, and the icons are just some pixel-art ones I put together quickly. Kind of the thing I was thinking of.
The proper one would probably use some fancy SVG icons of some kind.

- tool-mockup.png (22.01 KiB) Viewed 12853 times
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 3:57 pm
by richmond62
GIMP has a choice of Single-Window mode:
-

- SShot 2025-03-25 at 17.52.50.png (61.59 KiB) Viewed 12699 times
-
C.F. That Create mockup above.
or something a bit more like the current IDE:
-

- SShot 2025-03-25 at 17.53.28.png (180.98 KiB) Viewed 12699 times
-
If 'KREATE' were to have those alternatives that would be super.
I am aware, however, that if the whole thing is to be 'confined' inwith a browser window that will probably not be possible.
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 3:58 pm
by tperry2x
Yeah, I don't like Gimp either.
That's why I use the gimpshop mod.
What is "Kreate"?
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 4:21 pm
by richmond62
Yeah, I don't like Gimp either.
That's why I use the gimpshop mod.
What is "Kreate"?
1. I love GIMP.
2. I like the floating palettes, and dislike the unifoed thing.
3. 'Kreate' is my nickname for what you are making at the moment.
-

- SShot 2025-03-25 at 18.20.16.jpg (98.63 KiB) Viewed 12678 times
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 4:50 pm
by tperry2x
richmond62 wrote: ↑Tue Mar 25, 2025 4:21 pm
3. 'Kreate' is my nickname for what you are making at the moment.
You've just reminded me why software development shouldn't be a community effort.
Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 5:01 pm
by richmond62
You've just reminded me why software development shouldn't be a community effort.
Well, to be honest at the moment it is not: it is 99% Paul and yourself.
And, until you release something for beta testing, this Killer Klown for one, won't start spraying your efforts with popcorn.
Mind you, you have to admit '
webXtalk' could be worse . . .
. . . like '
WebEcstasy' for instance.

Re: The basis for an xtalk engine [I/we] control
Posted: Tue Mar 25, 2025 10:41 pm
by tperry2x
Anyway,
continued from here earlier.
I'm not done with the graphic objects, because I've implemented curves and closed paths:

- throwing-some-shapes.gif (52.85 KiB) Viewed 12272 times
On page 43 and 44, I've added examples (assuming you already made a graphic called "test"):
Re: The basis for an xtalk engine [I/we] control
Posted: Wed Mar 26, 2025 2:52 am
by Kdjanz
The rapid visible progress you are making is absolutely awesome to watch from the sidelines.
Big Cheers!!!
Re: The basis for an xtalk engine [I/we] control
Posted: Wed Mar 26, 2025 3:06 am
by OpenXTalkPaul
tperry2x wrote: ↑Tue Mar 25, 2025 10:41 pm
Anyway,
continued from here earlier.
I'm not done with the graphic objects, because I've implemented curves and closed paths:
throwing-some-shapes.gif
On page 43 and 44, I've added examples (assuming you already made a graphic called "test"):
Hah, excellent! I was thinking the same about 'graphic', it makes sense to use SVG path strings for 'the points', since a list of points is practically what those are already, but with points that can be
curved and such. Preferably it's sideways-compatible with OXT community engines? That uses line breaks to separate points of the list. The difference between them is minor, with the OXT graphics controls if you remove the line breaks, add the 'M' (moveto) at the beginning point, and add 'L' (line to) before each successive point then it becomes a SVG-compatible path string.
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. I think the OXT/LC CE property inspector had too many things crammed into it.
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
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.
4) If they could be flexible enough to be usable on a phone-screen that would be fantastic!
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.
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.
There's a lot of options that can be used with the <img> elements nowadays. You can use SVG as an image now! (I haven't done a lot of 'web stuff in many years, so many of these options are new to me). Besides that 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 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.