New keyboard install not visible, MacOS 26.3.1

[scalwo]

Hello, I have been using my ukulele keyboard for 5 years, and I tried to make a few new modifications.  However, my computers cannot see the new layouts.  I have tried two computers (both running OS 26.3.1).  I have tried the user Library/Keyboard Layouts and the global /Library/Keyboard Layouts folders.  I have tried in a bundle and as a standalone .keylayout.  I have tried a layout based on my 5-year-old layout (still working fine on both computers).  I have tried a new layout based on ABC - Extended with a few minor letter swaps.

Does anyone have any idea what the problem could be?

Thank you!!!

[John Brownie]

On 8 Mar 2026 at 08:33:18, scalwo <scottaw...@gmail.com> wrote:

Hello, I have been using my ukulele keyboard for 5 years, and I tried to make a few new modifications.  However, my computers cannot see the new layouts.  I have tried two computers (both running OS 26.3.1).  I have tried the user Library/Keyboard Layouts and the global /Library/Keyboard Layouts folders.  I have tried in a bundle and as a standalone .keylayout.  I have tried a layout based on my 5-year-old layout (still working fine on both computers).  I have tried a new layout based on ABC - Extended with a few minor letter swaps.

Does anyone have any idea what the problem could be?

I haven’t heard of other people having problems in macOS 26, but not everyone has moved there yet — many people keep older versions running. So at first thought, it might be a problem with the keyboard layout. If you can send it to me, I can see if there’s anything wrong with it. If it’s in a bundle, compress it to a zip file first.

John

[Gé van Gasteren]

1. Hi, I can confirm that Ukelele’s layouts can be installed in 26.3.1 and work as expected.

I just did "New from current input source", made a few modifications, changed the name, then installed it using Ukelele’s Install command.

After logging out and back in to my user’s account, I could add the new layout to the menu; I’m typing with it now.

Two random thoughts that come up:

• Have you renamed the new version of the keyboard using Ukelele’s menu command Keyboard > Set Keyboard Name and Script…  ?

If not, macOS can easily get confused and decide to list only one of the installed keyboard layouts.

• Maybe installing your layout with Ukelele’s Install function works better? For one thing, that will prompt you to log off.

2. Something off-topic for John: 

One change I made was to add a phrase I use often to one key. 

But when I used that key in TextEdit, the app crashed. (Other keys worked fine.) 

I have saved the crash report; what caught my eye was this text in it:

Application Specific Information:
stack buffer overflow

Details: I ventured to live dangerously (for once…) and assigned a phrase longer than 20 characters to the key, just to see what would happen.

When that crashed TextEdit, I did the whole thing again, this time assigning the same phrase except the last few characters.

That still crashed TextEdit.

Third try: The phrase I assigned previously started with a space character, so on a hunch, I left that off this time around. Result: TextEdit is happy.

Conclusion: If this behaviour can be replicated, you might consider converting the assigned character string, or pop up a warning.

By the way, I just read in the PDF manual:

Note that there is a maximum of twenty UTF-16 code points that can be produced by a

single key. If you try to make it more than twenty, Ukelele will tell you that it cannot do this.

Obviously, that isn’t the case anymore.

I haven’t tried what happens when I assign a >20 char phrase that doesn’t start with a space…

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ukelele-users/CAC13VMzmjK8tzFvG-9AA%2BRQsnsgcZLTdroX%3Dpv0XtXjrfWbfbQ%40mail.gmail.com.

[scalwo]

Here is a layout I was unable to see as a Keyboard Input Source when I put it in Library/Keyboard Layouts.

Thank you!!!

[Gé van Gasteren]

On Sun, Mar 8, 2026 at 5:08 PM scalwo <scottaw...@gmail.com> wrote:

Here is a layout I was unable to see as a Keyboard Input Source when I put it in Library/Keyboard Layouts.

 

Hi Scalwo,

Your attached keyboard can’t be the one you were working on, I think, can you check again?

Its name is "Untitled" and it looks completely empty when I open it in Ukelele:

To view this discussion visit https://groups.google.com/d/msgid/ukelele-users/6ca6589a-4c8c-4735-9793-3280952341fen%40googlegroups.com.

[scalwo]

Gé - 

I don't know what happened, I've always got confused about the keyboard file structures.  Here is another one, it is bigger, so I hope this is it.

Thank you!!!

[Gé van Gasteren]

On Sunday, 8 March 2026 at 19:58:06 UTC+1 scalwo wrote:

Gé - 

I don't know what happened, I've always got confused about the keyboard file structures.  Here is another one, it is bigger, so I hope this is it.

Great, this one looks better :-)

On first glance, it looks like ABC – Extended.

Anyway, I opened and installed it with Ukelele, logged out and back in, and lo:

Note that .keyboard layouts don’t carry any language information or icon with them; if you want that, you need to contain them in a .bundle – or, in Ukelele terms, a keyboard layout collection.

[Gé van Gasteren]

Oh, wait: I just realized that macOS 26 requires custom keyboard layouts to be inside a bundle.

Which means, in practice, that you can "activate" .keyboard files (as I showed in my last post) but in spite of that, it doesn’t appear on the drop-down menu.

So I put your layout in a bundle and then I could install and activate it, and it appears on the menu:

Note that it has a generic icon to it.

Adding its own icon would have been more work, so I skipped that, seeing that this your keyboard layout doesn’t look like a final version ;-)

By the way, custom keyboard layouts can’t have icons in the same style as the System keyboard layouts.

[scalwo]

Thank you Gé, my error was thinking that since I was starting my new layout from an en language layout that the language would carry over.  Your picture showing it in the "Others" language tipped me off.

Thank you for your time!!!

[Gé van Gasteren]

On Sun, Mar 8, 2026 at 10:17 PM scalwo <scottaw...@gmail.com> wrote:

Thank you Gé, my error was thinking that since I was starting my new layout from an en language layout that the language would carry over.  Your picture showing it in the "Others" language tipped me off.

 

All right, I learned something too!

If you haven’t worked with bundles/layout collections before, you’re in for a smoother ride if you take a look at section 6.4.1 in the PDF manual (available from Ukelele’s Help menu).

[John Brownie]

On 8 Mar 2026 at 15:40:17, Gé van Gasteren <gevang...@gmail.com> wrote:

2. Something off-topic for John: 

One change I made was to add a phrase I use often to one key. 

But when I used that key in TextEdit, the app crashed. (Other keys worked fine.) 

I have saved the crash report; what caught my eye was this text in it:

Application Specific Information:
stack buffer overflow

Details: I ventured to live dangerously (for once…) and assigned a phrase longer than 20 characters to the key, just to see what would happen.

When that crashed TextEdit, I did the whole thing again, this time assigning the same phrase except the last few characters.

That still crashed TextEdit.

Third try: The phrase I assigned previously started with a space character, so on a hunch, I left that off this time around. Result: TextEdit is happy.

Conclusion: If this behaviour can be replicated, you might consider converting the assigned character string, or pop up a warning.

By the way, I just read in the PDF manual:

Note that there is a maximum of twenty UTF-16 code points that can be produced by a

single key. If you try to make it more than twenty, Ukelele will tell you that it cannot do this.

Obviously, that isn’t the case anymore.

I haven’t tried what happens when I assign a >20 char phrase that doesn’t start with a space…

That is true, that somewhere in the various rewriting of Ukelele, the check for long strings was lost. I’ve gone and fixed that now. I haven’t tried whether having a string more than one character and up to 20 starting with a space, but that is something to check. It shouldn’t be a problem in theory, but we’ll have to see in practice!

John

[John Brownie]

On 11 Mar 2026 at 15:55:08, John Brownie <john_b...@sil.org> wrote:

That is true, that somewhere in the various rewriting of Ukelele, the check for long strings was lost. I’ve gone and fixed that now. I haven’t tried whether having a string more than one character and up to 20 starting with a space, but that is something to check. It shouldn’t be a problem in theory, but we’ll have to see in practice!

A quick test seems to indicate that having a space doesn’t cause a problem. It was most likely the output string being longer than 20 characters that was the problem (a buffer overflow is almost expected if the string you’re using is longer than the maximum length that was set up for the input buffer, and I wonder if this is a possible security issue…).

John

[Gé van Gasteren]

On Wed, Mar 11, 2026 at 2:55 PM 'John Brownie' via Ukelele Users <ukelel...@googlegroups.com> wrote:

somewhere in the various rewriting of Ukelele, the check for long strings was lost. I’ve gone and fixed that now. I haven’t tried whether having a string more than one character and up to 20 starting with a space, but that is something to check. It shouldn’t be a problem in theory, but we’ll have to see in practice! 

Which prompted me to do my homework more thoroughly :-) so I created a layout with multi-character keys of various lengths, then tried that in TextEdit.

Strangely enough, none of those keys crashed the app this time.

But: I can’t be 100% sure that the culprit string (from the previous posting) was shorter than 21 characters.

The longest string in the test I’ve done now was 15 characters, starting with a space: " 23456789abcdef"

[Gé van Gasteren]

Update: Another layout, this time with 3 keys with a leading space and total 19, 20, and 21characters, respectively, produced a clear result: the first two keys work normally, the third one crashes TextEdit.

So the most logical explanation for my previous results is that the string that crashed TextEdit until I removed the leading space was exactly 21 characters long. 

There’s some value in tracking the exact conditions while testing…