Difficulty with modifier keys

[Aural Architect]

Using Ukelele 3.2.3 on Mountain Lion 10.8.5:

I have a USB keyboard which definitively sends unique scan codes for each of the left & right modifier keys.  I have verified this to be the case and to be working in MacOS in such applications as VMware Fusion and ControllerMate (both of which I use/have running constantly- utilizing the distinction between the L/R side modifier keys).

I have just started creating a keyboard which distinguishes between option & rightOption; all other layers/modifier maps use anyModifier.

However, I can't figure out how to edit—or even access—the newly created rightOption layer.  Actually, it almost seems like Ukelele itself is not capable of distinguishing between the two keys!  There's obviously something that I'm missing...
Pressing either of any of the modifier keys on my keyboard always triggers (left)option).  What's even more confusing is that when I press the virtual button on Ukelele's interface window for right option, it still activates the left option map.  And in both cases both of the virtual option keys are highlighted (as pressed).
I tried virtually all of the different keyboard maps (excluding some of the laptop configurations)—including many ISO versions as well as ANSI (several keyboards caused Ukelele to crash BTW).  I even tried a couple Japanese versions.
There was only one or two that didn't "show" both keys being pressed regardless of which side I clicked.   But even clicking the right option key on those on-screen keyboards still activated the left option map (even though it wasn't highlighted as though being pressed).

(BTW, I am aware of many of the limitations & caveats of distinguishing between the L&R modifiers, and I still wish to go ahead with it since I know my keyboard and the OS can handle it.)

Any thoughts?  Advice?  Comments?  Questions?


Oh, there was another app called "Key Codes" (free) that was able to see the difference between the left & right modifiers.

Also, just thought of this- don't know that it makes any difference.  I started out with a US layout, but there wasn't even the possibility to make the L/R distinction in Ukelele (the layout was already "simplified"), so I edited the file with a text editor.  I didn't get it right the first try, but the Ukelele crash report helped me resolve the issue and open the layout for modification.  All I did was add the layer to the modifier maps in the beginning of the file, then duplicate the anyOption modifier section mapping scan codes to outputs or actions, and of course fix the numbering of the layers.
Is there anything else I might need to change or add to the top of the file?
I consulted the Apple developer reference page for help and I saw some options that Ukelele doesn't seem to use/specify (in any of the layouts I have- either downloaded from somewhere or made/modified myself).  I didn't understand their purpose very well, but none of that seemed to be related to the use of distinct L&R modifiers.
Do I need to duplicate & uniquely rename all the "actions" referenced by the duplicated modifier set (even though they will remain identical)?



[Incidentally, my plan was actually duplicate the map of the left option to the right option (not linked) and only to differentiate the two within the output expression layers of dead keys.  It looks like I'm going to be entering a lot more transliteration, and I am not satisfied with any of the available layouts for entering IPA text and I decided that having more layers inside dead keys would let me create a layout that I would be able to easily learn, remember & use.   If I can get it to work and I reach the limits the limits of the option layers before being able to finishing programming all of the IPA glyphs, I may end up doing the same thing for shift and shift+option layers.  Basically IPA has so many latin letters that are rotated or flipped around as well as symbols/diacritics which are similar but either flipped and/or place above or below the base character.  And it seems much easier to just remember where the "original" version is and have the various similar alternative orientations/placements be mapped to the same modifier map.  This would reduce or eliminate nested deadkeys, while also making it very logical to figure out where a character is mapped (without having to actually remember) based on how it is changed from the original.
Technically I suppose it wouldn't really be required to access those modifier map layers for my goals.  I could just use the "Edit Key..." dialog box, except it doesn't present the differentiated options keys in the check-box list in the top right corner.  Is it supposed to/designed to self-adjust its button compliment dynamically based on the actual modifier key maps?
I sort of get the impression that you're in the process of terminating support for separate modifier keys in Ukelele but haven't deactivated that code yet to maintain support for layouts that rely on the distinction.]

[Sorin Paliga]

macOS does not distinguish left-right option, this is a system feature. I do not think UKELELE can handle this, can it? Perhaps you need smth like Karabiner to do this. 

--
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 post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

[Aural Architect]

I may be mistaken, but as I understand it: while MacOS does not functionally distinguish between the L & R instances of the modifier keys, the OS DOES recognize that they are unique/separate keys and receives/processes the code from the keyboard specifying which was pressed- it just treats them equally.

Yet regardless of whether Ukelele receives this distinction & how it is (or is not) processed & handled, the user manual (and the Apple specification for "keylayout" files) does recognize this distinction and provides a fair amount of documentation for implementing separate L & R modifier keys in Ukelele's interface.  Therefore, I would expect some means of selecting/activating (and hence editing) the modifier map indices distinguishing L & R modifier keys which Ukelele can produce.

However, the Ukelele Manual does not seem to indicate how to actually activate & edit the modifier maps distinguished by Right-side keys.  I suppose that is my primary question at the moment!

Since apparently Ukelele doesn't receive (or can't process) the code which uniquely identifies the L & R modifier keys, and the user interface (clicking the keys represented on the 'on-screen' graphical keyboard) seems to treat both modifiers as the left modifier even when a distinction exists in the modifier maps of the loaded keylayout...  The only way I can think of that might activate one of the modifier map indices which is distinguished & activated by a R modifier key would be to set that index as the default index (temporarily)- and *maybe* that modifier map index would activated by default (possibly only if the file was saved & re-opened?  *I'm totally guessing/speculating*)


@ John Brownie : perhapsyou can shed some light or insight on this?  And maybe offer me some guidance or point me in the right direction?


Thank you SO much for you time, concern and response Cattus Thraex (and any future commenters)!

[John Brownie]

This may not answer all your questions, but I'll have a go.

There are two levels where modifiers are noted. One is the higher-level system events where modifiers are passed to applications. At this level, no distinction is made between left and right modifier keys, and both keys send a notification of a left modifier key. The other level is at the raw key event level. Most applications don't ever go there, since they're more interested in the actual text input than the keys used to generate it.

The crucial thing is that the keyboard layout mechanism in Cocoa does not support a left/right modifier distinction. We've come a long way from when Steve Jobs said (approximately), "In the future, all life forms will be Carbon based." Carbon doesn't exist as a 64-bit framework, and Cocoa is where virtually all Mac applications work these days.

Since the use of left and right modifier keys is of no use at the level where keyboard layouts work, I considered it of no utility to try to support them in recent versions of Ukelele.

Your original use case is puzzling. Yes, the OS knows that there are separate keys, but the keyboard layout will never be able to generate any events that trigger the right modifier keys, so I don't see that you're going to be able to get around that fact.

John

Aural Architect

20 April 2017 at 08:34

Sorin Paliga

11 April 2017 at 04:11

macOS does not distinguish left-right option, this is a system feature. I do not think UKELELE can handle this, can it? Perhaps you need smth like Karabiner to do this. 

--
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 post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

Aural Architect

11 April 2017 at 03:18

Using Ukelele 3.2.3 on Mountain Lion 10.8.5:

I have a USB keyboard which definitively sends unique scan codes for each of the left & right modifier keys.  I have verified this to be the case and to be working in MacOS in such applications as VMware Fusion and ControllerMate (both of which I use/have running constantly- utilizing the distinction between the L/R side modifier keys).

I have just started creating a keyboard which distinguishes between option & rightOption; all other layers/modifier maps use anyModifier.

However, I can't figure out how to edit—or even access—the newly created rightOption layer.  Actually, it almost seems like Ukelele itself is not capable of distinguishing between the two keys!  There's obviously something that I'm missing...
Pressing either of any of the modifier keys on my keyboard always triggers (left)option).  What's even more confusing is that when I press the virtual button on Ukelele's interface window for right option, it still activates the left option map.  And in both cases both of the virtual option keys are highlighted (as pressed).
I tried virtually all of the different keyboard maps (excluding some of the laptop configurations)—including many ISO versions as well as ANSI (several keyboards caused Ukelele to crash BTW).  I even tried a couple Japanese versions.
There was only one or two that didn't "show" both keys being pressed regardless of which side I clicked.   But even clicking the right option key on those on-screen keyboards still activated the left option map (even though it wasn't highlighted as though being pressed).

(BTW, I am aware of many of the limitations & caveats of distinguishing between the L&R modifiers, and I still wish to go ahead with it since I know my keyboard and the OS can handle it.)

Any thoughts?  Advice?  Comments?  Questions?


Oh, there was another app called "Key Codes" (free) that was able to see the difference between the left & right modifiers.

Also, just thought of this- don't know that it makes any difference.  I started out with a US layout, but there wasn't even the possibility to make the L/R distinction in Ukelele (the layout was already "simplified"), so I edited the file with a text editor.  I didn't get it right the first try, but the Ukelele crash report helped me resolve the issue and open the layout for modification.  All I did was add the layer to the modifier maps in the beginning of the file, then duplicate the anyOption modifier section mapping scan codes to outputs or actions, and of course fix the numbering of the layers.
Is there anything else I might need to change or add to the top of the file?
I consulted the Apple developer reference page for help and I saw some options that Ukelele doesn't seem to use/specify (in any of the layouts I have- either downloaded from somewhere or made/modified myself).  I didn't understand their purpose very well, but none of that seemed to be related to the use of distinct L&R modifiers.
Do I need to duplicate & uniquely rename all the "actions" referenced by the duplicated modifier set (even though they will remain identical)?



[Incidentally, my plan was actually duplicate the map of the left option to the right option (not linked) and only to differentiate the two within the output expression layers of dead keys.  It looks like I'm going to be entering a lot more transliteration, and I am not satisfied with any of the available layouts for entering IPA text and I decided that having more layers inside dead keys would let me create a layout that I would be able to easily learn, remember & use.   If I can get it to work and I reach the limits the limits of the option layers before being able to finishing programming all of the IPA glyphs, I may end up doing the same thing for shift and shift+option layers.  Basically IPA has so many latin letters that are rotated or flipped around as well as symbols/diacritics which are similar but either flipped and/or place above or below the base character.  And it seems much easier to just remember where the "original" version is and have the various similar alternative orientations/placements be mapped to the same modifier map.  This would reduce or eliminate nested deadkeys, while also making it very logical to figure out where a character is mapped (without having to actually remember) based on how it is changed from the original.
Technically I suppose it wouldn't really be required to access those modifier map layers for my goals.  I could just use the "Edit Key..." dialog box, except it doesn't present the differentiated options keys in the check-box list in the top right corner.  Is it supposed to/designed to self-adjust its button compliment dynamically based on the actual modifier key maps?
I sort of get the impression that you're in the process of terminating support for separate modifier keys in Ukelele but haven't deactivated that code yet to maintain support for layouts that rely on the distinction.]

--
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 post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

--
John Brownie
In Australia on furlough from SIL Papua New Guinea

[Gé van Gasteren]

There is a relatively new feature in Mac OS where holding down a key makes a little list of characters pop up, much like on iOS.

(Sorry if this isn’t accurate, I haven’t seen or used this feature on my OS version.)

This feature provides a very intuitive alternative to dead keys and key combinations. It is also very "productive" (many results per key) and relatively easy to remember in cases like IPA, when one groups all characters based on the same Latin character in the list for that character’s key.

John: Can this behavior be edited in Ukelele? (I think it can, but if in doubt, go to the source...)

Aural Architect: Maybe this could be a good alternative solution to what you’re trying to achieve?

On 20 April 2017 at 01:20, John Brownie <john_b...@sil.org> wrote:

This may not answer all your questions, but I'll have a go.

There are two levels where modifiers are noted. One is the higher-level system events where modifiers are passed to applications. At this level, no distinction is made between left and right modifier keys, and both keys send a notification of a left modifier key. The other level is at the raw key event level. Most applications don't ever go there, since they're more interested in the actual text input than the keys used to generate it.

The crucial thing is that the keyboard layout mechanism in Cocoa does not support a left/right modifier distinction. We've come a long way from when Steve Jobs said (approximately), "In the future, all life forms will be Carbon based." Carbon doesn't exist as a 64-bit framework, and Cocoa is where virtually all Mac applications work these days.

Since the use of left and right modifier keys is of no use at the level where keyboard layouts work, I considered it of no utility to try to support them in recent versions of Ukelele.

Your original use case is puzzling. Yes, the OS knows that there are separate keys, but the keyboard layout will never be able to generate any events that trigger the right modifier keys, so I don't see that you're going to be able to get around that fact.

John

Aural Architect

20 April 2017 at 08:34

I may be mistaken, but as I understand it: while MacOS does not functionally distinguish between the L & R instances of the modifier keys, the OS DOES recognize that they are unique/separate keys and receives/processes the code from the keyboard specifying which was pressed- it just treats them equally.

Yet regardless of whether Ukelele receives this distinction & how it is (or is not) processed & handled, the user manual (and the Apple specification for "keylayout" files) does recognize this distinction and provides a fair amount of documentation for implementing separate L & R modifier keys in Ukelele's interface.  Therefore, I would expect some means of selecting/activating (and hence editing) the modifier map indices distinguishing L & R modifier keys which Ukelele can produce.

However, the Ukelele Manual does not seem to indicate how to actually activate & edit the modifier maps distinguished by Right-side keys.  I suppose that is my primary question at the moment!

Since apparently Ukelele doesn't receive (or can't process) the code which uniquely identifies the L & R modifier keys, and the user interface (clicking the keys represented on the 'on-screen' graphical keyboard) seems to treat both modifiers as the left modifier even when a distinction exists in the modifier maps of the loaded keylayout...  The only way I can think of that might activate one of the modifier map indices which is distinguished & activated by a R modifier key would be to set that index as the default index (temporarily)- and *maybe* that modifier map index would activated by default (possibly only if the file was saved & re-opened?  *I'm totally guessing/speculating*)


@ John Brownie : perhapsyou can shed some light or insight on this?  And maybe offer me some guidance or point me in the right direction?


Thank you SO much for you time, concern and response Cattus Thraex (and any future commenters)!



On Monday, April 10, 2017 at 2:11:37 PM UTC-4, Cattus Thraex 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-users+unsubscribe@googlegroups.com.

To post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

Sorin Paliga

11 April 2017 at 04:11

macOS does not distinguish left-right option, this is a system feature. I do not think UKELELE can handle this, can it? Perhaps you need smth like Karabiner to do this. 

--
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-users+unsubscribe@googlegroups.com.

To post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

Aural Architect

11 April 2017 at 03:18

Using Ukelele 3.2.3 on Mountain Lion 10.8.5:

I have a USB keyboard which definitively sends unique scan codes for each of the left & right modifier keys.  I have verified this to be the case and to be working in MacOS in such applications as VMware Fusion and ControllerMate (both of which I use/have running constantly- utilizing the distinction between the L/R side modifier keys).

I have just started creating a keyboard which distinguishes between option & rightOption; all other layers/modifier maps use anyModifier.

However, I can't figure out how to edit—or even access—the newly created rightOption layer.  Actually, it almost seems like Ukelele itself is not capable of distinguishing between the two keys!  There's obviously something that I'm missing...
Pressing either of any of the modifier keys on my keyboard always triggers (left)option).  What's even more confusing is that when I press the virtual button on Ukelele's interface window for right option, it still activates the left option map.  And in both cases both of the virtual option keys are highlighted (as pressed).
I tried virtually all of the different keyboard maps (excluding some of the laptop configurations)—including many ISO versions as well as ANSI (several keyboards caused Ukelele to crash BTW).  I even tried a couple Japanese versions.
There was only one or two that didn't "show" both keys being pressed regardless of which side I clicked.   But even clicking the right option key on those on-screen keyboards still activated the left option map (even though it wasn't highlighted as though being pressed).

(BTW, I am aware of many of the limitations & caveats of distinguishing between the L&R modifiers, and I still wish to go ahead with it since I know my keyboard and the OS can handle it.)

Any thoughts?  Advice?  Comments?  Questions?


Oh, there was another app called "Key Codes" (free) that was able to see the difference between the left & right modifiers.

Also, just thought of this- don't know that it makes any difference.  I started out with a US layout, but there wasn't even the possibility to make the L/R distinction in Ukelele (the layout was already "simplified"), so I edited the file with a text editor.  I didn't get it right the first try, but the Ukelele crash report helped me resolve the issue and open the layout for modification.  All I did was add the layer to the modifier maps in the beginning of the file, then duplicate the anyOption modifier section mapping scan codes to outputs or actions, and of course fix the numbering of the layers.
Is there anything else I might need to change or add to the top of the file?
I consulted the Apple developer reference page for help and I saw some options that Ukelele doesn't seem to use/specify (in any of the layouts I have- either downloaded from somewhere or made/modified myself).  I didn't understand their purpose very well, but none of that seemed to be related to the use of distinct L&R modifiers.
Do I need to duplicate & uniquely rename all the "actions" referenced by the duplicated modifier set (even though they will remain identical)?



[Incidentally, my plan was actually duplicate the map of the left option to the right option (not linked) and only to differentiate the two within the output expression layers of dead keys.  It looks like I'm going to be entering a lot more transliteration, and I am not satisfied with any of the available layouts for entering IPA text and I decided that having more layers inside dead keys would let me create a layout that I would be able to easily learn, remember & use.   If I can get it to work and I reach the limits the limits of the option layers before being able to finishing programming all of the IPA glyphs, I may end up doing the same thing for shift and shift+option layers.  Basically IPA has so many latin letters that are rotated or flipped around as well as symbols/diacritics which are similar but either flipped and/or place above or below the base character.  And it seems much easier to just remember where the "original" version is and have the various similar alternative orientations/placements be mapped to the same modifier map.  This would reduce or eliminate nested deadkeys, while also making it very logical to figure out where a character is mapped (without having to actually remember) based on how it is changed from the original.
Technically I suppose it wouldn't really be required to access those modifier map layers for my goals.  I could just use the "Edit Key..." dialog box, except it doesn't present the differentiated options keys in the check-box list in the top right corner.  Is it supposed to/designed to self-adjust its button compliment dynamically based on the actual modifier key maps?
I sort of get the impression that you're in the process of terminating support for separate modifier keys in Ukelele but haven't deactivated that code yet to maintain support for layouts that rely on the distinction.]

--
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-users+unsubscribe@googlegroups.com.

To post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

--
John Brownie
In Australia on furlough from SIL Papua New Guinea

--
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-users+unsubscribe@googlegroups.com.

[Tom Gewecke]

On Apr 20, 2017, at 12:04 AM, Gé van Gasteren <gevang...@gmail.com> wrote:

There is a relatively new feature in Mac OS where holding down a key makes a little list of characters pop up, much like on iOS.

(Sorry if this isn’t accurate, I haven’t seen or used this feature on my OS version.)

This feature, Character Picker or Accent Menu, appeared in 10.7 in 2011.  I think editing it involves modifying a .plist inside system/library/input methods/pressandhold.app.

[Tom Gewecke]

On Apr 20, 2017, at 12:04 AM, Gé van Gasteren <gevang...@gmail.com> wrote:

 Can this behavior be edited 

For those interested in modifying the Character Picker/Accent Menu, here is a good resource:

https://georgegarside.com/blog/macos/custom-characters-accent-popup-osx/

[Gé van Gasteren]

I’m blushing here in my old age...

This feature has been there since whatever and never in all those years have I tried it or stumbled across it.

Thanks for this great revelation, and especially paired with the knowledge how to change it!

I just have to look up how to disable/enable SIP now.

John: Could an editor for this be added to Ukelele, so that errors and problems are prevented and SIP handled properly?

After all, it’s part of the range of options someone thinking of modifying his keyboard layout would consider.

--

[Tom Gewecke]

On Apr 20, 2017, at 9:55 AM, Gé van Gasteren <gevang...@gmail.com> wrote:

 never in all those years have I tried it or stumbled across it.

A testimony to your typing skills.  The very first question that came up after this feature was introduced was how to disable it, as quite a few users are very annoyed when it comes up accidentally from a long key press or because they for some reason want to repeat single characters 50 times.

[Gé van Gasteren]

T

​hanks, Tom :)

Could you please point me to some more info about this Accent Menu?

The question now on my mind is: What’s the mechanism by which the OS picks a certain .plist, and/or: how to tell which of them is currently in use.

But I guess there’s more stuff I haven’t thought of yet...​

--

[John Brownie]

Gé van Gasteren wrote:

John: Could an editor for this be added to Ukelele, so that errors and problems are prevented and SIP handled properly?

After all, it’s part of the range of options someone thinking of modifying his keyboard layout would consider.

I don't think it's possible at this point, as Apple doesn't expose that function for user modification, and it has changed location at least once since I first became aware of it. I do have a long-standing open bug report with Apple requesting a way of customising it, but I'm not holding my breath.

[Aural Architect]

Got it.  Thank you so much John!  That fills in the blanks and resolves the confusion I was having surrounding "separate" modifier keys. 

I guess those apps like "ControllerMate", "VM-Ware Fusion" and "Karabiner" are some of those few exceptions that go down to that raw key event level.


I figured out that I can probably accomplish what I was originally trying to do using the app  "ControllerMate" (and possibly with "Karabiner" if it worked on 10.8) but it is not really designed for that type of use so it would be rather cumbersome...  But I have to say "ControllerMate" is an amazing and extremely powerful piece of software with so much flexibility!