The basis for an xtalk engine [I/we] control
Forum rules
Please limit any bashing/harping on any commercial interests to a minimum, thanks!
Please limit any bashing/harping on any commercial interests to a minimum, thanks!
-
- Posts: 16
- Joined: Thu May 05, 2022 9:02 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
If you go to System Preferences -> Keyboard -> Keyboard Shortcuts -> App Shortcuts -> Safari -> [+] you can change the Minimize command shortcut to something else. Then command M will show the message box in the simulator instead. It drove me crazy always doing it...
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The basis for an xtalk engine [I/we] control
Aye, but . . .
It might be slightly unrealistic to expect end-users all to do that.
It might be slightly unrealistic to expect end-users all to do that.
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 3493
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The basis for an xtalk engine [I/we] control
Typical. That sounds very much like a MacOS problem then. I'll keep it ctrl M for everything in that case.OpenXTalkPaul wrote: ↑Fri Apr 11, 2025 11:50 pm Adding Command+M for Mac won't work for in-Browser context on macOS because the browsers treat ou[r]'web stacks' like any other document window in an app and so it minimizes the window into the Dock. It's a problem with HyperCard Sim and Emscripten Engine too. Something other than Cmn+M, like command+option+shift+M might work.
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The basis for an xtalk engine [I/we] control
Sensible.I'll keep it ctrl M for everything in that case.

Except for kinky characters like Uncle Richmond (who skips merrily back and forth between Macs and Linux) who has played "silly buggers" with the key layouts on ALL his Macs:
- -
And a Very Happy Saturday morning to Thee . . . and here he is, the original thorn in the flesh.

https://richmondmathewson.owlstown.net/
- OpenXTalkPaul
- Posts: 2812
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
I've always done the reverse, make Linux file manager and other key commands on Linux use the macOS keyboard positions for special modifier keys, ergonomically I think it's better, and it's what my muscle memory has been programmed with for 35+ years, so....richmond62 wrote: ↑Sat Apr 12, 2025 7:18 amSensible.I'll keep it ctrl M for everything in that case.![]()
Except for kinky characters like Uncle Richmond (who skips merrily back and forth between Macs and Linux) who has played "silly buggers" with the key layouts on ALL his Macs:
-
Screenshot 2025-04-12 at 10.19.25.png
-
And a Very Happy Saturday morning to Thee . . . and here he is, the original thorn in the flesh.![]()
Anyway, I think this is the correct behavior as 'web apps' are basically web browser documents windows, if you want desktop app behavior you need to build a desktop app (or wrap the web app with one, like Electron or similar).
But I've had to switch back and forth between platforms enough that I can manage the occasional left-hand rotate + extra stretch from Control to the M key with thumb + middle fingers on one hand (the right hand is for the mouse).
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
- tperry2x
- Posts: 3493
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The basis for an xtalk engine [I/we] control
Since Linux and Windows use ctrl, and MacOS uses CMD, then it's 2 against one. Three against one if you count Haiku (which I am)
Hiding message box, ctrl M, and running the script I typed in the message box (even if it's hidden) ctrl return / enter.

Hiding message box, ctrl M, and running the script I typed in the message box (even if it's hidden) ctrl return / enter.
-
- Posts: 133
- Joined: Sat Oct 16, 2021 5:05 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
Thanks Tom for the syntax clarifications. I've updated to WebTalk-131. As you post webtalk doc.pdf's, I'll try to keep the dict-database updated, new entries at the top next time. Ask with multiple entry field support, nice.
- Attachments
-
- WebTalk Dict.zip
- (6.95 KiB) Downloaded 110 times
- OpenXTalkPaul
- Posts: 2812
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
It's fine, same as HC Sim used, and then if I want to minimize my web-tinkering sesh its the normal minimize command key. It would bother me in a mac desktop standalone app though.tperry2x wrote: ↑Sat Apr 12, 2025 7:48 pm Since Linux and Windows use ctrl, and MacOS uses CMD, then it's 2 against one. Three against one if you count Haiku (which I am)![]()
Hiding message box, ctrl M, and running the script I typed in the message box (even if it's hidden) ctrl return / enter.
hiding-message-box.gif
On OS level as long as we can set modifier keys the way one likes on the system then it doesn't matter so much.
- tperry2x
- Posts: 3493
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The basis for an xtalk engine [I/we] control
Well, for better or for worse - depends on your outlook - the parser, tokenizer, and lexer approach isn't going to work I feel - not for a javascript implementation. I've been struggling with it for the best part of a month now and it's never going to be up to par with the regex version I made previously.
I'm going back to version 132 where I used a regex version.
I'll copy 133 and all my incremental changes I've done into that shared folder Paul, and you and Dan can work on it from now on. Feel free to do what you want with it. Put it in github, whatever.
I'll continue with my regex version (possibly for my own amusement only) from now on.
I'm going back to version 132 where I used a regex version.
I'll copy 133 and all my incremental changes I've done into that shared folder Paul, and you and Dan can work on it from now on. Feel free to do what you want with it. Put it in github, whatever.
I'll continue with my regex version (possibly for my own amusement only) from now on.
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The basis for an xtalk engine [I/we] control
You could provide some 'amusement' for some other people by releasing this into the wild . . .I'll continue with my regex version (possibly for my own amusement only) from now on.
https://richmondmathewson.owlstown.net/
-
- Posts: 133
- Joined: Sat Oct 16, 2021 5:05 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
Tom, awaiting your return to resume development of WebTalk. Standing by....
- OpenXTalkPaul
- Posts: 2812
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
Same here. I really want some more UI objects to play with. As far as parsing script goes I really don't care which unerlying method(s) are used, and for the most part I can adjust to work with differences in an interpreter (such as not using elaborate compound chunk expressions in a single line of script), it wouldn't be the first time I've had to, but writing xTalk scripts isn't nearly as much fun with only a few basic objects to manipulate, and I'm excited to see what sort of NEW features can be added as a result of having a web browser as the back end 'engine' (like text fields on an angle or curved path, or 3D transforms for image controls). In the meantime I'll continue to play around with SimpleTalk or modifying HC Sim, since those are also built on top of JavaScript/HTML at least some of it should be useful for 'webtalk'.
- OpenXTalkPaul
- Posts: 2812
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
A shame he's going back to the regex method, because Tom's Lexer/Parser version was a bit better than Dan's @dandandandan HC Sim interpreter in that it could properly return the correct value for the following example:
put item 2 of line two of "hell,o" & return & "wor,ld"
Result = "ld"
HyperCard Sim result for the same chunk expression:
Result = "
wor,ld"
(including a line break)
which is obviously incorrect.
ViperCard returns the same result as HC Sim parser
https://www.vipercard.net/0.3
I was trying to add the constant values '\n' for 'cr' (carriage 'return') and '\r' for lf (linefeed) and '\n\r' (should that be the other way around, are both ever even needed anymore?) for crlf since I've become accustomed to using those constants instead of HyperTalk's because they're shorter to type.
put item 2 of line two of "hell,o" & cr & "wor,ld"
Doesn't work in either interpreter at the moment.
put item 2 of line two of "hell,o" & return & "wor,ld"
Result = "ld"
HyperCard Sim result for the same chunk expression:
Result = "
wor,ld"
(including a line break)
which is obviously incorrect.
ViperCard returns the same result as HC Sim parser
https://www.vipercard.net/0.3
I was trying to add the constant values '\n' for 'cr' (carriage 'return') and '\r' for lf (linefeed) and '\n\r' (should that be the other way around, are both ever even needed anymore?) for crlf since I've become accustomed to using those constants instead of HyperTalk's because they're shorter to type.
put item 2 of line two of "hell,o" & cr & "wor,ld"
Doesn't work in either interpreter at the moment.
- tperry2x
- Posts: 3493
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The basis for an xtalk engine [I/we] control
OpenXTalkPaul wrote: ↑Sat Apr 26, 2025 1:34 am A shame he's going back to the regex method, because Tom's Lexer/Parser version was a bit better than Dan's @dandandandan HC Sim interpreter in that it could properly return the correct value for the following example:
put item 2 of line two of "hell,o" & return & "wor,ld"
Result = "ld"
HyperCard Sim result for the same chunk expression:
Result = "
wor,ld"
(including a line break)
which is obviously incorrect.
ViperCard returns the same result as HC Sim parser
https://www.vipercard.net/0.3
I was trying to add the constant values '\n' for 'cr' (carriage 'return') and '\r' for lf (linefeed) and '\n\r' (should that be the other way around, are both ever even needed anymore?) for crlf since I've become accustomed to using those constants instead of HyperTalk's because they're shorter to type.
put item 2 of line two of "hell,o" & cr & "wor,ld"
Doesn't work in either interpreter at the moment.
You can use:
Code: Select all
put "hell,o" & return & "wor,ld" into tString
put item 2 of line 2 of tString
I was in two minds about whether to contribute here anymore. As I mentioned, feel free to use the last version I gave you of webtalk (134 I think), and put it into github, or whatever you want to do with it. Rename it / rebrand it if you want.
What is currently 'webtalk', I'll continue with on my own fork over at:
https://www.tsites.co.uk/sites/other/other.php
That page will be changed with my updates.
-
- Posts: 170
- Joined: Mon Sep 13, 2021 9:46 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
Tom, it appears as something has hurt or offended you. Can that be overcome or sorted out?
Mic
Mic
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The basis for an xtalk engine [I/we] control
I would hope you are considering adding these as ALTERNATIVES and not REPLACEMENTS, as, surely the main idea is to ensure that OXT-web does not diverge any more than is inevitable from what we might call "the common heritage".since I've become accustomed to using those constants instead of HyperTalk's because they're shorter to type
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The basis for an xtalk engine [I/we] control
- -Tom, it appears as something has hurt or offended you. Can that be overcome or sorted out?
I very much hope not.
Turn Again, All is Forgiven: We Love You:
-
https://richmondmathewson.owlstown.net/
- OpenXTalkPaul
- Posts: 2812
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: The basis for an xtalk engine [I/we] control
Yah sure, just like legacy OXT/LC Engine these are synonyms for the HyperTalk equivalents. MC/RR/LC about 30 years ago already diverged from HyperTalk which is forever stuck at v2.4.1. So for example you can use the keyword 'part' OR 'control' and they refer to the same thing, same with 'cr' or 'return' constants, this is already true of the legacy engine as well.richmond62 wrote: ↑Sun Apr 27, 2025 9:01 amI would hope you are considering adding these as ALTERNATIVES and not REPLACEMENTS, as, surely the main idea is to ensure that OXT-web does not diverge any more than is inevitable from what we might call "the common heritage".since I've become accustomed to using those constants instead of HyperTalk's because they're shorter to type
- richmond62
- Posts: 5258
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The basis for an xtalk engine [I/we] control
Of course there is the inevitable stage in any sort of development when we ask WHAT purpose an appendix serves beyond giving people appendicitis, and its presence does NOT stop fundamentalists from insisting that God made mankind 'Crash-Bang-Wallop' a few years back . . .
. . . as long as something residual does NOT cause the computational equivalent of a burst appendix keep it, but when keeping it becomes counter-productive, or even destructive, let's remove it.
Reminds me of when they removed 'LET' from BASIC: I for one sighed a huge sigh of relief.
. . . as long as something residual does NOT cause the computational equivalent of a burst appendix keep it, but when keeping it becomes counter-productive, or even destructive, let's remove it.
Reminds me of when they removed 'LET' from BASIC: I for one sighed a huge sigh of relief.

https://richmondmathewson.owlstown.net/
Who is online
Users browsing this forum: No registered users and 3 guests