Keyboard layout

[richmond62]

So: most of the time use the MacOS US English keyboard layout, occasionally I use the GB English keyboard layout, ad about 20% of the time I use the Bulgarian Phonetic keyboard layout.

I do exactly the same sort of thing on Xubuntu Linux.

Now, in languages such as Lazarus there is a nifty command:

Code: Select all

GetKeyboardLayout

Now were that sort of thing available in OXT it should be able to populate an instack virtual keyboard with buttons mirroring the end-user's physical keyboard.

[richmond62]

https://cplusplus.com/forum/beginner/275268/

[tperry2x]

Please can you try this, and if it works, we could make a custom function quite easily:

Code: Select all

on mouseUp
   put the platform into tPlatform
   if tplatform contains "mac" then
      put "/usr/libexec/PlistBuddy -c 'print " & QUOTE & "AppleSelectedInputSources:0:KeyboardLayout Name" & QUOTE & "' /Library/Preferences/com.apple.HIToolbox.plist" into tCmd
      put shell(tCmd) into tResult
      answer "Current Keyboard Layout: " & tResult
   else if tplatform contains "win" then
      put "powershell -command Get-WinUserLanguageList" into tLayout
      put shell(tLayout) into tResult
      answer "Current Keyboard Layout: " & tResult
   else if tplatform contains "lin" then
      put "setxkbmap -query" into tCommand
      put shell(tCommand) into tResult
      filter lines of tResult with "layout:*"
      answer "Current Keyboard Layout: " & tResult
   end if
end mouseUp

example.png (56.84 KiB) Viewed 714 times

[richmond62]

Screenshot 2024-10-25 at 22.09.56.png (257.56 KiB) Viewed 709 times

-
I wish life were that simple.

[tperry2x]

Hahahah, what the heck is ABC for a layout name?
I'll have to try experimenting with other layouts!

[tperry2x]

Ah, my fault. I left off the tilde ~

Try adjusting it to read:

Code: Select all

on mouseUp
   put the platform into tPlatform
   if tplatform contains "mac" then
      put "/usr/libexec/PlistBuddy -c 'print " & QUOTE & "AppleSelectedInputSources:0:KeyboardLayout Name" & QUOTE & "' ~/Library/Preferences/com.apple.HIToolbox.plist" into tCmd
      put shell(tCmd) into tResult
      answer "Current Keyboard Layout: " & tResult
   else if tplatform contains "win" then
      put "powershell -command Get-WinUserLanguageList" into tLayout
      put shell(tLayout) into tResult
      answer "Current Keyboard Layout: " & tResult
   else if tplatform contains "lin" then
      put "setxkbmap -query" into tCommand
      put shell(tCommand) into tResult
      filter lines of tResult with "layout:*"
      answer "Current Keyboard Layout: " & tResult
   end if
end mouseUp

bulgarian-test.png (80.18 KiB) Viewed 697 times

Fingers crossed...

[OpenXTalkPaul]

on mouseUp
put the platform into tPlatform
if tplatform contains "mac" then
put "/usr/libexec/PlistBuddy -c 'print " & QUOTE & "AppleSelectedInputSources:0:KeyboardLayout Name" & QUOTE & "' ~/Library/Preferences/com.apple.HIToolbox.plist" into tCmd
put shell(tCmd) into tResult
answer "Current Keyboard Layout: " & tResult
else if tplatform contains "win" then

There's probably a few ways to do this on macOS.
Here's a similar shell command that uses the 'defaults' tool (and grep), instead of PListBuddy to parse the key/value from the same file (com.apple.HIToolbox.plist):

Code: Select all

defaults read ~/Library/Preferences/com.apple.HIToolbox.plist AppleSelectedInputSources | egrep -w 'KeyboardLayout Name' |sed -E 's/^.+ = \"?([^\"]+)\"?;$/\1/'

Result:
U.S.
changed to British in System Settings result:
British

Of course you'd have to also do the quoted or escaped form of that for using that with shell() function.

[richmond62]

Ouch:

Many a tilde twixt cup and lip.
-

Screenshot 2024-10-26 at 12.32.10.png (408.86 KiB) Viewed 600 times

-
MacOS 12

[richmond62]

My main desire is NOT really to work out what sort of keyboard layout an end user is using Ding An Sich, but to do something like this:

Warning: pseudocode:

Code: Select all

on rawKeyDown RD
             switch RD
               case "100"
                  put the glyph for my keyboard layout that overlays that rawKeyCode into field "K100"
                  break
                  --- and so it goes
                  end switch
                  end rawKeyDown

BUT: automated, so that end users could see a 'chart' a bit like this:
-

Screenshot 2024-10-26 at 13.01.50.png (88.78 KiB) Viewed 586 times

-
that would "automagically" reflect the end-user's current keyboard layout inwith an OXT stack.

[richmond62]

This is NOT a recent whim of mine, but an ongoing obsession:

https://forums.livecode.com/viewtopic.php?t=36751

[tperry2x]

I just had a bit of a play, making inroads into detecting it.
The problem seems to be that the method for doing this seems to change between MacOS versions.

So far, this is version 2 of the stack to detect the layout.
It seems to detect the correct layout on Windows and Linux, and I've also tested in MacOS 10.9.
I'll try and test in MacOS 12 tomorrow - just might need different methods for different OS / Versions.

The idea is this can eventually be wrapped in a do-it-all function.

Screenshot at 2024-10-28 01-12-46.png (50.42 KiB) Viewed 342 times

keyboard layout test v2.oxtstack

(3 KiB) Downloaded 8 times

EDIT: Have so far confirmed this seems to work under MacOS 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15, 11, and 12.
Edit: works on MacOS 12 as below:

Screenshot.png (118.68 KiB) Viewed 255 times

I know it's probably a different method for MacOS 10.4, as that gives [error -4].
Under MacOS 10.6, you get a different error code: [error -1728], so my point is this can (and does) change between MacOS versions quite a lot.

I'll need someone to please try running the following Applescript under MacOS 13+

I'll also try running this in "Applescript Editor" on various MacOS versions, and see what happens:

Code: Select all

set plistPath to "~/Library/Preferences/com.apple.HIToolbox.plist"
try
	do shell script "defaults read " & plistPath & " dummy"
end try
tell application "System Events"
	repeat with pli in property list items of ¬
		property list item "AppleSelectedInputSources" of property list file plistPath
		try
			return value of property list item "KeyboardLayout Name" of pli
		end try
	end repeat
end tell

Edit 2: Just seen it's working for you Richmond, so that's great news.

[richmond62]

Works PERFECTLY on MacOS 15.1 Sequoia:
-

SShot 2024-10-28 at 11.34.01.png (114.45 KiB) Viewed 288 times

-
Marvellous: Thanks.

[OpenXTalkPaul]

I can confirm the AppleScript works for me on macOS 15.0.1
Result = "U.S."

The only thing I'd be concerned about (beyond one day Apple deciding to deprecate AppleScript) is using "System Events", as I imagine it could trigger some permissions warning if it's coming from an app that's not been granted System Event scripting privileges, or that has accessibility features turned off for whatever reason, or something like that. AppleScript just seems like an unnecessary intermediary in this case since we can get the info using shell() without using AppleScript or System Events at all.

I don't think we need to worry about this working on Mac OS X 10.4 (Tiger, from 2004/05), do we?

As far as the other part, the mapping of 'rawKey' (X.org key mapping) numbers to certain alternate glyphs?
I think that would require some sort of programming/scripting to happen. Actually I would've thought that macOS would already use the correct glyphs for the current input language. Anyway, that 'OnScreenKeyboard' widget that I built last year has a set of default scripts for capturing just about any sort of keyboard input event ( Function-Keys, NumberPads, Command/Control/Option/Alt combos, etc.). The scripts are meant to be starting point for using every bit of an alpha-numeric computer keyboard as possible as an arbitrary input device, for use as a gaming controller, or to input musical notes, or whatever, basically treating the keyboard like a bank of switch buttons. Those default-scripts consists of large pre-made switch/case control structure, but I have another method for mapping keyboard keys to xTalk messages that's quite fast due to using an Array to store the mapping (it can be seen in action in my 'Virtual MIDI Bass Guitar' stack video on YouTube).

[richmond62]

It looks like I will have to have a MONSTER lookup table for each possible keyboard layout because what interests me is NOT whether an enduser's keyboard layout will deliver the charаcters relevant to that language (which I assume it will), but something like this:

Imagine, if you will, an overlay on an OXT card that looks a bit like this (these are screenshots of the MacOS15 keyboard thingy):
-

SShot 2024-10-29 at 11.05.50.png (115.69 KiB) Viewed 164 times

-
US English layout MacOS 15 which changes automatically inwith an OXT stack to this:
-

SShot 2024-10-29 at 11.06.04.png (116.32 KiB) Viewed 164 times

-
when the end-user changes to the SlavonicCY layout (or whatever).

[OpenXTalkPaul]

It looks like I will have to have a MONSTER lookup table for each possible keyboard layout because what interests me is NOT whether an enduser's keyboard layout will deliver the charаcters relevant to that language (which I assume it will), but something like this:

Imagine, if you will, an overlay on an OXT card that looks a bit like this (these are screenshots of the MacOS15 keyboard thingy):
-
SShot 2024-10-29 at 11.05.50.png
-
US English layout MacOS 15 which changes automatically inwith an OXT stack to this:
-
SShot 2024-10-29 at 11.06.04.png
-
when the end-user changes to the SlavonicCY layout (or whatever).

I was thinking I could make it so that you, me or anyone, could attach your own svg-path icons to the keys for that OnScreenKeyboard widget (it would just be replacing an array element in the array that stores the state of each key), but you would have to provide it glyphs sets as some sort of list. Perhaps it could be a simple tab-sep-values list, which is what the OXT SVG glyphs library uses. I wanted to enhance the thing in a similar way already so that the 'alt' and 'option' keys could be labeled with symbols appropriate for a specific OS (for example).