Does MacOS support group switching?

[Ralf H.]

I haven’t actually used Ukulele yet, but I would be interested to use it to replicate this extended German layout:

https://de.wikipedia.org/wiki/E1_(Tastaturbelegung)#/media/Datei:Deutsche_Tastaturbelegung_E1_nach_DIN_2137-01--2023-08.png

The problem here could be that it requires group switching to access the characters shown in red. So, instead of adding more regular layers through modifier keys, clicking Alt(Gr) + F in this layout switches all base layers to a new group with completely different layers. 

Does MacOS and Ukulele even support that functionality? I see no mention or sign of it in the app or documentation. 

And if it is not directly supported, would there maybe be a work-around? I see a combination of multiple dead keys mentioned in the documentation, so maybe the functionality could be simulated this way. 

[Gé van Gasteren]

Hi Ralf,

I read the description of the E1 keyboard layout on Wikipedia, and to me, this group switch seems to work just like any other dead key. Maybe I’m missing something?

On the other hand, I’m not sure if the way it produces accents by themselves (as opposed to combinations with a letter) by typing them twice can be replicated in a Mac keyboard layout:

Um (als Beispiel für ein nicht in Unicode auf einzelnem Codepunkt vorhandenes Zeichen) für Yoruba ein Ẹ́ (E mit Akut und Punkt unterhalb) einzugeben, drückt man ⇧ + E, danach , danach die gleiche Taste noch einmal, danach Alt Gr + , danach die gleiche Tastenkombination noch einmal.

On the Mac, the dead-key accents themselves are normally produced by typing a space after them.

--
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 on the web visit https://groups.google.com/d/msgid/ukelele-users/df2c5c96-f50b-4e6f-97cc-1c7596953192n%40googlegroups.com.

[Tom]

Have you checked out Apple's own input source called German Standard?  It is also extended German, providing a large number of option dead keys for accents, plus option shift combining versions, so that a letter with mutiple accents can be easily made.  Ẹ́ is made via ' then E then option shift ö.

[Ralf H.]

On Friday, February 9, 2024 at 9:37:49 PM UTC+1 Tom wrote:

Have you checked out Apple's own input source called German Standard?  

Yes. And this layout is missing all the “group switching” characters from the DIN standard. That’s what made me wonder if there are technical limitations to implement this layout on MacOS. 

[Sorin Paliga]

Ralf

Perhaps I missed your initial message. What is ‘group switching’ in Windows keyboard layouts? Since I have not used a Windows machine for years, I do not realize what you wish/intended to do. 

macOS sometimes behaves in a specific way, but perhaps there is a simple solution for you.

--
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 on the web visit https://groups.google.com/d/msgid/ukelele-users/cbc88a0a-9303-4b30-aea2-c395d39c6967n%40googlegroups.com.

[Tom]

Can you give some examples of the missing characters?

[Ralf H.]

On Saturday, February 10, 2024 at 1:08:53 PM UTC+1 Tom wrote:

Can you give some examples of the missing characters?

See the image I posted earlier:

https://de.wikipedia.org/wiki/E1_(Tastaturbelegung)#/media/Datei:Deutsche_Tastaturbelegung_E1_nach_DIN_2137-01--2023-08.png

The “German Standard” layout on MacOS contains the letters and symbols shown in black. The red ones are not supported.  

[Tom]

Aha, sorry I missed that.  The ABC Extended keyboard has a wider selection, activated by dead keys on the option shift level.  Perhaps that would be a model?  

[Sorin Paliga]

On 10 Feb 2024, at 14:28, Ralf H. <ads...@ralf-herrmann.de> wrote:

The red ones are not supported. 

OK. I cannot figure out why Apple engineering decided to not support them (I had and have my critical views on how Apple handles keyboard layouts), but you can add them to any existing German keylayout by ’sacrificing’, so to speak, the existing chars and replacing them by the ones displayed in red. I guess you need them or, at least, some of them. 

This should be a relatively easy task with UKELELE, but I guess it is a problem for you and am trying to understand how I may be helpful. 

So, open your German keylayout, the one closest to your wish and already present in macOS, and make the changes. Why can’t you do that? 

I do not have time today or tomorrow, perhaps, but I can do that for you. If I did this, you will not learn how to use UKELELE, so try to learn how to add your desired chars.

Good luck

[Gé van Gasteren]

Ralf, can you say a little about your "motives" for this keyboard layout?

From your description, I get the feeling that you want to create a close copy of the MS Windows keyboard layout, so people who are used to that one can more easily move their work to a Mac. But I may be wrong, of course.

One possible problem I see with the E1 layout is that it mixes two basically different ways of typing accents: type them before or after the base character:

Speziell für Vietnamesisch lassen sich Tottasten auch verketten, so gibt man beispielsweise für ự (u mit Horn und Punkt unterhalb) ein: Alt Gr + für das Horn, danach Alt Gr + , danach u. (Die Eingabereihenfolge der diakritischen Zeichen ist unerheblich.)

Such characters should, in my opinion, be produced not by typing dead keys, but by typing combining diacritical marks after the base character. Not only because it’s easier to implement, but mainly because it often yields better typography.

It’s also easier to learn a keyboard layout when it’s following a simpler logic – but of course that doesn’t matter if your project is mainly aimed at "existing users".

Has this E1 layout actually been implemented as an MS Windows keyboard layout, or is it only a DIN guideline, so far?

I ask because the thing I wrote about before (producing accents by themselves by typing their dead keys twice) points at a difference between how "terminal characters" of dead key setups are handled by Windows and macOS.

Those are just some thoughts about your project…

[Sorin Paliga]

I guess Ralf’s problem is, he cannot get accustomed to macOS. He has had a long Windows experience and would like to have it identical in macOS. I do not think this is possible. The two OSs have different approaches, including keylayouts. 

In my case, as long as I have not used a Windows machine for years, getting accustomed to Windows would be a tiresome, tedious attempt. Any mac user would say ‘macOS is easier and more logical’, a Windows user would say exactly the contrary! Use and usage are more important than logic proper.

--
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 on the web visit https://groups.google.com/d/msgid/ukelele-users/CAOH1hL_Bokc05qsw4cF9Gq5YhDCWj95hmWQ0oQ7K6CLdxHs0Kg%40mail.gmail.com.

[Ralf H.]

On Saturday, February 10, 2024 at 2:40:13 PM UTC+1 Gé van Gasteren wrote:

Ralf, can you say a little about your "motives" for this keyboard layout?

Ideally, I would want to create a shareable MacOS version to allow and promote the use of an “extended German norm layout”, which could be used on Windows and Mac at the same time. Happy to learn Ukulele for that, but if the standard, which was created with Windows in mind, requires functionalities which are not available on MacOS, the project would be dead in the water. That’s why I asking people with more experience in creating Mac keyboard layouts. 

Has this E1 layout actually been implemented as an MS Windows keyboard layout, or is it only a DIN guideline, so far?

It only became official a couple of months ago. A beta version from an individual is available here:

http://www.e1-tastatur.de

For the previous, only slightly different version of this standard, there was even a commercial physical keyboard available – with all the letters and symbols printed on it. That’s another reason why the Mac implementation would need to match the Windows version exactly. 

[Sorin Paliga]

On 10 Feb 2024, at 16:34, Ralf H. <ads...@ralf-herrmann.de> wrote:

on Windows and Mac at the same time

OK. This is clear. As long as Windows and macOS have different views on details, you must decide whether the Windows keylayout should be like macOS, or vice-versa. 

If their creators have uploaded different keylayout for the two platforms, you must adapt one in order to fit the other.

I guess, according to your messages, that you are accustomed to Windows, and new to macOS. The two OSs do the same thing, in principle, but they differ in details. You must decide which details you are inclined to choose.

[Tom]

Offhand it seems to me that you could add all those characters via a dead key on option shift F.  After pressing that, you would then put the red ones on the normal and shift levels of each of the keys.   You have to press the dead key every time in the Apple system.  Does the Windows system let you just press it once to turn on the extra levels, and then press it again to turn those levels off?

[Gé van Gasteren]

Great info, Ralf, I’ll report back when I’ve tried out that Windows version.

Slightly controversial, maybe, to write the following on this forum, but anyway:

You could take a look at Keyman, which I should say is more intrusive to users’ privacy than Ukelele, because it installs an app monitoring keystrokes.

But for this E1 project, it does have the advantage that it lets you develop a keyboard layout (in MS Windows) and then export versions for Mac, Windows, and many other platforms. Which not only saves time, but might also help keep the way of working more the same. Unfortunately, I can’t say that last point with much faith, as I have wanted to give Keyman a good try, but so far haven’t gotten to it.

Regarding an Installer: Ukelele does have a command that lets you create an installer package (.dmg) you can distribute.

[Gé van Gasteren]

I have to correct the following sentence from my previous post:
"Keyman is more intrusive to users’ privacy than Ukelele, because it installs an app monitoring keystrokes."

What I should have written:

"Keyman is more intrusive on your computer, because it installs an app that needs to run in the background for Keyman keyboard layouts to work."

Obviously, such an app could potentially send your keystrokes anywhere on the web, so it’s understandable that people are wary. But Keyman is open-source, and its source code is available on Github, so anyone who really wants to can verify that it doesn’t do anything naughty.

Thanks to David J. Perry for alerting me to this error.

[Gé van Gasteren]

In the meantime, I’ve tested how the MS Windows keyboard layout works that Ralf had uploaded, and sent him some details.

To sum up my "experience", as it’s called these days, it feels like the designer(s) have struggled to implement the DIN guidelines and had to resort to some relatively clumsy workarounds to get as much in as they possibly could.

My suggestion is therefore, to first decide the platforms to cater for, assess their respective possibilities, and then design the keyboard layout as a "greatest common factor", so that it can be implemented to work virtually the same on the targeted platforms.

In case this allows only a partial implementation of the DIN guidelines, then so be it – it means that those who drafted those guidelines had different goals in mind than the actual user.

One could also consider creating two keyboard layouts for the Mac: one labeled for a Latin-script language and one for non-Latin. As the Mac has a setting to switch between two such keyboard layouts through the Caps Lock key, they would feel as if they were parts of one keyboard layout. It would be interesting to find out if Microsoft has plans to include such a feature in future. Or, if switching keyboard layouts through the standard key combination is deemed practical enough, one could decide to go for this "twin-layouts" setup.

[Tom]

Is the reference to non-Latin meant for the Greek layer which I guess E1 includes?

[Gé van Gasteren]

On Sun, Feb 11, 2024 at 6:49 PM Tom <thge...@gmail.com> wrote:

Is the reference to non-Latin meant for the Greek layer which I guess E1 includes?

 

On Sunday, February 11, 2024 at 9:24:40 AM UTC-7 Gé van Gasteren wrote:

…

One could also consider creating two keyboard layouts for the Mac: one labeled for a Latin-script language and one for non-Latin. As the Mac has a setting to switch between two such keyboard layouts through the Caps Lock key, they would feel as if they were parts of one keyboard layout. It would be interesting to find out if Microsoft has plans to include such a feature in future. Or, if switching keyboard layouts through the standard key combination is deemed practical enough, one could decide to go for this "twin-layouts" setup.

So far, that’s only brainstorming on my part, and your input as to its feasibility would be very welcome.

Indeed, the E1 layout includes sets for Greek, Cyrillic, maths, IPA – actually a bit top-heavy for my feeling :-)

[Tom]

It looks to me like Cyrillic is not part of the one Ralf is trying to make, but the rest is still pretty huge

[Gé van Gasteren]

On Sun, Feb 11, 2024 at 10:17 PM Tom <thge...@gmail.com> wrote:

It looks to me like Cyrillic is not part of the one Ralf is trying to make, but the rest is still pretty huge

Indeed, I haven’t found the Cyrillic layer yet in the keyboard he uploaded, but it is in the DIN E1 description and also in the ReadMe file that came with the keyboard.

Actually, I have found the layers with the Greek and maths symbols by playing around, because the way they are accessed differs from what the documentation says – and the maths symbols aren’t documented at all – so Cyrillic may still be in there somewhere :-)

[Ralf H.]

Another question regarding replicating the DIN2137 E1 layout on MacOS:

The layout has a smiley key (Alt + A) which either outputs a smiley or is supposed to be used to call a character palette for emojis or other characters, which is handy. 

So, on MacOS that would be what would otherwise be called with control + cmd + space. Is it possible to replicate that call for Alt + A?

(I doubt it, but I figured it can’t hurt to ask.)

[Gé van Gasteren]

Hi Ralf,

I suggest you just put it in and see how it works for you – I mean, it can't hurt to try ;-)

As far as I know, this kind of shortcuts (with the Command modifier involved) is not universally supported, but in some apps it will work as hoped.

Because at the moment, it's passed through most apps I know of, i.e. it makes it through to the OS and there triggers the emoji panel, I'd say chances are good.

--

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 on the web visit https://groups.google.com/d/msgid/ukelele-users/5e43f300-0b55-4295-a7b6-ab541afb2306n%40googlegroups.com.