Darkroom active window focus issue.

[chhil]

Have some text in clipboard, just ctrl+c some text from anywhere.
Put cursor in search module.
Mouse select a picture in the filmstrip at bottom, then ctrl+c to copy its history , select another pic where you want paste, ctrl+v.
Nothing happens to the picture, but you will notice that the search module text entry will have the copied text.

A similar thing happens using short cut ctrl+e when in the search module, no export happens. One needs to physically click in the main image window in darkroom to export the image.

I had "abc" on the clipboard, then did one ctrl+c, and multiple ctrl+v's resulting in multiple abc's in the search text window.

Since we are on clipboard issue, I have seen windows clipboard stops functioning at times when dt is running, I have to close DT to get back control of ctrl+c ctrl+v on my windows system for other apps.

I believe this has happened after the change that redirects key strokes per window.

darktable-3.1.0+9~g962bc9ae3-win64

[github-actions]

This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Please check if the master branch has fixed it since then.

[chhil]

Still an issue in the current dev version.

[dterrahe]

This may not be optimal, but it is intended behavior; whenever a cursor is in a text entry field, any darktable shortcuts are disabled. Otherwise you wouldn't be able to search for "lens correction" because typing L would take you to lightroom. Copying history has been assigned the same shortcuts that gtk uses for text entry, CTRL-C/CTRL-V, assuming this helps people remember, but the copy doesn't actually pass via the normal clipboard.

Presumably what you want is that, while in text entry mode, only single keys and those used in standard gtk text entry are disabled as dt shortcuts. I could consider this as a feature request for #8078 (with fairly low priority if I'm honest) if you could specify an uncontroversial list of combinations that should be exempt from suppression.

Alternatively it may be possible in #8078 to have the Entry widget take a first shot at interpreting key presses (using gtk_widget_event?) and only process them in the shortcut dispatcher if the Entry doesn't absorb them. Even if it works, there may be side effects to that approach that make it less predictable than the current blanked disabling of dt shortcuts, but it may be worth experimenting.

[johnny-bit]

@dterrahe - i think with #8078 and it's searchentry the problem is "gone" due to how search entry behaves... so IMO in my testing I'd consider #8087 "fixes" this issue. Would you agree?

[dterrahe]

#8078 includes the implementation of the suggestion I made above

Alternatively it may be possible in #8078 to have the Entry widget take a first shot at interpreting key presses (using gtk_widget_event?) and only process them in the shortcut dispatcher if the Entry doesn't absorb them.

which I think works well. After merging, it would be useful to review widget/central area focusing behavior all over the code base that was implemented to work with the gtk accelerator framework but might be simplified/improved now that the new shortcut system has complete control.

#8078 doesn't implement clipboard-like behavior for ctrl-c/ctrl-v of history items (i.e. pasting text or history depending on what was most recently copied) like this PR originally requested, so closing this would more accurately be a wontfix (which would be my position).

[johnny-bit]

Well, I do agreee with "won't fix" because i expect text entry to respect text-entry behaviour and 'normal' in-darktable copypaste to work normally outside of text entries :)