Fix confusion with paste buffers and keyboard shortcuts #135
Conversation
…buffer not clipboard
TODO find out what they are!
| _, _ = t.in.Write([]byte{0x16}) | ||
|
|
||
| if ct, ok := s.(*fyne.ShortcutCut); ok { | ||
| if ct.Secondary { |
There was a problem hiding this comment.
Perhaps you could have exposed the triggering keys/key-code on the shortcut struct along side the Secondary bool? This would fix your issue here of trying to determine what keys to translate them into here; you could just write whatever key-code was originally captured when converting the input into a shortcut. The added bonus being that developers like my self would then be able to tell the exact keys used to trigger the shortcut and add custom handling if we choose to do so.
There was a problem hiding this comment.
That isn't needed - the Secondary provides that exact information.
Plus the codes from the keyboard are not the ANSI terminal codes need to be which is where I am falling short.
Keyboard codes are available at the low-level for Fyne developers that really need them - but this is not that place.
There was a problem hiding this comment.
Keyboard codes are available at the low-level for Fyne developers that really need them - but this is not that place.
I agree, this isn't the place, but since they are not emitted as actual key events I was clutching at straws. You're right that I can do this, and it'll work, and it does basically represent the same thing, it's just from a my perspective it's not clean or nice, BUT I'm falling into different issue territory here, that's the whole "Should Fyne be hard-coding shortcut handling in the first place" thing which is already open elsewhere.
Plus the codes from the keyboard are not the ANSI terminal codes need to be which is where I am falling short.
Ah, I entirely missed your point on this and thought you were talking about keyboard codes, which is why I was confused by the values and that you couldn't get them! My bad.
2 participants
No description provided.