"Shift + Insert" produces "^V" instead of correct keys in TermGrid key handling

[drunlade]

Issue

When trying to register a shortcut to handle "Shift + Insert", it's not possible to detect as the actual input that Fyne appears to receive is "^V" rather than actual keys.

When pressing the Shift key, I correctly log "Shift". When pressing the Insert key I correctly log "Insert". Press them together, "Shift" is detected, "Insert" is not and *fyne.ShortcutPaste &{Clipboard:{}} is produced in TypedShortcut, which is no as terminal application do need to know the difference between "Control + V" and "Shift + Insert", since most do not actually expect "Control + V" as as a sequence for pasting.

TL;DR; typed keys should be represented correctly in Fyne applications.

(I'd be happy to be told I've missed something obvious and this behaviour can be fixed/changes easily!)

Details

Fyne    2.6.1
Windows 11
Go      1.25.2

[drunlade]

So I poked into the driver and the Windows driver has this:

	if modifier == fyne.KeyModifierShift {
		switch keyName {
		case fyne.KeyInsert: // detect paste shortcut
			shortcut = &fyne.ShortcutPaste{
				Clipboard: NewClipboard(),
			}

Fyne driver is eating the key input and interpreting it. This needs to have an option to be disabled, because application developers (and importantly Terminal Emulators) need to receive the actual key input, not an interpretation.

[andydotxyz]

Hmm, an interesting one - it seems people have strong feelings on this.
Shift+Ins was seen as a universal paste keyboard shortcut - what is the use-case for where the app should take over a system shortcut to do other things instead?

TL;DR; typed keys should be represented correctly in Fyne applications.

That's probably not a fair TL;DR - system shortcuts should do what the user expects. We will need to understand what is not working to evaluate this correctly.

[andydotxyz]

Based on a few assumptions I opened that PR. It will enable the terminal app to cut/copy/paste from the selection instead of clipboard.

Have I guessed correctly?

[drunlade]

Fair enough, my TL;DR; was a little off-the-cuff I admit. Essentially, I agree, in most applications, having "Shift + Insert" behave as paste is probably a sensible default.

My use case is the application I've built my Terminal emulator for (almost exclusively) is quite old, and it uses Control + V to open a special menu (it's a text based UI). This shortcut can't be changed. The old Terminal software we currently use supports this just fine; Control + V is not a paste shortcut, it's passed all the way through to the software running in it. Shift + Insert has been configured in the Terminal Emulator to act as Paste.

Putting aside my perceived Terminal expectations, from a general developer standpoint (I'm aware this is an opinionated and touchy subject, I've seen some of the other threads!), I want complete control over what my application does and doesn't do. I've no issue with sensible defaults, but if I don't want a certain shortcut doing something in the program I'm creating, I feel I should be able to make that choice rather than have it dictated. Effectively, I believe the shortcut manager should be able to override whatever the sensible default is, including outright removing it so its passed through as actual keyboard input from the Driver layer.

[andydotxyz]

I feel I should be able to make that choice rather than have it dictated. Effectively, I believe the shortcut manager should be able to override whatever the sensible default is, including outright removing it so its passed through as actual keyboard input from the Driver layer.

That is an interesting request - and one to open in the Fyne project itself. However it's worth noting that we cannot disable /all/ shortcuts as many happen at the OS layer and never reach us (alt-tab / meta-s etc) and also vary based on the system. We have done our best to support a consistent user experience.

Hopefully with the PR linked the terminal can use the correct multiple-paste-buffers which I have learned is common practice. Additonally it means your app can look at ShortcutPaste.Secondary and when it is false open the menu instead?

[drunlade]

I feel I should be able to make that choice rather than have it dictated. Effectively, I believe the shortcut manager should be able to override whatever the sensible default is, including outright removing it so its passed through as actual keyboard input from the Driver layer.

That is an interesting request - and one to open in the Fyne project itself. However it's worth noting that we cannot disable /all/ shortcuts as many happen at the OS layer and never reach us (alt-tab / meta-s etc) and also vary based on the system. We have done our best to support a consistent user experience.

Hopefully with the PR linked the terminal can use the correct multiple-paste-buffers which I have learned is common practice. Additionally it means your app can look at ShortcutPaste.Secondary and when it is false open the menu instead?

Indeed, I was just writing up a reply to say that; checking that flag I can control the behaviour the way I need (non-secondary paste gets passed through as key input, secondary paste is treated a normal clipboard paste). I appreciate it, thank you.

I'm aware that making a cross-platform library like Fyne is full of gotchas and bear-traps, making what seems like a sensible concession can blow up in your face. I suspect I am using it in a rather non-standard way compare to most people, and I have expectations that might not fall entirely in line with the more opinionated design that is Fyne. Having said that, I do think "Sensible by default; flexible by design" is the best approach, because you really can't predict what someone actually wants to do with your library.

I might need to fork and apply that change for now as the program I'm working on is entering production envs and this was raised as an issue by users.

[andydotxyz]

I do think "Sensible by default; flexible by design" is the best approach, because you really can't predict what someone actually wants to do with your library.

Our design is "Sensible by default; extensibly by design" so that it is easy to be additive and very hard to be detractive.
I can see that in this case it may be helpful to remove certain builtins and such a discussion could be had in a Fyne issue, though it is a much more complex fix than we have in PR now.

I might need to fork and apply that change for now as the program I'm working on is entering production envs and this was raised as an issue by users.

With any luck we can get the PR approved today at which point your app could update to that version of Fyne and apply the appropriate if statement - I don't think you need to wait for a terminal update or new release.

[drunlade]

Our design is "Sensible by default; extensibly by design" so that it is easy to be additive and very hard to be detractive.

My (probably unfair) opinion is that Fyne is halfway there on that, I've encountered a number of places where I could not achieve what I wanted, such as trying to add right-click popup menu to tab header (seems to be basically impossible?) or supporting double-click (or press-enter) on items in list boxes to trigger a submit action.

With any luck we can get the PR approved today at which point your app could update to that version of Fyne and apply the appropriate if statement - I don't think you need to wait for a terminal update or new release.

Oh, fair enough, I thought I was going to have to wait a while for the next release, that'd certainly be better.

[andydotxyz]

trying to add right-click popup menu to tab header (seems to be basically impossible?)

That is a complex one, as we treat the whole container as a single widget (for simplicity). To have a menu for a single area (such as a tab) would require an API addition. Not a complex one though - a feature request on this could probably be delivered in a few days.

supporting double-click (or press-enter) on items in list boxes to trigger a submit action.

This is completely possible (unless I have misunderstood what "list boxes" are). You just have a custom component that is DoubleTappable, or Focusable (depending on your desired outcome). The List is designed to have custom items as the content - because these are not really features of the list but of it's child items.

[drunlade]

supporting double-click (or press-enter) on items in list boxes to trigger a submit action.

This is completely possible (unless I have misunderstood what "list boxes" are). You just have a custom component that is DoubleTappable, or Focusable (depending on your desired outcome). The List is designed to have custom items as the content - because these are not really features of the list but of it's child items.

I'll try again, sounds like I might have made a mistake with implementing if it's supposed to work.

That is a complex one, as we treat the whole container as a single widget (for simplicity). To have a menu for a single area (such as a tab) would require an API addition. Not a complex one though - a feature request on this could probably be delivered in a few days.

The thing I wanted to do with it however I think doesn't work anyway, so it's perhaps less important... I wanted to add an "Undock" item to a popup menu, however it appears that Fyne doesn't allow moving content from one window to another; the content shows up in the new window, but it's never visually updated unless I force it to through code, and even then I can't focus input in the new window. Is this a limitation of Fyne?

[andydotxyz]

however it appears that Fyne doesn't allow moving content from one window to another; the content shows up in the new window, but it's never visually updated unless I force it to through code, and even then I can't focus input in the new window. Is this a limitation of Fyne?

This is not a known issue - content should be able to be moved between windows. Be sure that you have removed it from the old first as any object can only appear in one place.

If it is not working please do open an issue - it may relate to a cache miss or overlap.

[andydotxyz]

Upstream is landed so I'm putting the terminal fix in place now - but I cannot seem to find the right combinations.

I get: shift+del = 46 (also "."?), shift+ins = 48 (also "0"?) but I cannot find ctrl+ins

Any hints? Not sure I'm on the right rack here...

[drunlade]

@andydotxyz I'm unsure what's happening for you, I doubt shift-ins is supposed to map to 48.

Pretty sure 46 maps DEL doesn't it, not .? And Insert should generate 45, not 48?