SUMMARY When there exists a KNotes widget on desktop, it is impossible to paste files using Ctrl+V key sequence, because the file is inserted in the KNotes widget as file://PATH string STEPS TO REPRODUCE 1. Add KNotes widget on desktop 2. Copy some file to buffer 3. Paste the file on desktop using Ctrl+V OBSERVED RESULT file://PATH string is inserted in KNotes widget EXPECTED RESULT File is copied on desktop SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 19.10 KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.12.4
(In reply to Andrey Yashkin from comment #0) > When there exists a KNotes widget on desktop Plasma's notes widget is totally unrelated to KNotes, KNotes doesn't offer a widget to add to the desktop. Changing the product/component appropriately.
Confirmed, and this drives me crazy too.
*** Bug 455914 has been marked as a duplicate of this bug. ***
Say HI to QML API, where shortcuts can't be assigned "widget scope". Actions are global only and always ¯\_(ツ)_/¯ Maybe the best we could do is temporarily disable those actions completely when notes applet is not focused.
Then Paste wouldn't work on the desktop; doesn't seem ideal. There must be a satisfactory way to fix this somehow.
> Then Paste wouldn't work on the desktop; doesn't seem ideal. There must be a satisfactory way to fix this somehow. What I meant to say is that «Notes» applet's action should be disabled when the «Notes» applet is not focused, so that it (hopefully) would stop overriding window-global set of registered actions. (Not sure if what I'm saying technically makes any sense, or it's just a moonspeak)
Yeah, that sounds reasonable.
I briefly looked into shortcut API. So, normally there are two options to choose a shortcut context from: Application and Window. As the names imply, they work either on a per-window basis, or application-wide. There is no such option to limit them to a particular widget or QML subtree. There is no such thing as a FocusScope analogy. On the other hand, normal regular text fields are common in everyday programs, and they somehow manage to grab their shortcuts only when they are focused. Haven't looked into that yet, but I think something is just a bit over-engineered in this particular applet's implementation.
*** Bug 451635 has been marked as a duplicate of this bug. ***
According to https://bugs.kde.org/show_bug.cgi?id=451635 (resolved as duplicate), this does not seem to happen on Wayland. Still happens with X11 / Plasma 5.27.1.
(In reply to mrfrh from comment #10) > According to https://bugs.kde.org/show_bug.cgi?id=451635 (resolved as > duplicate), this does not seem to happen on Wayland. > Still happens with X11 / Plasma 5.27.1. I can reproduce on Wayland session of neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Graphics Platform: Wayland