OXT Lite Moving Forward

[tperry2x]

Yeah Code-Signing,...Try building an 'native' app with ...any of others and you will hit the same problems.

Very true, - doesn't stop it being any less annoying, but there's not much alternative as that's the way Apple has gone. Don't get me wrong, I like working on the Mac 90% of the time, just the recent issues had me pulling my hair out. I think I'm over that now I know the process.

No, OXT does NOT have an Apple Silicon native engine, but the Intel based Mac engine runs fine in Rosetta 2

It does, on the only M-series Arm processor I've been able to test it on, it actually seemed to run faster, which would make sense. However, I only mention this as history shows that Apple doesn't support Rosetta forever. It's just one to have on the radar.

...we already have iOS Standalone engine...could be a good template, I was thinking maybe it could even run as 'Catalyst' app (which, if you're not familiar, is Apple's Framework for iOS apps that can run 'native' on macOS Apple Silicon).

I was thinking the same thing a while back, and did mention that here:
https://www.openxtalk.org/forum/viewtop ... 4441#p4441

...may be to totally switch to another open-source xTalk interpreter...I also easily built a 'native' (in that it doesn't require JavaVM to be installed in order to run) OpenXION build with GraalVM 'natifier'...

I believe this to be the simpler route into solving engine problems, rather than having to trawl the engine code as it currently stands. Paul, can you PM me a link / download for the OpenXion build that does not require JAVA please. I would really appreciate this, and I'll have a tinker with it.

I'd also want to be clear that the OnScreenKeyboard widget that I've been developing for the last two weeks or so, had nothing to do with fixing the mentioned crashing bug when using macOS built-in on-screen-keyboard. It was purely coincidence...

Sorry, please don't get me wrong - I love that this is coming along as a widget / plugin, however I didn't make myself entirely clear. I didn't mean your efforts in making this was to solve the bug, more that if the onscreen keyboard exists within OXT, it would negate the need for anyone to turn on the MacOS system one and therefore the crash issue under MacOS would not be apparent. As a side-note, onscreen keyboard such as 'onboard' under Linux work without issue, it's purely a MacOS thing.

From what I understand, FFPLAY (from FFMPEG Team) can be bound a window on Linux, just using shell command switches ... but it would add 10s of 10s of megabytes to the overall package sizes...

Again, I think this would be good just to be aware of it and have it on the to-do-list. It's not necessarily something that everyone would use all the time, but we need to mention that it is capable of completely locking up a distro that isn't 'buntu based.

For Linux it would be great to know if the distro you are using has all of the required dependencies...Just saying that it's VERY broken isn't particularly helpful. I mean I've run OXT on Linux distros where it ran as good as the macOS engine does for me...

Very true. I did point to the dependencies required here:
https://www.openxtalk.org/forum/viewtop ... 4626#p4626
And on this machine I'm currently writing this on (Xubuntu, based on Ubuntu 22.04.3 LTS, both Wayland and X11 tested), it works fine. The issue is with less-common distros with different underpinnings. (Debian, Enlightenment, Devuan, MX-Linux, Solus etc).

On... not-common [distros] I do have those issues, but I kind of expected that...I don't think the source is even fully updated for C++2011 support). What would be helpful would be to create a list of required dependencies and incompatible desktop environment/windowing compositors/etc.

While it works fine on 'buntu-based distros, (and see my point above for required dependencies), as you rightly mention - creating a list of all the ones that it doesn't work on seems to be anything that is not using straight Ubuntu as an underlying base. I have a feeling this is down to differences in the GCC compiler and display managers. In much the same way that VLC works (on anything), including a more recent version not based on QT - so it can play back mkv/m4v/avi/wmv/divx etc, it has all the codecs included in the plugins via the package manager repo. I was wondering if VLC could be contacted to provide a tsv plugin, and we could use their traffic-cone icon, but it would utilite VLC if installed. That way, the only thing the user on linux has to add is VLC and it could pass to their engine for playback? They also get a shoutout / credits (free exposure) in exchange?

As always, just ideas, and things probably worth considering. At least I feel we now have something that runs on all 3 platforms with OXT Lite. I did feel a bit stymied with the 0.94 release (that was kind of my 'Windows Vista' release ), and I think 0.95 is moving a lot closer to where it should be.

[tperry2x]

While experimenting, creating a horizontal inspector...

just-noticed.png (95.01 KiB) Viewed 8818 times

I've noticed that there's something missing from the inspector palette.
For some reason, it's not possible to set a tooltip on a vertical scrollbar object. But, you can set it via script and it'll show in the IDE correctly. My horizontal inspector will have this ability.

It's in the early stages of course, but that's the kind of thing I'm thinking. The idea will be that you should be able to get to all the options you need on any selected object, without having to click through various tabs like you currently have to with the inspector.

[richmond62]

As a side-note, onscreen keyboard such as 'onboard' under Linux work without issue, it's purely a MacOS thing.

Pardon me for "protruding", but since 1993 I have often had recourse to the MacOS Keyboard viewer, and have NEVER had any problems with it, and, when over on the Debian/Xubuntu side have constantly used Onboard.
-

MacKB.jpg (240.03 KiB) Viewed 8815 times

-
So, what exactly is the problem that requires effort to build a new on-screen keyboard?

[richmond62]

The issue is with less-common distros with different underpinnings. (Debian

I think you will find that Xubuntu's underpinnings are exactly Debian.

[tperry2x]

I think you will find that Xubuntu's underpinnings are exactly Debian.

They do use a different compiler, canomical drivers for a few things, and a few different branches of essential libraries. Enough to make a huge difference.

[richmond62]

Aha.

I do know (for what its worth) that Debian 12 with XFCE 32-bit runs LC 963 without a hitch, except the messageBox will not receive focus.

Which, quite obviously, is a pain in the bum as it means that for any script I would normally run in the messageBox I have to script a button.

[tperry2x]

Ah, okay - thanks for letting me know. I've made a note of that and will get that ticked off the list too.

[OpenXTalkPaul]

If this is true, then why is that card not hidden away?
-
SShot 2023-11-06 at 10.40.40.png

Why not hide the iOS standalone building tab/card?
Because there are other ways to get an iOS App on to your iDevice and run it.

I was just reading an article from 2011 that said the real issue/ reason you will never see non-Apple iOS realtime app building tools that actually run on iOS, on the App Store is because they don't allow Apps that can execute external code like from a file (script/stack), which is also the reason why you won't see classic hardware emulators on Apple's AppStore.
All of these restrictions, jumping through hoops, it's really the reasons I'm considering going back to Android for my next mobile devices (plus I'm excited about fold-out phone/phablet screens and Apple currently isn't).

There is an 'xCard' app called NovoCard I bought on the crAppStore a while back, but it doesn't really have a scripting language, it's more or less a UI oriented database making app. The closest you can *officially* get to 'live coding' on iOS will always be whatever Apple offers ( iOS Swift Playground app) or via a web app (which is good argument for porting some of the IDE to run on the Emscripten engine, should be doable based on tests using 'OXT Playground'). IF someone were to port the IDE to run on iOS, it would have to be "side-loaded" (via Xcode and a Apple Dev Account, Jailbroken/'root' user, hosted on a 3rd part "AppStore" like Cydia, or some other method.

[OpenXTalkPaul]

So, what exactly is the problem that requires effort to build a new on-screen keyboard?

I wasn't trying to fix that problem with the IDE (which I can confirm did crash for me too using Apple's on-screen keyboard as input device with OXT on BigSur) . I just wanted a keyboard I could script in real-time (or as close as possible) the visual highlighting of keys for several use-cases I had in mind, and I finally figured out a workaround for Extension Builder's 'OnKeyPress' syntax not actually working, so I pulled it all together (mostly using Piano Widget as a template) into a Widget. It's working fairly well now. Like I said the problem is OnKeyPress, it doesn't actually recieve any keyboard input messages.

So... to have a (non-native/non-FFI) widget that appears to receive keyDown/keyUp, rawKeyDown/Up, enterKey, etc. messages what I wound up with is the partial beginnings of xTalk parser/interpreter written in Extension Builder. You can forward any keyboard messages to the widget using Extension Builder's OnDo' handler. I've included default scripts that look like this:

Code: Select all

on keyDown pKeyChar
   do keyDown && pKeyChar in me
end keyDown

The OnDo handler on the Extension side receives a string, for example 'keyDown p' or 'rawKeyDown 32', splits it by the space char, and then looks for the key by name or by character code (number) and highlights/unhighlights that key in the widget accordingly. You can also set the vKeysDown property to highlight keys arbitrarily, which works with the same format as 'the keysDown' (char code numbers), like so:

Code: Select all

on rawKeyDown
   set the vKeysDown of me to the keysDown
end rawKeyDown

This widget does not (currently) generate its own key messages (like keyDown), it only sends virtuaKeyDown/Up and normal mouse messages. I suppose it could still be used to build an in-IDE OnScreen keyboard, but my intention was to use it as visual feedback, and for dialogs or pop-up 'menu stack' for setting up keycombos (acceleratorKeys), in the vein of 'Answer Color', like 'Answer keyCombo'.

[tperry2x]

This is all good stuff, and I'm always intrigued as to what can be done.
I'm keen to make most things preferences, so people can tweak the IDE to how they see fit.

After much head-scratching this evening, I've fixed the Ubuntu-only error of the message box not being able to receive focus. Weirdly, the issue wasn't actually the message box in the end. The inspector was continuously stealing focus, but only when inspecting the stack. (if you inspect an object such as a button or a field, it's fine).

As you can see in this screenshot (xubuntu), I have resolved it and the message box receives focus nicely:

Screenshot_2023-11-29_23-07-20.png (732.65 KiB) Viewed 8786 times

It turned out to be a 3 line fix.
This will be patched in the next update.

Screenshot_2023-11-29_23-02-26.png (16.78 KiB) Viewed 8786 times

[OpenXTalkPaul]

Terry stated that the rebranding was done.

Um:
-
Screenshot 2023-11-05 at 20.13.02.png
-
Screenshot 2023-11-05 at 20.15.51.png
-
Screenshot 2023-11-05 at 20.19.25.png

I just recently did some more updating of the docs. at some point I may have inadvertently overwritten some newer version with some older, unedited version.
Mostly I edited or replaced some of the 'Guides' images to removed graphical 'LiveCode' mentions (logos and such).
There will still be some mentions of LiveCode, I mean LCC is the progenitor of OXT, we need to give credit where its due.
In my dictionary builds you will also find glossary terms for HyperCard, SuperCard, Oracle Media Objects, OpenXION, StackSmith, and others, and of course OpenXTalk. I also fixed some 'debranding' that I had missed in a few of the included Libraries/Widget Extensions docs, like in the DataGrid docs for example. I just pushed some of these changes to the repos on github this morning.

[OpenXTalkPaul]

It turned out to be a 3 line fix.
This will be patched in the next update.
Screenshot_2023-11-29_23-02-26.png

Nice work, thanks!
There was a similar focus issue that turned out to be coming from a different IDE stack stealing focus, between Tools palette and the Message Box that I had running on Windows.

[OpenXTalkPaul]

Even a large amount of the files inwith the engine that do NOT end with .rev or .livecode seem to be writtein in xTalk:
-
SShot 2023-11-24 at 13.06.53.png
-
Erm . . . "teardown".

Teardown is NOT mentioned in the LC Dictionary: are we to conclude that there are parts of xTalk that LiveCode have kept to themselves?

Certainly if that is true, and the xTalk language is open source, we ought to be able to ask them for a COMPLETE list of xTalk terms, and should sowe caan get on with things.
-
SShot 2023-11-24 at 13.12.37.png
-
Well, possibly, but a term used at the end of an xTalk script in a totally decontextualised fashion it is ever so slightly difficult to understand.

This looks like that is something used by the IDE/Engine testing tools, which is probably why there's no complete handler in that script. It's a domain specific subset they used for testing, that's my guess. 'teardown' could be a call to a command handler 'on teardown'.

But there are bits of xTalk syntax in the Engine that aren't documented, usually with names like __internal..., while there's also syntax that IS documented but either no-longer functional (Answer Record), or was only ever a 'stub' left in the language for (non-functional) compatibility with other xTalks dialects.

[OpenXTalkPaul]

Quoting myself here:
https://www.openxtalk.org/forum/viewtop ... 4247#p4247
A bit like talking to myself, except other people are also cc'd in.

I wonder @Paul, could the "org.openxtalk.library.macosnativeapptools.lci" be adjusted to colourise the background popup buttons to grey as per in the screenshot, or the post above?
pop-menu.png
I assume this was a MacOS 10.15 and above theme change by Apple, as before that, the button text colour was always black, if I recall?

Is it possible to make a "org.openxtalk.library.windows10plusnativeapptools.lci" as well that can support dark titlebars (and out-of-focus / background window - dark titlebars)?

A 'native' (using FFI) capable popup menu widget could be created. I do want to rebuild new alternatives to all of the builtin 'classic controls'. The problem with 'native' controls is they don't render properly when you are in Stack editMode. It would be best if they were all 'hybrid controls' that used the best method available based on 'the platform' AND the editMode. There exist examples widgets that change appearance depending on 'the platform', but they are not 'native', and don't use FFI for real OS 'native' control if available.

You CAN edit the default properties for the 'classic controls', They are read into the IDE from tab-separated-value lists. That's the concept I was testing when I included the 'macOS Style' 'classic' control Button in OXT DPE. You can also use scripts for some parameters for the Property Inspector so maybe that could likely be used to set the colors at the time of creation of the control.

'org.openxtalk.library.windows10plusnativeapptools.lci'
I started something like that at one point, but never added much to it. Trevor DeVore has some Windows FFI experiments in his repos. But don't hold your breath for darkMode window frames on Windows 10, I don't think there is an 'official' public API for that built into Windows 10 (but in Windows 11 there is)... basically the same reason that the 'darkMode' handlers in Mac native tools lib won't function as expected on macOS 10.7 though 10.13.a

[OpenXTalkPaul]

I believe this to be the simpler route into solving engine problems, rather than having to trawl the engine code as it currently stands. Paul, can you PM me a link / download for the OpenXion build that does not require JAVA please. I would really appreciate this, and I'll have a tinker with it.

I don't know if using OpenXION engine would be simpler, at least not in the short term, unless you are only interested in a command-line interface xTalk. The nice thing is that, like HyperCard did, it allows for built-in syntax ('reserved keywords' like 'Play' or 'Answer') to be overridden. But I also think that StackSmith by Uni Kusterer is probably a better choice as a replacement engine that already supports 'live' GUI editing, although the license to this work isn't entirely clear to me, there's no license file in the GitHub repo for that stuff ( and he's got a few other very interesting to me repos).

I have been meaning to upload that 'standalone'/native (macOS Intel64) build of OpenXION. I''ll try to remember to do that when I get home tonight. I used GraalVM & 'Nativefier' tool to create it, will need to do the same for other platforms/CPU architectures. I also like to make its syntax available from a Web browser. I should also move the XION scripting experiments I did here: https://github.com/OpenXTalk-org/OpenXt ... XION_Stuff into a proper OXT+OpenXION repo.

more that if the onscreen keyboard exists within OXT, it would negate the need for anyone to turn on the MacOS system one and therefore the crash issue under MacOS would not be apparent. As a side-note, onscreen keyboard such as 'onboard' under Linux work without issue, it's purely a MacOS thing.

I wonder if it's not a permissions/security thing? Like do apps now need to declare that they allow text input from other apps or allow Assistive Services, similar to the way that AppleScript and JSX needs Assistive Services on in order to use AS UI scripting features on recent macOS versions. If it's something like that we could at least get the IDE to handle that case gracefully rather than just crash.

As for using this virtual keyboard widget as mouse-click-to-character input device, strictly within the IDE or your stacks, currently in the widgets script you would need to handle its virtualKeyDown/Up messages that it sends and then 'send' the corresponding 'keyDown'/'keyUp' messages to your target scriptObject...now that I think about it, I could probably make 'the object to send key messages to' be a set-able widget property). Theoretically it could work for that purpose, and I do want to make it more versatile for use-cases I haven't thought about.

If you'd like to beta test it out or just see how it's built or whatever, there's now a repo for it here (ignore that the readme doc there is from PianoWidget):
https://github.com/OpenXTalk-org/OpenXT ... enKeyboard

[OpenXTalkPaul]

I just now noticed this repo from the creator of OpenXION:
https://github.com/RebeccaRGB/keyboards

There's even a Commodore 64 keyboard layout in there, lol, awesome!

[tperry2x]

..I also think that StackSmith by Uni Kusterer is probably a better choice as a replacement engine that already supports 'live' GUI editing, although the license to this work isn't entirely clear to me, there's no license file in the GitHub repo for that stuff...

Thanks for that - I'll have to have a look at this. I wonder if he can be contacted and see if he'd have any objections to us using it? - or even join the OpenXTalk effort!

I have been meaning to upload that 'standalone'/native (macOS Intel64) build of OpenXION. I''ll try to remember to do that when I get home tonight. ... will need to do the same for other platforms/CPU architectures. ...into a proper OXT+OpenXION repo.

That would be excellent, just so I can have a play with it really. This would be a great inroad into an xtalk language, in the same way that Python console is. No GUI but is useful for command-line-only output. A basic version without all the overheads of OXT, yet enough to offer a taster into it. If you could compile it for all 3 architectures, I'd really appreciate that. We could even wrap a stack / standalone around it so that there's a GUI of sorts - so users/students/pupils (whatever) can enter a command and see the output underneath (just thinking many schools and organisations don't allow access to command prompt / terminal / shell to be opened directly), so this is a way of demo'ing xtalk without needing to worry about those restrictions.

(Onscreen keyboard)...I wonder if it's not a permissions/security thing? ...If it's something like that we could at least get the IDE to handle that case gracefully rather than just crash.

That would be good. As you observed, it just spontaneously quits the IDE on MacOS.

[tperry2x]

I couldn't help noticing from someone else's other screenshot (posted somewhere else on another topic, I forget exactly where), that some people turn off the toolbar icons and only show the 'Toolbar text'.

I was trying this myself and found a bug.
Previously, it would do this if you toggled it:

01_toolbar-bug-before.gif (38.2 KiB) Viewed 8756 times

But I've now fixed it, and it behaves as expected:

02_toolbar-bug-after.gif (37.57 KiB) Viewed 8756 times

This is only because there's a slightly different routine called when drawing the toolbar when the IDE is starting up, as opposed to changing and redrawing the toolbar after the IDE has already loaded.

This bug fix will be included in my next lot of changes.

[micmac]

Hi tPerry

This one is a confirmation dialog after msg History has been deleted

Mic

[micmac]

Skærmbillede 2023-11-27 kl. 14.37.53.jpg (210.18 KiB) Viewed 8748 times

Hi tPerry

This one is a confirmation dialog after msg History has been deleted

Mic