This adds the ability to open the terminal from the main Plasma Shell
context menu. It was originally written as a Red Hat/Fedora patch
for KDE Workspace 4 to open Konsole from the desktop context menu
when Fedora switched to KDE 4, and ported forward to KDE Plasma 5
when Fedora Linux switched to Plasma 5 in Fedora 22.
It has been maintained as a downstream patch since then.
This version of the patch genericizes the patch by not implying that
Konsole is the user's terminal (it actually opens the user's chosen
terminal anyway), can be restricted via the desktop kiosk mode
settings, and is disabled by default.
The major maintainers of this patch are being honored as co-authors
for this patch. They have all helped keep this functionality working
across two KDE major versions for a decade.
Co-authored-by: Daniel Vrátil <dvratil@redhat.com>
Co-authored-by: Jan Grulich <jgrulich@redhat.com>
Co-authored-by: Marc Deop <marcdeop@fedoraproject.org>
Co-authored-by: Rex Dieter <rdieter@fedoraproject.org>
BUG: 451217
These items don't have anything to do with the desktop itself, so that's
not really the right place for them, making it unlikely that anyone
would expect to find them in the desktop context menu.
Instead, these items are probably there as a sort of emergency escape
valve so that people can still lock the screen and log out under the
following set of circumstances:
1. They've accidentally removed their launcher menu or primary panel,
or it has gotten lost due to multi-screen arrangement bugs
2. ...And they don't know how to perform these actions from KRunner
3. ...And they don't know the keyboard shortcuts for these actions
This seems very unlikely, given how we have made it much harder to
accidentally remove your panel and its applets over time, how much
robustness work we've put into multimonitor workflows, and how we now
even have a UI to restore panels that have gotten lost anyway. So
having these actions in the context menu specifically to protect
against such an unlikely happenstance is therefore not worth it, and we
can safely remove them by default (note that users can add them back)
to unclutter the context menu and make it more relevant to the desktop
itself.
---
There is no need to handle the now-orphaned menu separator as QMenu
takes care of automaticlaly suppressing separators when they are the
last item in the menu.
OpenUrlJob
We are starting a KService, but with extra steps. Use the appropriate
job.
This fixes launching apps since OpenUrlJob, by default, doesn't launch
executables
BUG: 449900
This is something that came up in the monthly VDG meeting: the desktop
context menu has a lot of stuff in it, and we're looking to slim it down
where possible so it isn't so overwhelming.
One potential target is the Activities menu item, which has no real use
for a user who isn't using activities. We can never be 100% sure, but if
there is only one activity, it's a good bet the user isn't using the
feature. In this case, we can hide the menu item that shows the
switcher, because there's nothing to switch to!
Now, the switcher also has a button to add new activities, so it could
be argued that this change makes activities less discoverable. However
the feature is shown pretty prominently in the commonly-accessed
Workspace Behavior group in System Settings, so I think it's already
discoverable enough.
Test plan:
- Have one activity and right-click on the desktop > See no menu item
- Create a second activity and right-click on the desktop > See it
Here's how the menu looks now when there is only one activity:
cc @teams/vdg@ivan
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
Neal Gompa
l10n daemon script
Volker Krause
Nate Graham
Laurent Montel
Ahmad Samir
Nicolas Fella
Alexander Lohnau
Ezike Ebuka