On-screen keyboards . . .

[richmond62]

While Android and iOS have built-in on-screen keyboards that OXT can call, that can adapt themselves to whichever keyboard layout the end-user has selected in their system settings.

AND while it is comparatively easy enough to set up an OXT palette as a floating on-screen keyboard for any desktop system, there seems no obvious way that keyboard can adapt itself to an operating system's selected keyboard layout . . .

[tperry2x]

On which OS?
If you want to reconfigure them on Linux, there's a whole guide on it here - either through the terminal or via a GUI.

Then if you are using something like onboard, onscreen keyboard viewer, the layout will of course change to however you've modded your keys:

efdk0w2z1wi71-123611517.png (82.12 KiB) Viewed 5226 times

[richmond62]

What I was really asking is if there be a way OXT can detect what keyboard layout an end-user is using on their desktop machine so a palette keyboard authored in OXT can set its buttons to reflect that.

[tperry2x]

Ah, I see. I think we covered this before - but here you are again:

example.png (26.03 KiB) Viewed 5081 times

Then, once you know your keyboard layout, you'd have to position your keys manually via scripting.
(much easier to use the built in / already existing onscreen keyboard viewers that are available).

[richmond62]

Hey-Ho:
-

Screenshot 2025-03-04 at 15.45.34.png (94.7 KiB) Viewed 5162 times

-
MacOS 12

That has been tested with US English and Sanskrit.

[tperry2x]

Hang on... let me go find a mac and go test it...

[tperry2x]

Don't have much time to fool around and waste with MacOS at the moment, but this is the applescript that will do it:

applescript.scpt.zip

(585 Bytes) Downloaded 135 times

Have updated my screenshot accordingly.

[richmond62]

Don't have much time to fool around and waste with MacOS at the moment

emphasis mine.

Presumably working with Windows and Linux does NOT constitute either fooling around or wasting time.

That works.

What that does NOT do, and will NOT do is inform a stack of buttons how to label those buttons.

[tperry2x]

I did put that in deliberately.

Presumably working with Windows and Linux does NOT constitute either fooling around or wasting time.

Emphasis mine
Yes, because at least on Linux and Windows, the goalposts are not constantly being moved.
I had my hands in a laminator, repairing that, so was a bit pre-occupied. Since I seem to be the only person responding to most stuff on here, then it seems up to me to come up with options.

What that does NOT do, and will NOT do is inform a stack of buttons how to label those buttons.

No, it won't. You are quite right.
That's also why I mentioned it's far better to just show the onscreen keyboard viewer that's part of the system (or at least outside OXT / LCC) - far easier. This is the approach taken with Android and iOS, just because then otherwise you have the added 'fun' of manually moving all the buttons (and images that make up the onscreen keys) around via script - which I mentioned above.

In fact, I knew we'd covered this before. This was the oxtstack that worked on MacOS previously.

macca.png (126.68 KiB) Viewed 5024 times

[richmond62]

I had one seriously odd boy who came to my schoolette for English for about 7 years who managed to screw 2 laminating machines . . . eventually he got 'wented' for making off-colour remarks about a cousin of my wife's breasts . . . having ballsed up high school he now sells Yugio cards in a murky shop in a murky part of term.

So when it comes to opening up laminating machines and attempting to get off the plastic that has bonded with the heated roller I do sympathise.

But, having watched my Primary teachers 'at it' in the 1960s with laminators, at 42, when I opened my school, buying a laminating machine was almost as ecstatic as seeing the Ancient of Days approaching in a cloud of angels.

[tperry2x]

Funnily enough, before I started my current job 8 years ago, my predecessor was "encouraged to leave" under no uncertain terms for doing things like this.
He took apart a 3D printer (and bear in mind, 3D printers were quite new back then, so they cost quite a hefty amount). He of course couldn't get it back together, so it sat in a pile of parts until I started.

So yes, quite odd what people get up to.

Anyway, the necessary staff have been laminating exam posters to their hearts content all afternoon. I did give them specific instructions to ensure one piece emerges fully before they attempt to shove another piece in, but time will tell whether or not they will listen to instructions.

Anyway, back on-topic.
Because there's also quite a few methods of modifying your actual keyboard layout on both Linux and Windows (so you might press a physical key on the keyboard inscribed with H, but if you've used third-party software, modified it in a config file, or changed your windows registry), what might actually be output could be anything.

So, how to tell what that might be? - Because the methods of modifying this are numerous, it's also not a simple task of just inspecting an xmodmap file (or equivalent) because there are multiple places to tinker with it, so I'd suggest calling up either the built in on-screen viewer, alternative third-party one, or one from a repository (linux) - after all, why reinvent the wheel when someone else has already done the hard work. I can't speak highly enough of onboard for Linux. It's always worked flawlessly for me.

[richmond62]

Anyway, the necessary staff have been laminating exam posters to their hearts content all afternoon. I did give them specific instructions to ensure one piece emerges fully before they attempt to shove another piece in, but time will tell whether or not they will listen to instructions.

Nothing like a hypocritical bunch of teachers who will go ape-shit if some pupil does not listen to instructions.

[tperry2x]

Don't have much time to fool around and waste with MacOS at the moment...

In fact, picking up from my own comment, I don't know. Seems sad that once I considered MacOS to be head-and-shoulders above the rest of operating systems. There was a time where it far surpassed Linux and Windows for both ease of use, speed, efficiency and was my go-to-OS.
It's a shame to see what it has now become. A locked-down, dumbed-down, shadow of it's former self. Yes, there all these snazzy features being added - but generally the UI is as clear as mud in many programs, a lot of key features have been removed throughout it, and now the OS gets in your way constantly. Coupled with removing support for programs running on Intel chipsets - developing for this OS is something I really need to consider if it's worthwhile going forward.

Which brings me to another point, probably worth it's own topic: factoring in all these hurdles, surely that's going to put off anyone developing a 'native' app for MacOS with our IDE too. That also makes a strong case for something running in-browser (even if it's local with no internet).

Yes, I realise I've made an entire 360 degree turn on this. That is, if MacOS support matters in future.

[richmond62]

if MacOS support matters in future

I am not sure: but about 20% of the children who attend my language school have Mac laptops.

This depends an awful lot on what end-users aim at: and with Open Source software it will be very difficult to determine.

Just as, at the moment, I have absolutely no idea whatsoever if anyone is producing any standalones for any platform with OXT Lite apart from myself.

[tperry2x]

Just as, at the moment, I have absolutely no idea whatsoever if anyone is producing any standalones for any platform with OXT Lite apart from myself.

Other than you or me, probably not. I have no delusions of grandeur: I doubt many people at all are actively using it. After all, LCC was a bit niche, so OXT is going to be even moreso. Then some people might not like the idea or direction I've gone with a certain feature within OXT Lite (but it's impossible to please everyone), so it's even more niche still (niche-er'r??).

Never mind.