Summary: | Notes widget on the desktop steals the ctrl+v keyboard shortcut even when Folder View appears to have focus | ||
---|---|---|---|
Product: | [Plasma] kdeplasma-addons | Reporter: | Andrey Yashkin <andreyyashkin> |
Component: | notes | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugseforuns, goodaqua, med.medin.2014, mrfrh, myriam, nanoblade9, nate, wbauer1 |
Priority: | NOR | Keywords: | usability |
Version: | 6.1.5 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kdeplasma-addons/-/commit/a226f8cb7661951ee56d1e7eac8993e61788c016 | Version Fixed In: | 6.3.0 |
Sentry Crash Report: |
Description
Andrey Yashkin
2020-02-07 00:51:10 UTC
(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 *** Bug 493369 has been marked as a duplicate of this bug. *** Fixed by Marco Martin with https://invent.kde.org/plasma/kdeplasma-addons/-/commit/a226f8cb7661951ee56d1e7eac8993e61788c016 for Plasma 6.3.0! |