On Fri, 16 May 2025 22:25:20 GMT, Martin Fox wrote:
>> Under the hood the Keyman input method appears as a US English keyboard
>> layout. The characters attached to an NSEvent are always US English Roman
>> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>> the corre
On Fri, 16 May 2025 22:25:20 GMT, Martin Fox wrote:
>> Under the hood the Keyman input method appears as a US English keyboard
>> layout. The characters attached to an NSEvent are always US English Roman
>> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>> the corre
On Fri, 16 May 2025 22:25:20 GMT, Martin Fox wrote:
>> Under the hood the Keyman input method appears as a US English keyboard
>> layout. The characters attached to an NSEvent are always US English Roman
>> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>> the corre
On Fri, 16 May 2025 23:02:30 GMT, Andy Goryachev wrote:
> It is weird that we have to add third-party specific code to JavaFX as a
> workaround - why doesn't macOS provide a general purpose API for this?
Normally an input method is designed for a specific language and is bundled
with a collect
On Fri, 16 May 2025 23:13:43 GMT, Andy Goryachev wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Second try at making Keyman work to some extent
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m lin
On Fri, 16 May 2025 22:25:20 GMT, Martin Fox wrote:
>> Under the hood the Keyman input method appears as a US English keyboard
>> layout. The characters attached to an NSEvent are always US English Roman
>> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>> the corre
On Fri, 16 May 2025 22:25:20 GMT, Martin Fox wrote:
>> Under the hood the Keyman input method appears as a US English keyboard
>> layout. The characters attached to an NSEvent are always US English Roman
>> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>> the corre
On Fri, 16 May 2025 22:21:52 GMT, Martin Fox wrote:
> keeps sending backspaces to erase previous characters
I do know that keyboards in general need to be able to interact with the
existing context, that is, to convert h + i into ひ erasing the "h". I'm not
sure of the correct mechanism here bu
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct Hebrew or Dvorak character to insertText:replacementRan
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Thu, 15 May 2025 22:57:08 GMT, Steven Loomis wrote:
>>> Do you think it's a bug in keyman or our code? I head the beep (correctly)
>>> but then n appears, despite the keyman onscreen keyboard showing an empty
>>> key. If it is our code, should there be some additional logic?
>>
>> Keyman is
On Thu, 15 May 2025 22:48:51 GMT, Martin Fox wrote:
>>> The N key in the Himyarit Musnad layout shouldn't generate a character
>>> (just a beep)
>>
>> Do you think it's a bug in keyman or our code? I head the beep (correctly)
>> but then n appears, despite the keyman onscreen keyboard showing
On Thu, 15 May 2025 22:25:51 GMT, Andy Goryachev wrote:
> Do you think it's a bug in keyman or our code? I head the beep (correctly)
> but then n appears, despite the keyman onscreen keyboard showing an empty
> key. If it is our code, should there be some additional logic?
Keyman is definitely
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Thu, 15 May 2025 19:04:26 GMT, Martin Fox wrote:
> The N key in the Himyarit Musnad layout shouldn't generate a character (just
> a beep)
Do you think it's a bug in keyman or our code? I head the beep (correctly) but
then n appears, despite the keyman onscreen keyboard showing an empty key
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Thu, 15 May 2025 17:26:39 GMT, Alexander Zuev wrote:
>> Noticed a bit of a problem.
>>
>> To reproduce, install Himyarit Musnad keyboard
>> https://keyman.com/keyboards/himyarit_musnad
>>
>> typing 'h' causes this character to appear: 𐩱
>> typing 'n' followed by 'h' generates garbage input
On Thu, 15 May 2025 15:55:41 GMT, Andy Goryachev wrote:
> typing 'h' causes this character to appear: 𐩱 typing 'n' followed by 'h'
> generates garbage input rather than expected 𐩱:
The same happens without the fix. For some reason events for the keys not
mapped on the active keyman keyboard st
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
> the correct H
Under the hood the Keyman input method appears as a US English keyboard layout.
The characters attached to an NSEvent are always US English Roman even if the
selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct
Hebrew or Dvorak character to insertText:replacementRange: inst
28 matches
Mail list logo
