OpenXTalk Forums

A forum for xTalk discussion
https://www.openxtalk.org/forum/

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

https://www.openxtalk.org/forum/viewtopic.php?t=1211

Page 4 of 14

Re: The basis for an xtalk engine we control

Posted: Sat Mar 15, 2025 8:07 pm
by OpenXTalkPaul
If you look at the JSON of one of the speech voice-objects you can see they have properties that indicate male/female/neutral, language, and region. This is important if you want pronunciations of specfiic words to sound a certain way. I'll often use an Female Australian English Voice for text-to-speech because it amuses me (I don't know why), but if I use something like a Female Chinese Mandarin or Male Brazilian Spanish voice then some word sound 'like arse' when trying to pronounce English words (also funny to me).

I don't know why Debian Linux browser wouldn't work for web speech, perhaps something to with Debian being strctly FOSS oriented/liscense issues? Or perhaps it doesn't install or doesn't turn on 'assistive technologies by default? I know Gecko (Firefox) engine counts on there being a TTS voice installed in the OS. I thought Google's Chrome used its own voices, but I could be wrong.

You're right It seems that the voice names returned by the API are formatted in a way that is inconsistent from one Browser engine to the next, but it's always some comination of a human name and optionally male/female/neutral, language, and regon (dialect). I don't think it matters much though because to select a voice the API takes the voice-object list index number, not a name, so you have to iterate through that list to find the voice object that matches it.

HyperTalk used 'the voice' for the selected voice, revSelectedVoice is the OXT engine equivelant.

HyperTalk:
speak tText with <gender> voice
the speech
stop speech
the voice to <voiceName>
the voices -- returns voice list
Also used soundChannel volume (iirc)
I think in HC 2.4.x there was some improvements to the syntax.

OpenXTalk:
revSpeak
revStopSpeech
revSetSpeechVoice voiceName
revSpeechVoices([voiceGender])
revLoadSpeech
revUnloadSpeech
revSetSpeechProvider speechProvider
revSetSpeechSpeed wordsPerMinute
revSetSpeechVolume volume
revSetSpeechPitch pitchLevel

I'm not sure which would be best to try to support, or maybe can create syntax-aliases to support multiple xTalk dialects?
Of course for revWhatever equivalents I would want to drop the 'rev' prefix, scripts would just need to search+replace " rev" with " ".

BTW, I noticed webtalk interpreter currently does not allow to use the function() format for properties.
put the platform --- works fine
put platform() -- does not work at all

I'm still using v100 so you probably fixed some things since with v104.

Re: The basis for an xtalk engine we control

Posted: Sat Mar 15, 2025 8:21 pm
by OpenXTalkPaul
I think the most important will be 'open (file,URL,etc) as well as import and export syntax. With those added one could get pre-written script files and media assets into play. I have code that does some of this using JavaScript already in the OXT Web Playground, but those would need to be adjusted to fit this interpreter. I'm going to try to work on that if I have some time this weekend.

Re: The basis for an xtalk engine we control

Posted: Sat Mar 15, 2025 8:59 pm
by tperry2x
Version 105
Implemented the "loc" property (location for objects).
So, I tested this with:

Code: Select all

create button "test"
put the loc of button "test" -- Returns the x,y position of the button's center
set the loc of button "test" to "200,200" -- Positions button with its center at 200,200
I also began work on tool modes, as it seemed a necessary thing when messing about with objects. We can now run:

Code: Select all

choose browse tool -- the default, where you click and interact with objects
choose pointer tool -- akin to edit mode, where you drag objects around the card
As well as "choose [x] tool", you can set the mode instead (which runs the same command):

Code: Select all

set the mode to browse -- same as "choose browse tool"
set the mode to edit -- same as "choose pointer tool"
I did some more work to object logic. For example, setting the script of our newly created button above to:

Code: Select all

on mouseEnter
   set the top of me to 20
   set the left of me to 20
end mouseEnter

on mousedown
   set the top of me to 100
   set the left of me to 400
end mousedown
As you'd expect, that now moves the button around the card upon the mouse entering it, and when it's clicked. (It understands the context of what "me" is) - which was actually quite hard.

Added a checkbox in the bottom left of the script editor that allows you to toggle autocomplete on/off. The checkbox is unchecked by default, so autocomplete suggestions won't appear until this is turned on.
When enabled, eventually the autocomplete will suggest keywords and functions as you type.
You'll be able to navigate the suggestions using arrow keys and select with Tab or Enter.

I also fixed a visual issue with the script editor, as it had an overprinting text layer.
2025-03-15-20-32-48.png
2025-03-15-20-32-48.png (50.6 KiB) Viewed 18241 times

Re: The basis for an xtalk engine we control

Posted: Sat Mar 15, 2025 9:02 pm
by tperry2x
OpenXTalkPaul wrote: ↑Sat Mar 15, 2025 8:07 pm BTW, I noticed webtalk interpreter currently does not allow to use the function() format for properties.
put the platform --- works fine
put platform() -- does not work at all
I'm still using v100 so you probably fixed some things since with v104.
Ah - well spotted.
Fixed, and added the test for this in "testing2.html" in version 106:
2025-03-15-21-01-23.png
2025-03-15-21-01-23.png (36.87 KiB) Viewed 18235 times

Re: The basis for an xtalk engine we control

Posted: Sun Mar 16, 2025 12:35 pm
by tperry2x
Perhaps a bit out of curiosity, for my own amusement (but not for much other reason) - I wondered just how far back this implementation could be run.
Seems like it'll run on OSX 10.7 - as that's the minimum requirement for "Waterfox Classic". 10.6 won't cut it it seems.
But, runs on there fine:
OSX107lion-webtalk.png
OSX107lion-webtalk.png (259.62 KiB) Viewed 17250 times
Runs under Haiku too, (not with WebPositive, but with IceWeasel) - interesting that the speech support is also not included as default.
haiku.png
haiku.png (72.86 KiB) Viewed 16931 times

Re: The basis for an xtalk engine we control

Posted: Sun Mar 16, 2025 3:15 pm
by tperry2x
OpenXTalkPaul wrote: ↑Sat Mar 15, 2025 8:21 pm I think the most important will be 'open (file,URL,etc) as well as import and export syntax. With those added one could get pre-written script files and media assets into play. I have code that does some of this using JavaScript already in the OXT Web Playground, but those would need to be adjusted to fit this interpreter. I'm going to try to work on that if I have some time this weekend.
Yes, that needs adding and is important (well, it all is)...I'll need to add the CORS header that you mentioned Paul, and see if that allows what I need. I know you said you'd have a look at loading other formats, so I don't want to tread on your toes or duplicate work you have already done - so I may hang-fire on that, and carry on with my object properties get/set tasks & the saving/loading of stacks.

When I messaged Dan last (dandandandan), he suggested using JSON format rather than XML, so I'd like to try this approach first using the JSON format.

Re: The basis for an xtalk engine we control

Posted: Sun Mar 16, 2025 9:05 pm
by tperry2x
I know it'll sound crazy, and you will probably think I'm not right in the head... well, okay - that's probably obvious by now, but I'm actually enjoying this process in a strange kind of way.
Yes it's a huge task, but the point is it's progress.

Here's some changes I made this evening / night:

Version 107
I wanted the interpreter to allow me to be a bit more "fuzzy" when I reference lines of a string:

Code: Select all

put "apple" & return & "banana orange" & return & "cherry grape kiwi" into tString
put word 1 of line 3 of tString into tResult -- two line conditions at the same time
put tResult
outputs:

Code: Select all

cherry

Code: Select all

put word 2 of line 2 of tString into tResult -- two line conditions at the same time
put tResult
outputs:

Code: Select all

orange

Code: Select all

put word 3 of line 3 of tString into tResult
put tResult
outputs:

Code: Select all

kiwi
So, then I remembered that HyperTalk allows you to use first, second, third etc - so added this:

Code: Select all

put "dog" & return & "cat mouse" & return & "fish bird snake" into tString
put first word of third line of tString into tResult -- phonetically referencing
put tResult
put second word of third line of tString into tResult
put tResult
put first word of second line of tString into tResult
put tResult
this would output:

Code: Select all

fish
bird
cat
Then I implemented "last" keyword for lines in strings:

Code: Select all

put "cat" & return & "snake dog chicken" & return & "elderly people" into tString
put first word of first line of tString into tResult
put tResult
put second word of second line of tString into tResult
put tResult
put last line of tString into tResult -- now knows about "last line" of...
put tResult
outputs:

Code: Select all

cat
dog
elderly people
Version 108
Added the backgroundColor (and synonym backgroundColour):

Code: Select all

create button "test"
set the backgroundColor of button "test" to "255,0,0" -- set background RGB values
set the backgroundColour of button "test" to "Green" -- background color, named ref
put the backgroundColour of button "test"
So it also made sense to add the foregroundColor (and synonym foregroundColour) at the same time, as in:

Code: Select all

create button "test"
set the foregroundColor of button "test" to "255,0,0" -- set foreground RGB values
set the foregroundColor of button "test" to "Red" -- Named color
set the foregroundColour of button "test" to "Blue" -- UK-English colour, named ref
get the foregroundColor of button "test" -- we can get using US spelling of property
get the foregroundColour of button "test" -- we can get using UK spelling of property

Baby steps ;)
baby-steps.png
baby-steps.png (16.06 KiB) Viewed 16530 times
I know this is a bit sad, but bear-with this old fool. I'm just pleased to be heading in the right direction with it.
a-bit-sad.gif
a-bit-sad.gif (17.83 KiB) Viewed 16499 times
Okay - I'll keep my posting a bit more infrequent because this could get annoying :D

Re: The basis for an xtalk engine we control

Posted: Mon Mar 17, 2025 6:31 pm
by OpenXTalkPaul
Just pasting this here temporarily, not ready for use, it's like a prototype. I was JS tinkering a little this weekend:

Code: Select all

             // Handle open command
              if (script.startsWith('open ')) {
                  const expr = script.substring(5);
                  if (expr.startsWith('file '))
                    {
                      const theParam = expr.substring(5);
                      const element = document.getElementById('inputData');
                      if (element) {
                        inputData.click();
                      // Element exists, proceed with operations
                      console.log('Element exists!');
                      const fileInput = document.getElementById('inputData');
                      console.log( fileInput.files[0] );
                      } else {
                        console.log('Element does not exist.');
                      //  <input type="file" id="fileInput" name="fileInput" accept="image/*">
                        var oxtInputFileDiv = document.createElement('div');
                         oxtInputFileDiv.setAttribute('style','display:none');
                         var inFileForm = document.createElement('form');
                         var inFileInput = document.createElement('input');
                         inFileInput.setAttribute('id','inputData');
                         inFileInput.setAttribute('type','file');
                         inFileInput.setAttribute('accept','image/*');
                         // inFileInput.setAttribute('onchange','this.it');
                         inFileForm.appendChild(inFileInput);
                         oxtInputFileDiv.appendChild(inFileForm);
                         document.body.appendChild(oxtInputFileDiv);
                         inputData.click();
                         const fileInput = document.getElementById('inputData');
                         console.log( fileInput.files[0] );
                      }
                    return 'file ' + theParam;
                    }
                  else {
                    return expr;
                  }
              }
It's really a prototype for 'answer file' more than it equates to 'open file'

Re: The basis for an xtalk engine we control

Posted: Mon Mar 17, 2025 9:19 pm
by tperry2x
Ah, thank you Paul.
That's kind of along the same lines I was thinking. I definitely need a Save file / Load file dialog. I've just uploaded my most recent changes (v111) and the documentation (as I make it at the same time) to go along with it.

Please have a look at stack.js as I was about to implement a stack save and load using this.
When objects (buttons and fields) are created via script now, they are registered with the DOM and WebObjects - as are any custom properties and their appearance, position etc (In preparation for some kind of inspector).

Thought I'd share this with you though. You can also have rotated text fields that remain editable:
fields.png
fields.png (38.85 KiB) Viewed 14364 times

Re: The basis for an xtalk engine we control

Posted: Mon Mar 17, 2025 11:02 pm
by OpenXTalkPaul
tperry2x wrote: ↑Mon Mar 17, 2025 9:19 pm Ah, thank you Paul.
That's kind of along the same lines I was thinking. I definitely need a Save file / Load file dialog. I've just uploaded my most recent changes (v111) and the documentation (as I make it at the same time) to go along with it.

Please have a look at stack.js as I was about to implement a stack save and load using this.
When objects (buttons and fields) are created via script now, they are registered with the DOM and WebObjects - as are any custom properties and their appearance, position etc (In preparation for some kind of inspector).

Thought I'd share this with you though. You can also have rotated text fields that remain editable:
fields.png
Hah rotated text fld, brilliant! That is a good example of one of the benefits of building an xTalk/xCard on top of common browser engine because that is something the OXT Engine needs an add-on / extension to do while modern Browser engines can already do that (and a lot more transforms) using built-in CSS features.

Super fun!

Code: Select all

create field "test"
put 180 into tAngle
set the angle of field "test" to tAngle
repeat 90
   put tAngle +10 into tAngle
  set the angle of field "test" to tAngle
  put tAngle into field "test"
wait 1 tick
end repeat
Yeah I was a little unsure about how / where in your code should I put functions I add like for reading files from disk.
I would think it would be best to have it match a command ('answer') and then in the same block parse the next word to check if it's one of the specialized forms of it ('answer file', 'answer color', 'answer password', etc.).

The other thing about 'answer' command is that with dialogs boxes, at least simple ones, you could've used the JS standard dialogs instead of creating custom dialog boxes, what I mean is:

Code: Select all

result = alert("I am an alert box!");
and

Code: Select all

confirm("Press a button!")) {
    txt = "OK!";
  } else {
    txt = "Cancel!";
}
Agree with it or not (I don't) that is the way 'Answer' was (partially) implemented with for the LC/OXT Emscripten Engine.
Personally I would want to add all of the specialized version of 'Answer' even 'Answer Record' which became non-functional in OXT due to it's reliance on Apple's Quicktime.

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 1:55 am
by OpenXTalkPaul
tperry2x wrote: ↑Sun Mar 16, 2025 3:15 pm When I messaged Dan last (dandandandan), he suggested using JSON format rather than XML, so I'd like to try this approach first using the JSON format.
JSON is what StackImporter CLI tool, used by various projects, outputs, so that makes sense to use it for that reason alone. I prefer clearly labeling of data fields so I like the more human-readable quality of xml or yml tagging. JSON is more efficient bytes-size-wise. XML can be converted to JSON. I can go with whatever for a stack file format so long as it's version control (Git) friendly and preferably human readable to some degree.

At the moment I'm just trying to get a working 'ask-file' and have it read a file of text, load the data into the it variable in memory and then put it into 'message box'.

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 10:41 am
by tperry2x
Version 112
Added "the name of me" for objects. As in:

Code: Select all

put the name of me
On my to-do list next: I've got to also add the setting of the name of me, or the setting of the name for <object> too.
(Object renaming, which also needs to update the DOM and the WebObjects when a name change occurs, as this is used to track what's on the card)

I also cleaned up the script editor. It now gets the indentation correct for else if conditions.
I added a "format" button, in case you paste text in from somewhere else, you can get it to tidy up the formatting with this button. (in case anyone is wondering, I did intentionally move the 'format' button away from the cancel button by some distance. My logic is that it would be really annoying if you'd made a load of changes, went to click 'format' and accidentally hit the cancel button instead!) - although the script editor should do a good job of trying to sort the formatting out 'live' for you now, as you type.

I do want to get the formatting of what's between quotes correct too, but I'm getting there.
name-of-me.png
name-of-me.png (29.72 KiB) Viewed 13028 times
If I go a bit quiet on the editing / updating front, it's only because I have a house-move happening and we are doing a lot of paperwork and are tied up with that.

Edit: Just being trying out your example script Paul. I love the fact that I hadn't yet tried putting it in a repeat loop, but it works (no reason why it shouldn't of course), but watching it do that, makes me wonder about adding something else.

You know how you can set the hotspot of an image in xTalk (such as one used for a cursor) - and this is where the 'click' point is regarded as being as. I was thinking about implementing a centerpoint keyword - so that you can control where the object would spin from (rather than top left).
Was thinking it would be handy for rotating a svg graphic of a spinning progress indicator for example.

edit 2:
I've left this in ("it's a feature, not a bug") :lol:
Although it's going to be specific to my webtalk implementation. (But as it's mine, I feel I can act on my own whims!)
feature-not-a-bug.png
feature-not-a-bug.png (9.35 KiB) Viewed 12787 times
You can rotate a button just as you can a field. Might not have much use to people, but someone out there may want to do it one day!

This is also where I can revisit my idea of sideways buttons (tabs) as I was thinking about implementing in the OXT Lite IDE. The only difference there is I have to clumsily export an image of the button, rotate that sideways, then set the image of the tab to that rotated button. I can't just rotate the button directly of course like I've done here.

But if we can get save and open of stacks in JSON format sorted, there's no reason we can't have this load a stack so it builds a tools palette using xTalk script directly now. Then we can have our rotated "Tools" button on the left so you click that for available tools (currently only browse and edit mode).

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 3:38 pm
by OpenXTalkPaul
Two comments on your last post;
1)
when a name change occurs, as this is used to track what's on the card)
Unique part-id number is how script-objects have traditionally tracked, that way the name can change anytime. It's also handy for inspecting a stack wen you want a list all of the controls in a stacl but you have no idea what they're named or what sort of object it is (btn,fld,grp,grc,wgt).
2)
The center-point for objects is already syntax in xTalks, it's the part/control'/object's loc property.
But you're saying have an additional property, similar to the clickPoint for cursors, that would be the origin point / axis for transforms like setting angle? (and hopefully other transforms to come, skew, perspective vanish point)
Or maybe have it be an option for a rotate or other transform commands? Basically would be much like the sort of thing as Canvas syntax Extension Builder module.
Somthing like this psudo code:
rotate [object] by [angle] at [point... from topLeft?]
Rotate tMyBtn by 90 at 30,30

I question topLeft there, because IIRC, origin point differences is one of the things that made it a little tricky to use some of Apple's CoreImage stuff with OXT. Most XTalks I believe have consistently use topLeft as an origin point for drawing things. But I know some software exists that use lower-left-origin coordinate system (LLO).
Just checked, yup Apple's Quartz and CoreImage use lowerLeft. https://developer.apple.com/library/arc ... forms.html

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 4:52 pm
by tperry2x
OpenXTalkPaul wrote: ↑Tue Mar 18, 2025 3:38 pm Unique part-id number is how script-objects have traditionally tracked, that way the name can change anytime.
That is a good point. At the moment they are just being tracked by name, but I can get them to assign ID numbers and track that way. See "objects.js" line 337 for an example where they are being deleted from the internal map:

Code: Select all

static deleteObject(name)
OpenXTalkPaul wrote: ↑Tue Mar 18, 2025 3:38 pm The center-point for objects is already syntax in xTalks, it's the part/control'/object's loc property.
But you're saying have an additional property...Something like this psudo code:

Code: Select all

Rotate tMyBtn by 90 at 30,30
Yes, I like that idea better. If no loc is specified when setting an angle or rotation, then at the moment it's just rotating from topleft. I didn't specifically choose this, just what the default seems to do. I like the idea of using an optional [at] qualifier to rotate at a certain point.

So if I used:

Code: Select all

set the angle of fld "test" to 20 at 20,20 -- rotates from 20px left and 20px top of the topleft of the object.
but If I used:

Code: Select all

set the angle of fld "test" to 20 -- then it should rotate about it's center point (it's loc).
OpenXTalkPaul wrote: ↑Tue Mar 18, 2025 3:38 pm I question topLeft there, because IIRC, origin point differences is one of the things that made it a little tricky to use some of Apple's CoreImage stuff with OXT. Most XTalks I believe have consistently use topLeft as an origin point for drawing things. But I know some software exists that use lower-left-origin coordinate system (LLO).
Just checked, yup Apple's Quartz and CoreImage use lowerLeft. https://developer.apple.com/library/arc ... forms.html
I'd normally want to measure from topleft since screenrects are topleft (well, actually left,top) but it would give consistency. Since most xTalks are also measuring from topleft as you say, then I think that's what I should possibly go with? I'm not building this specifically for Apple devices - as much for Linux and Windows too.

I'm going to make a to-do list which I'll put in the shared folder we are working in.
It'll be in Libreoffice ODT format (so we can paste in graphics and such) - but it's purely to organise my tasks so I know what I'm working on next and can cross them off.

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 6:18 pm
by OpenXTalkPaul
Oh don't get me wrong. I think leftTop is the most common, leave it to Apple to do things different(ly) than everyone else, for no particular reason as far as I can tell. Unless the reason is related to Display Postscript used on NeXT step (as I suspect). But I think leftTop is most common. It would be easiest to use what browsers engines use. But good to be mindful that the format of things like origin point, or for another example the format of a rectangle, can be different from one programming language to the next.

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 7:01 pm
by TerryL
I don't know if it helps, but attached is .txt of all the math functions to use as a check-off list, and a few math functions I wrote. Rotated field/btn...Wow!

Re: The basis for an xtalk engine we control

Posted: Tue Mar 18, 2025 9:14 pm
by tperry2x
TerryL wrote: ↑Tue Mar 18, 2025 7:01 pm I don't know if it helps, but attached is .txt of all the math functions to use as a check-off list...
OMG (as the kids say)
Wow. That's certainly food for thought!

Checking through your list, this is what I don't have:
()
acos(0.866025) *180/pi --30 deg
avg(10,20,25) --18.33
10000/annuity(.07/12,36) --308.77, $10k@7%3yr
arithmeticMean(10,20,25) --18.33
asin(0.5) *180/pi --30 deg
atan(0.57735) *180/pi --30 deg
atan2(2,1) --63.434949 deg, =atan(y/x)
averageDeviation(10,20,25) --5.555556
avgdev(10,20,25) --5.555556
baseConvert(11100,2,16) --1c, bin>hex
baseConvert(28,10,16) --1c, dec>hex
baseConvert("1c",16,10) --28, hex>dec
ceil(33.25) --34, integer up
ceiling(33.25) --34, integer up
3000*compound(.01,1) --3030, $3k@1%1yr
floor(33.25) --33, integer down
geometricMean(10,20,25) --17.10
harmonicMean(10,20,25) --15.79
isnumber(10) --true
ln(2.718282) --1, e^y=x
ln1(2.718282) --1.313262, = ln(x+1)
log10(100) --2, 10^y=x
log2(100) --6.643856, 2^y=x
matrixmultiply(tArray1,tArray2)
max(10,20,30) --30
mean(10,20,30) --18.33
median(10,20,30) --20
min(10,20,30) --10
set the numberFormat to "#.00" --money
set the numberFormat to "0.####" --<=4 dec
set the numberFormat to "0.0000" --=4 dec
popStdDev(8,10,12) --1.63
populationStandardDeviation(8,10,12) --1.63
populationVariance(8,10,12) --2.67
popVariance(8,10,12) --2.67
sampleStandardDeviation(8,10,12) --2
sampStdDev(8,10,12) --2
sampleVariance(8,10,12) --4
sampVariance(8,10,12) --4
standardDeviation(8,10,12) --2
statRound(10.5) --10, even down, odd up
stdDev(8,10,12) --2
variance(8,10,12) --4
vectordotproduct(tArray1,tArray2)

This is what I do have so far:
+ - * / ^ < = <> >
abs(-10) --10
average(10,20,25) --18.33
cos(30 *pi/180) --0.866025, 30 in radians
exp(1) --2.718282, e^x
exp1(1) --1.718282, e^x-1
exp2(3) --8, 2^x
exp10(2) --100, 10^x
"10" is a number --true
ten is a number --true
"ten" is a number --false
len(1234) --4
length(1234) --4
10 mod 3 --1, division remainder
random(25) --integer 1 to 25
random(16)+9 --integer 10 to 25
round(10.5) --11, rounds up
round(10.5678,2) --10.57, round to precision
sin(30 *pi/180) --0.5, 30 in radians
sqrt(9) --3
sum(10,20,30) --60
tan(30 *pi/180) --0.57735, 30 in radians
trunc(10.5) --10
value(2*4) --8


mind = blown!
Certainly saved for when I next want a headache. Thank you though. (I think :lol: )

Certainly, thank you for the example functions and tests too. I'd be lost without those.

Re: The basis for an xtalk engine we control

Posted: Wed Mar 19, 2025 11:46 am
by tperry2x
Version 113
Added the acos math functions to the interpreter (Thanks TerryL).

I've also reorganised the entire DOM and WebObjects map so they work with IDs as well as object names (in tandem).

Also added the renaming function, as in:

Code: Select all

set the name of button "test" to "renamed"
set the name of btn id 2 to "renamed again"
Or in the script of an object:

Code: Select all

on mousedown
  set the name of me to "blah" 
end mousedown
You can now also get by ID in the script of the object itself too:

Code: Select all

on mouseup
   put the id of me into tID
   put tID
end mouseup
...and rename by ID too:

Code: Select all

on mouseup
   put the id of me into tID
   set the name of button id tID to "new"
end mouseup
Boring bit:
Worth mentioning; when a button is renamed, the event handlers remained attached to the original DOM element, but the script lookup used the new name. This was the: executeObjectScript method in interpreter.js. Now, when the user renames a button via script, it updates the DOM element's dataset and the objects map, but the event handlers still referenced the original name that was used when the button was created. I then modified the event handlers to use the updated reference, to ensure mouse events keep working on the renamed object.

I did extensive testing as I was trying to confuse it, but seems to pass all these tests:

Code: Select all

create button "test"
put the id of button "test" into myID
set the name of btn id myID to "renamed"
set the width of btn id myID to 400
set the name of btn id myID to "original"
put the name of btn id myID
renaming.png
renaming.png (28.89 KiB) Viewed 11004 times
testing-id.png
testing-id.png (19.8 KiB) Viewed 11004 times

Re: The basis for an xtalk engine we control

Posted: Wed Mar 19, 2025 2:08 pm
by richmond62
Where can we download THIS from so we can:

1. Experience it for ourselves.

2. Give (constructive) feedback.

?

Re: The basis for an xtalk engine we control

Posted: Wed Mar 19, 2025 2:34 pm
by tperry2x
Nowhere yet.
(not sure I'm ready for constructive feedback).
All times are UTC
Page 4 of 14

Powered by phpBB® Forum Software © phpBB Limited