Wish lists

[John Brownie]

I had a productive week last week, and got bugs fixed and some new things done, including fixing printing. The newest thing is to save the font for display for each keyboard layout within a collection. Stand-alone keyboard layouts don’t get this, as I’m storing it in the metadata. Just as I write this, I realise that I could use an XML comment to store this information, so there would be that option if people really want it.

Anyway, Gé suggested making the Organiser copy rather than move files. That’s a possibility, so I could make that an option if there is enough interest.

Does anyone else have any wishes for changes or new features? I can hopefully make some progress on this, and perhaps get a new version out soon.

John

[Gé van Gasteren]

That’s good news, John.

When you write "got some things done, including fixing printing" it sounds like it was an easy job.

But I know how much time and "playing around" it usually takes me to first trouble-shoot, then repair broken stuff.

So thanks a lot for keeping up Ukelele the way you do!

--
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/CAC13VMxwX3KzN8WA8dGVA_nmPbwS8y4Bc9wO8n7zoW-XJ7nj3g%40mail.gmail.com.

[Cliff G]

Well, that is very generous of you to offer. As for me, I doubtless have an edge case, but it would be nice if it were supported. I have a custom keyboard that has as its intent maximizing the number of keys available to define. So I have a split right, and a split backspace; in other words, I have what you would find with a conjunction of ISO and a JIS. (I also have four keys to the right of the spacebar.)

So to define my layout, I select a keyboard which has both ISO and JIS available in the dropdown to the right. I define as much as I can in ISO or JIS, then switch and define the remaining keys. It would be nice if there were an option to view ISO and JIS in their merged state.

It is only a nice-to-have request, I am the first to acknowledge that, but thanks for taking a look!

[John Brownie]

That’s an interesting idea, but not easily done at present. The short version is that Ukelele relies on a set of physical keyboard descriptions that say what keys are where, including size and shape, which is currently frozen with the keyboards that Apple supplied until they stopped making them accessible, which was quite a few years ago. I’ve thought about making it an open system that users could extend, but a usable interface is a lot of complexity for a relatively small gain.

Here’s a long(er) version:

Back in the early days of the Mac, everything was done with resources, which were a brilliant innovation, allowing structured binary files to be used by developers in ways that could be extended. Among the resources included in the system were KCAP resources, which contained descriptions of all the physical keyboard types that Apple produced for the Mac.

Resource files started to fall out of favour with Mac OS X, and the collection of KCAP resources started to stagnate, not being updated with new keyboards as they were produced by Apple. I would guess that there is another system in place to do what the KCAP resources did, but it’s not documented anywhere that I have found, and I don’t know where to find them. So I made a property list that contains the old KCAP data and stores it inside the Ukelele application. It’s a binary format, so not easy to manage.

So at some point I decided to create my own format for describing a keyboard, based on the information that was present in a KCAP resource. It’s an XML-format description, and I have that as the basis for the next version of Ukelele, which is taking much longer to get working than I ever dreamed. But the XML text-based format is easier to extend, so there is the possibility of adding more keyboard types.

The format at present only describes keys that can be defined by two rectangles (most have one, but the Return key has two for some keyboard types) and defines just the key code. There is a lot of metadata that is hard coded into Ukelele about the various keyboard types, including the name, the coding, and how various keys work when the fn key is down (though the last is not particularly useful these days). The XML format can be easily extended to cover these things, but I haven’t felt the need to do so yet.

The challenge with making it open to users is that there are a lot of things that can go wrong. One is the complexity of parsing an XML file for all the information. Having it hard-coded is more efficient, but not extensible. Another is if there is an error in the file, which could make the keyboard unusable, or even cause a crash. I don’t think that there would be security issues, since it would not be executable code, but validation is always an issue.

The other big challenge is creating a way for users to add their own keyboard types. Creating XML by hand is tedious and error-prone (which is why Ukelele exists in the first place!), so there would need to be a more user-friendly approach. In my mind, you would have a canvas that you could populate with keys and define the key code for each. You would need basic square keys and a variety of rectangular keys, plus the various possibilities for two-rectangle keys. It’s all relatively straightforward at a basic level, but building such an editor would take a fair bit of time that I don’t really have at present. Maybe when I retire from my day job in a few years!

An alternative is also rather labour-intensive, that someone creates a definition, and I add it to what is hard-coded into Ukelele.

On 14 Jan 2025 at 08:43:03, Cliff G <monta...@gmail.com> wrote:

Well, that is very generous of you to offer. As for me, I doubtless have an edge case, but it would be nice if it were supported. I have a custom keyboard that has as its intent maximizing the number of keys available to define. So I have a split right, and a split backspace; in other words, I have what you would find with a conjunction of ISO and a JIS. (I also have four keys to the right of the spacebar.)

So to define my layout, I select a keyboard which has both ISO and JIS available in the dropdown to the right. I define as much as I can in ISO or JIS, then switch and define the remaining keys. It would be nice if there were an option to view ISO and JIS in their merged state.

The problem I see here is that many Apple-defined keyboard layouts use what are termed the JIS over-rides, where some characters are moved around between the ANSI/ISO and JIS types. For example, there is this section in the Finnish Extended keyboard layout:

<key code="24" output="^"></key>

<key code="30" output="["></key>

<key code="33" output="@"></key>

<key code="39" output=":"></key>

<key code="42" output="]"></key>

<key code="93" output="¥"></key>

<key code="94" output="_"></key>

<key code="95" output=","></key>

<key code="102" output=" "></key>

<key code="104" output=" "></key>

So the key with code 24 produces “=“ on an ANSI or ISO keyboard, but “^” on a JIS keyboard, and 30 is “]” in ANSI/ISO and “[“ in JIS. So, there is some problem with trying to define a merged ISO & JIS keyboard layout, since you would have to be able to show two different outputs on some keys.

What I think you have is a keyboard that has more keys than either a JIS or ISO keyboard has, so it would be a matter of making a representation of that in the Ukelele window. As detailed above, there is no quick answer to that.

It is only a nice-to-have request, I am the first to acknowledge that, but thanks for taking a look!

Maybe, one day…

John

[Sorin Paliga]

On 14 Jan 2025, at 15:28, 'John Brownie' via Ukelele Users <ukelel...@googlegroups.com> wrote:

The other big challenge is creating a way for users to add their own keyboard types. Creating XML by hand is tedious and error-prone (which is why Ukelele exists in the first place!), so there would need to be a more user-friendly approach. 

John, this is the essential part of your long explanation. I have the feeling many users do not understand that a keylayout, be it a simple txt file, may lead to system problems or even system crash. It happened to me several years ago, I have no idea whether newer macOS’s behave better. A keylayout may be a simple txt file, but it is a part of the system.

[Gé van Gasteren]

Here’s some ramblings of mine, only loosely related to the thread’s topic:

John, such a keyboard type editor sounds like almost an app in its own right!

1. Here’s an approach that could make it much easier (I think):

Have a fixed grid consisting of square "key points" acting as buttons and, separately, an image of the actual physical keyboard’s appearance which is not interactive.

Some of the keys shown in the image would include two or even three of the key points; for those keys, the key points’ definitions would be linked.

For example, the left Shift key should include two (linked) key points if the image shows an ANSI-type keyboard, and only one in an ISO-type keyboard.

The effect in the Ukelele window would be that keys are not necessarily changing colour completely – in other words: when they are clicked, they don’t light up as a whole.

I think I could live with that… :-)

Thinking further on that theme: Instead of squares, you could also use circles around the key points, which may be more esthetical, because then all keys would show as a contour with a different-colour circle inside them (when highlighted).

Such circles would also allow you to move the key points slightly off-centre in the keys on the bottom row, so they could remain in the same position for both ANSI and ISO layouts.

2. The opposite approach may also be worth considering:

Add a small optional panel to the keyboard window, containing all the keys unique to ISO, JIS, and ANSI, so that they are accessible in the graphic UI, even if the main window doesn’t show them.

Hopefully that’s not too many keys! 

I’m not sure how to mark them, though – by key code? With some default assignment? Both? 

Some keys would appear several times in that optional panel, namely in each of the three key groupings ISO, JIS, and ANSI, as necessary, to cater for the problem you described with Finnish Extended.

(It’s not important, but I couldn’t follow your description there: I expected a second entry for (at least) key codes 24 and 30, but there are none in the XML listing.)

--

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/CAC13VMwpOM8x3JKGauWx-KLwX_yRQRk0PtqrMT5Q8sAuOYTOwQ%40mail.gmail.com.

[John Brownie]

On 14 Jan 2025 at 22:05:43, Gé van Gasteren <gevang...@gmail.com> wrote:

(It’s not important, but I couldn’t follow your description there: I expected a second entry for (at least) key codes 24 and 30, but there are none in the XML listing.)

That’s because I just gave the part for the JIS over-rides. Here’s a fuller extract, first from the ANSI/ISO key map:

            <key code="24" action="acute"/>

            <key code="25" output="9"/>

            <key code="26" action="7"/>

            <key code="27" output="+"/>

            <key code="28" output="8"/>

            <key code="29" output="0"/>

            <key code="30" action="diaeresis"/>

            <key code="31" action="o"/>

            <key code="32" action="u"/>

            <key code="33" action="å"/>

            <key code="34" action="i"/>

            <key code="35" action="p"/>

            <key code="36" output="&#x000D;"/>

            <!-- carriage return -->

            <key code="37" action="l"/>

            <key code="38" action="j"/>

            <key code="39" output="ä"/>

            <key code="40" action="k"/>

            <key code="41" output="ö"/>

            <key code="42" output="&#x0027;"/>

            <key code="43" output=","/>

            <key code="44" output="-"/>

            <key code="45" action="n"/>

            <key code="46" action="m"/>

            <key code="47" output="."/>

            <key code="48" output="&#x0009;"/>

            <!--  -->

            <key code="49" action=" "/>

            <!-- space -->

            <key code="50" output="&#x003C;"/>

            <!-- less-than sign -->

            <key code="51" output="&#x0008;"/>

            <!-- backspace -->

            <key code="52" output="&#x0003;"/>

            <!-- end of text -->

            <key code="53" output="&#x001B;"/>

            <!-- escape -->

            <!-- gap, 54 through 64 -->

            <key code="64" output="&#x0010;"/>

            <key code="65" output=","/>

            <!-- decimal separator on numeric keypad -->

            <key code="66" output="&#x001D;"/>

            <key code="67" output="*"/>

            <!-- gap, 68 -->

            <key code="69" output="+"/>

            <key code="70" output="&#x001C;"/>

            <key code="71" output="&#x001B;"/>

            <key code="72" output="&#x001F;"/>

            <!-- gap, 73-74 -->

            <key code="75" output="/"/>

            <key code="76" output="&#x0003;"/>

            <key code="77" output="&#x001E;"/>

            <key code="78" output="-"/>

            <!-- gap, 79-80 -->

            <key code="79" output="&#x0010;"/>

            <key code="80" output="&#x0010;"/>

            <key code="81" output="="/>

            <key code="82" output="0"/>

            <key code="83" output="1"/>

            <key code="84" output="2"/>

            <key code="85" output="3"/>

            <key code="86" output="4"/>

            <key code="87" output="5"/>

            <key code="88" output="6"/>

            <key code="89" output="7"/>

            <!-- gap, 90 -->

            <key code="91" output="8"/>

            <key code="92" output="9"/>

            <!-- gap, 93-95 -->

            <key code="96" output="&#x0010;"/>

            <key code="97" output="&#x0010;"/>

            <key code="98" output="&#x0010;"/>

            <key code="99" output="&#x0010;"/>

            <key code="100" output="&#x0010;"/>

            <key code="101" output="&#x0010;"/>

            <key code="102" output="&#x0010;"/>

            <key code="103" output="&#x0010;"/>

            <key code="104" output="&#x0010;"/>

and then from the JIS again:

<key code="24" output="^"></key>

<key code="30" output="["></key>

<key code="33" output="@"></key>

<key code="39" output=":"></key>

<key code="42" output="]"></key>

<key code="93" output="¥"></key>

<key code="94" output="_"></key>

<key code="95" output=","></key>

<key code="102" output=" "></key>

<key code="104" output=" "></key

This is the effect of the base map, when it doesn’t have an entry, such as codes 25 to 29, it falls back to the base map, which is the one for ANSI/ISO. So I was wrong in saying that key code 24 produces “=“, but actually triggers the “acute” action, which is a dead key that enters the state “acute”, which gives the acute accent on various letters. Similarly, 30 is the diaeresis action in the base key map, but just “[“ in the JIS key map. The keys with codes 102 and 104 are the Japanese conversion keys. Those with 93 to 95 don’t exist on ANSI/ISO keyboards.

John

[John Brownie]

On 14 Jan 2025 at 22:05:43, Gé van Gasteren <gevang...@gmail.com> wrote:

Add a small optional panel to the keyboard window, containing all the keys unique to ISO, JIS, and ANSI, so that they are accessible in the graphic UI, even if the main window doesn’t show them.
Hopefully that’s not too many keys! 
I’m not sure how to mark them, though – by key code? With some default assignment? Both? 
Some keys would appear several times in that optional panel, namely in each of the three key groupings ISO, JIS, and ANSI, as necessary, to cater for the problem you described with Finnish Extended.

That’s worth considering, but you raise interesting questions!

You can actually make all the changes you need in the current version of Ukelele, by using the Edit Key… command. There you can change a key’s output or action with the key code entered into the appropriate field. You can always find the key code of any key by using the Inspector, which shows the code of the last key pressed. So it is possible to do everything, but it’s not nearly as convenient as the graphical editor. Maybe it would be possible to to enter the key code automatically by pressing the key? That would remove one level of difficulty from the operation.

John

[Gé van Gasteren]

On Wed, Jan 15, 2025 at 1:23 PM 'John Brownie' via Ukelele Users <ukelel...@googlegroups.com> wrote:

You can actually make all the changes you need in the current version of Ukelele, by using the Edit Key… command.

Yes, only I have the feeling that’s practically unknown territory for most users, especially those who don’t open the manual!

(off-off-topic: I even had my doubts if Cliff G knows about that function, when I read his descriptions.)

So that, together with the issue regarding the complexities around ISO/ANSI/JIS, got me thinking how it might be possible to make the interface more graphical.

A big unknown to me is, of course, how people use Ukelele and how their experience with it is. 

One tends to go by the posts in the group, but when I discovered that many thousands of people are using Ukelele, I realized that my impression could be quite wrong, as the vast majority never seems to have any problems.