Messing about in the engine

[tperry2x]

After v1.10 of OXT Lite, which I made available for download yesterday, I want to turn my attention to the engine.

I've been poking about in there this evening, and have identified a few things initially.
Firstly, (and again - sorry if this is old news). There's a hex encode and decode function embedded into the engine.
It's not a documented feature, so I thought I'd copy the code for it (externalise it) into this stack (attached). We could probably write a dictionary entry for it and add it as a function in the ide:

hex-encode-decode.png (16.08 KiB) Viewed 2230 times

[tperry2x]

Second thing. Paul mentioned that the Window Name (I assume under x11 window managers) in Linux, sometimes comes through as "Livecode_community_engineversion" - although this is normally hidden under most linuxes (replaced with the human-readable window name), I've replaced the word "livecode" with "xTalk_IDE"

name-anything.png (31.47 KiB) Viewed 2227 times

I'm aware this makes for a rather strange window class name, but my intention is mainly just to get the branding "Livecode" out of there. Not currently sure where it's pulling the "community" keyword from (take your pick!)
I've increased the engine version to "9.7.0-dp-2", but I don't know if I'll keep this naming scheme. Will probably stick with 9.7.x but use "9.7.x-OXT-1" to denote it's an OXT engine.

[tperry2x]

If you've ever wondered how the engine converts RGB colour references to web #ff000 equivalents (I know - all the time right? ) this is how. (I'm abstracting useful things I find, that I think might prove useful as example stacks).

rgb-to-html.png (10.94 KiB) Viewed 2011 times

RGB to HTML.oxtstack

(12.5 KiB) Downloaded 39 times

So, logically - here's how you convert back from a web html colour reference to RGB:

web to rgb.oxtstack

(1.03 KiB) Downloaded 41 times

[tperry2x]

Year 2038 problem. Like the y2k bug, and there's another one in 2106 too.
Assuming anyone is still using OXT in 13 years time, seems to pass the test here.

I mention it, as there's a bit built into the engine source, which stops it compiling if the test fails. I've externalised this into a stack so you can test your own systems.

2038-problem.png (30.03 KiB) Viewed 2000 times

2038 problem.oxtstack

(3.6 KiB) Downloaded 41 times

Just adjusted the test for the 2106 bug, and it does fail this. So the engine won't compile after 7th of February 2106 at 06:28:15 (Not that it affects us).

2106-bug.png (8.92 KiB) Viewed 2000 times

Also be aware you can't perform date calculations past this date in scripts.

[richmond62]

I resent that remark: 7th February 2106 will be my 144th birthday: I have already planned the party.

[richmond62]

If you could upload the version to test for 2106 that would be a great help, as I need to know if I have to buy a new computer before then.

I do NOT understand the checkbox that, whether I check it or not goes 'fail' for 2038; although the details look alright:
-

SShot 2025-01-10 at 9.11.24.png (53.15 KiB) Viewed 1963 times

[richmond62]

There's a hex encode and decode function embedded into the engine

And its probably (?) in the engine because the engine needs it: but what possible utility it can have for end-users of OXT is not clear.

Something that is some ways would be more useful would be a routine to convert Hexadecimal and Decimal numbers back and forth for nutcases like me who spend half their creative lives up to their 'prawns' in the joys of the Unicode Consortium's code charts.

Why the Unicode Consortium cannot do us all a favour and issue their charts with the glyph addresses in Decimal I just don't know.

While I may be a bit abnormal in some respects I do not suffer from the Polydactyly that the Unicode Consortium obviously expects me to:
-

polyD.jpg (3.6 KiB) Viewed 1962 times

-

SShot 2025-01-10 at 9.22.48.png (74.43 KiB) Viewed 1962 times

-
Sometimes I get 119F-ed off fooling around with Hexadecimal numbers.

[richmond62]

Doing some 'coal mining' of my own:
-

SShot 2025-01-10 at 9.36.30.png (83.98 KiB) Viewed 1960 times

-
While this stack comes from the 970 engine the fact that it uses the text 'Revolution' would argue it has been sitting around for a fairly long time.

Another giveaway is the date 2008.

HOWEVER, I wonder if it can be used to extend the capability of OXT to cope with Unicode 16 and the upcoming 17?

The BIG PROBLEM will ALWAYS be to keep up with all those moving fences.

[OpenXTalkPaul]

Second thing. Paul mentioned that the Window Name (I assume under x11 window managers) in Linux, sometimes comes through as "Livecode_community_engineversion" - although this is normally hidden under most linuxes (replaced with the human-readable window name), I've replaced the word "livecode" with "xTalk_IDE"
name-anything.png

I'm aware this makes for a rather strange window class name,
...

Cool. I've been thinking about the engine sources a lot lately too. I think it would be great to build a map of this rather large project starting from 'main' and figuring out what each and everysingle file is there for, what it does, why its written the way it is written (before we go trimming any fat and accidentally sever something we didn't know was important).

For window class name de-branding how about using just xTalk instead of 'xTalk_IDE' or better yet characters like 'xt' or ' _', or maybe " ": or nothing at all? (that's probably not a good idea for a class name). I say that because it would need to have a non-'IDE' class-name for standalone engine created windows, I see no reason to introduce a difference between the IDE engine windows class-name and its corresponding standalone engines window class name.

[OpenXTalkPaul]

There's a hex encode and decode function embedded into the engine.
It's not a documented feature, so I thought I'd copy the code for it (externalise it) into this stack (attached). We could probably write a dictionary entry for it and add it as a function in the ide:

hex-encode-decode.png

I think many functions in the engine are used in multiple ways by the engine.
This function you came across is probably used by baseConvert and/or binaryEncode / binaryDecode which can be used for ascii+ chars to hex, decimal to hex, bytes to number, etc. etc. There are other functions in the engine that I'm not sure that xT script has access to, like certain functions related to character encodings (things like converting Wndows 'WIDE string' chars to UTF-), but I could be wrong. I still find syntax in the dictionary that I never knew was in there, lol.

'External' to the engine the 'printf' command line / ansi C function can typically be used for some similar data format conversions as well.

[OpenXTalkPaul]

I've mentioned this before... On certain window compositors like the one used by Budgie desktop and some others, when you try to use a the Browser widget you can see a 'phantom' window is opened. I believe this phantom window is where the 'off screen' rendering (even if it's incorrectly showing up on-screen as a window) takes place before it's funneled into the widgets view area rect. Playing around with this 'phantom' window, i realized when the browser widget loses keyboard input focus, that it is because the keyboard focus actually should be on this phantom window (which again, that window is not supposed to be visible on screen). If I click into this phantom window, the widget placed on my card regains keyboard input focus, So that is the crux of the problem with Browser Widget on Linuxes, and it also probably affects any other thing that uses a 'Native Layer' to pull in rendering from another process, the CEF web engine in this case, and I suspect the 'Player control' problems are related as well.

[tperry2x]

Digging around in the engine is very worthwhile, even if making sense of it (to a newcomer like myself) is a slow process.

Thanks to Mark Wieder, (who very obviously knows his way around the engine), for this:

Code: Select all

specialfolderpath("Documents")

fix on Linux.

Added into the engine source, compiled, and will be bundled with OXT v1.11 when that is ready.

specialfolderpath-documents.png (9.57 KiB) Viewed 1877 times

[FourthWorld]

There's a hex encode and decode function embedded into the engine.
It's not a documented feature, so I thought I'd copy the code for it (externalise it) into this stack (attached). We could probably write a dictionary entry for it and add it as a function in the ide:

In the example stack, hexEncode is a scripted function which uses the documented binaryEncode engine function.

Did I miss something?