Having an "Add Panel" item in the panel context menu communicates to the
user that the new panel will be placed on the existing panel somehow, or
at least will bear some relationship to it. However this is false; the
new panel is added to the desktop containment, not the panel
containment. Therefore it is inappropriate to have this item in the
panel context menu since it has nothing to do with the panel that has
been right-clicked on.
This action is the "Open in Dolphin" menu item in the context menu. This
menu item is not very useful; there is little reason to open the entire
desktop view in Dolphin because it's already visible on the desktop!
Disabling this item by default makes the context menu a tiny bit more
approachable by removing a fairly useless item from it.
With a multi-screen setup, it's possible to get into a situation where
all of your means to launch apps have gone missing because a screen
forgot its containmewt or moved the only panel onto a disabled output,
or any number of other issues that unfortunately have not yet been
resolved. In such a situation, it is common for people to try to fix it
by visiting the KScreen KCM to switch around their primary screens,
enable disabled outputs, turn it off and on again, etc.
However if your only visible means to launch apps has gone missing, you
may have a hard time accessing the KScreen KCM. In such a circumstance,
it can be helpful to have the action in the desktop context menu so that
people can right-click on the wallpaper of any screen that *is* working
and make System Settings launch with the KScreen KCM on that screen.
Co-authored-by: Nate Graham <nate@kde.org>
BUG: 355679
FIXED-IN: 5.24
This commit implements what was agreed upon in
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/690, but
does it correctly by simply disabling the menu item by default, not
removing it entirely. This ensures that the change is only made for new
installs. Existing users' configs will not be touched (because all
values are serialized to the config file already), and any new users
will be able to re-enable this item if they like it.
CCBUG: 437747
This reverts commit 1cb254416c.
This change was not implemented in the correct way. The context menu is
configurable, so instead of removing the possibility of the menu item
ever being in the menu, we should have simply removed it from the
default set of menu items.
BUG: 437747
FIXED-IN: 5.22
In the past, this was considered to be a way to make KRunner more
discoverable by users.
However today Kickoff exposes all the same runners as KRunner, so its
full functionality is therefore more discoverable in a different way,
so making the KRunner UI itelf more discoverable is not as important.
Furthermore, this was always a questionable way to increase
discoverability in the first place, because the menu item did not expose
the keyboard shortcut, which is the typical way that people show
KRunner. Also, context menus are generally considered shortcuts for
experts; novice users don't tend to use context menus very much. But
experts are the people more likely to already know about KRunner and its
keyboard shortcut, and would never invoke it using the desktop context
menu.
Removing this menu item de-clutters the desktop context menu a bit, and
we do get complaints that the menu is overwhelming because it has too
many things in it. This is a fairly unimportant item that we can remove
without any real consequences.
Finally, Marco didn't like the change to refer to KRunner using the
actual term "KRunner" in the main UI, so this change removes one of the
two places where that happened. :)
This came up in today's VDG meeting. A user who right-clicks on the
desktop is highly likely to want to change the wallpaper, but the menu
item that does this is the last item in the menu, not the first. We can
move it up to the top.
The "Open with Dolphin" item is likewise moved up too so that we don't
have two single-item sections in a row.
l10n daemon script
Alexander Lohnau
Nate Graham
Ezike Ebuka
Adrien Faveraux
Nicolas Fella
Felipe Kinoshita