Progress and a question

[John Brownie]

Hi everyone,

I’ve been working on the issues that Paul identified with template icons, and have fixed them. I don’t know if anyone really wants to use a private use language code, but it should be possible with the fixes. Indeed, the caps lock switching and template icon toggles don’t make Ukelele save the information unless there’s a language chosen. Sorry for that oversight!

Now, the question. Patrick asked if he could get a list of the possible outputs and their keystrokes. It’s certainly possible, but because it would need to be updated with every change to the keyboard layout, I’m thinking that it would be possible to generate a text file with the output and keystrokes. It would be tab-separated, so it could be read into a table or a spreadsheet and sorted and searched however you want it. But before I put in the effort to make it work, is there any support for that direction?

Another sort of related thing is that the Keyman roadmap for version 19 (they are currently shipping version 18, and 19 is in alpha release) includes converters for other kinds of keyboard layouts, including the XML format that Ukelele can edit. So there will be a way to use Ukelele to develop a keyboard layout and use Keyman to port it to other platforms!

John

[Theresa Goldband]

Text output of keystrokes would be very useful!  

Regards

Theresa. 

Sent from my iPhone

On 16 Jul 2025, at 16:01, 'John Brownie' via Ukelele Users <ukelel...@googlegroups.com> wrote:



--
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/CAC13VMxPHZuH5Koy-6P52C8B5YGCkN03w12qHBLFGu9yXme7bA%40mail.gmail.com.

[Gé van Gasteren]

On Wed, Jul 16, 2025 at 5:01 PM 'John Brownie' via Ukelele Users <ukelel...@googlegroups.com> wrote:

Now, the question. Patrick asked if he could get a list of the possible outputs and their keystrokes. It’s certainly possible, but because it would need to be updated with every change to the keyboard layout, I’m thinking that it would be possible to generate a text file with the output and keystrokes. It would be tab-separated, so it could be read into a table or a spreadsheet and sorted and searched however you want it. But before I put in the effort to make it work, is there any support for that direction?

I personally think it’s a great idea:

• When planning a custom keyboard layout, it can help decide which Apple-provided layout to take as a starting point: Open a few candidates with "New from current input source" then print their respective lists, maybe in PDF.

• After you have picked one, you can print the list on paper and use it as a working document where you write the desired changes.

• And after editing, you can compare a new printout with the working list to check if everything works as planned.

What I’m not sure about is how you would format it. It’s easy to create a table with keycodes and output, but how do you link keystrokes and output? Hardware keyboards come in various localized versions, and taking the US layout as reference may not be practical for everyone – although I don’t see an easy alternative here.

Another sort of related thing is that the Keyman roadmap for version 19 (they are currently shipping version 18, and 19 is in alpha release) includes converters for other kinds of keyboard layouts, including the XML format that Ukelele can edit. So there will be a way to use Ukelele to develop a keyboard layout and use Keyman to port it to other platforms!

That sounds really good. A question: 

I suspect the properties of Ukelele-generated layouts and Keyman layouts are different, so you may want to expand Ukelele’s feature set to make better use of Keyman’s possibilities and/or reduce it when preparing a layout for Keyman. And how would you switch between "Mac mode" and "Keyman mode" ?

[John Brownie]

On 17 Jul 2025 at 13:01:07, Gé van Gasteren <gevang...@gmail.com> wrote:

On Wed, Jul 16, 2025 at 5:01 PM 'John Brownie' via Ukelele Users <ukelel...@googlegroups.com> wrote:

Now, the question. Patrick asked if he could get a list of the possible outputs and their keystrokes. It’s certainly possible, but because it would need to be updated with every change to the keyboard layout, I’m thinking that it would be possible to generate a text file with the output and keystrokes. It would be tab-separated, so it could be read into a table or a spreadsheet and sorted and searched however you want it. But before I put in the effort to make it work, is there any support for that direction?

I personally think it’s a great idea:

• When planning a custom keyboard layout, it can help decide which Apple-provided layout to take as a starting point: Open a few candidates with "New from current input source" then print their respective lists, maybe in PDF.

• After you have picked one, you can print the list on paper and use it as a working document where you write the desired changes.

• And after editing, you can compare a new printout with the working list to check if everything works as planned.

Yes, that is the general scenario that I was thinking about. Good to know that there is support, so I’ll get to work on it.

What I’m not sure about is how you would format it. It’s easy to create a table with keycodes and output, but how do you link keystrokes and output? Hardware keyboards come in various localized versions, and taking the US layout as reference may not be practical for everyone – although I don’t see an easy alternative here.

The approach I’ve taken in the Find Key Stroke is to use the output of the key with no modifiers. But now that I say that, I realise that there is something of a flaw when the key without modifiers is a dead key. At the moment, it gets (I think) the terminator for the state, which may not be the best alternative, though I can’t think of a better one at the moment. One possibility would be to have a third column which uses the key code rather than specifying a particular character output.

Another sort of related thing is that the Keyman roadmap for version 19 (they are currently shipping version 18, and 19 is in alpha release) includes converters for other kinds of keyboard layouts, including the XML format that Ukelele can edit. So there will be a way to use Ukelele to develop a keyboard layout and use Keyman to port it to other platforms!

That sounds really good. A question: 

I suspect the properties of Ukelele-generated layouts and Keyman layouts are different, so you may want to expand Ukelele’s feature set to make better use of Keyman’s possibilities and/or reduce it when preparing a layout for Keyman. And how would you switch between "Mac mode" and "Keyman mode" ?

I don’t really know enough about how they are doing it, but they are reading the .keylayout file directly and parsing it to get the information they need, so I don’t know what would make it easier for them.

To switch between modes would be to (I think, not having used Keyman on my Mac) activate either the Ukelele type keyboard layout or the Keyman method. You need to have the Keyman application on your computer, and it provides a way to enable different Keyman keyboard layouts. I think it’s akin to enabling an input method.

John

[Gé van Gasteren]

Thanks, John!

Just regarding the last point, I was more thinking in terms of compatibility. 

How to handle differences in feature set – flag imcompatible stuff upon conversion?

Implement some of Keyman’s extra features in Ukelele?

[John Brownie]

There’s a deal of limitations in this. It’s a one-way conversion of the XML file, so I’m guessing that some of the metadata such as language and icon are not imported by Keyman. I need to check with the Keyman people on that one.

John