Commit ecc938a6 authored by Nate Graham's avatar Nate Graham
Browse files

Remove "Lock" and "logout" items from default desktop context menu

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


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.
parent aed28558
Pipeline #151017 passed with stage
in 10 minutes and 2 seconds
......@@ -75,6 +75,8 @@ void ContextMenu::restore(const KConfigGroup &config)
disabled.insert(QStringLiteral("configure shortcuts"));
disabled.insert(QStringLiteral("run associated application"));
// clang-format on
  • In my opinion, this was probably a bad move. At Kubuntu Focus (, out of 5 people testing Plasma 5.25.0 all 5 complained about this being removed. We had to check that this was not a bug. These people do not come from a UNIX background.

    Although many people do not come from a UNIX background, those with a UNIX background expect this logout option to be there when right-clicking on the background, and you can see this in most legacy window managers. Unfortunately, removing this can, has, and will break many people's workflows, especially for people who are less adaptable than others.

    For what it's worth, I don't use this, but I am sympathetic to those that do.

  • It's configurable; people can add these menu items back if they want:

    Right-click on desktop > Configure Desktop and Wallpaper… > Mouse actions > Right-Button > click the configure button > add them back

    This means you can ship with a config file that re-adds the menu items if you feel like our decision was the wrong one.

    But I wonder... what non-UNIX background do these people have that made them expect this functionality in the context menu in the first place? To my knowledge, this functionality is not present in the desktop context menu for Windows or macOS, which we reasoned are most likely to be the desktop OSs that new Plasma users are most familiar with. Could it be that your non-UNIX-background testers simply got used to it from previous versions of Plasma?

    Edited by Nate Graham
  • Yes, they got used to it from previous versions of Plasma, plain and simple.

  • Then they can add them back, or you can do it for them with your packaging. :)

  • mentioned in issue #49 (closed)

    Toggle commit list
  • Nate, what does what windows or MacOS have to do with KDE? What makes either of them the ideal to aspire too? The majority of Linux users are Linux users because the got fed up with the BS way windows does things. It is incomprehensible to me why anyone who left that garbage would want to imitate it's look and function! Just because windows removes a function or NEVER had it is absolutely NO reason to remove it from any Linux desktop! If people want an arcane system to imitate windoze they can go back to the windoze morass! If Linux devolves to nothing more than a windoze clone that doesn't run any windoze programs, it has well and truly lost it's mission! The published documents indicate that KDE is in bed with Microsoft. That it disgraceful! If developers at KDE love windows so much, I suggest that they be sent over to work for microsoft rather than keep dragging KDE from the pinnacle of Linux desktop to a disgusting clone of why we all left windoze in the first place!

  • Windows and macOS have nothing to do with Plasma really, and we don't explicitly copy them. See

    Quite simply, the reason for removing these menu items by default was the persistent negative feedback we got about the length of the desktop context menu. People said it was "overwhelming" "too long to find anything" "way too much random stuff in there" and so on. We got this feedback in bug reports, in social media complaints, and in YouTube video reviews of Plasma.

    So far I have noticed no such feedback at all from users of Plasma 5.25. So that seems to indicate to me that going in this direction was the right decision.

    If you don't agree, you're welcome to re-add them to your desktop context menu, as the menu is configurable.

    "Simple by default, powerful when needed."

  • Hi Nate:

    I agree with "Simple by default, powerful when needed" mantra as well. However, I also believe in "Don't break userland." The problem here is this simple feature has been default in all Unix systems for 30 years. Removing it breaks all those established workflows.

    "So far I have noticed no such feedback at all from users of Plasma 5.25": We have reported that all testers in one round (actually 6 of 6) - 100% - were severely inconvenienced and confused by this removal. It's one option, but it's used all the time.

    Almost always I agree with your UX sensibilities. However, in this case, I respectfully disagree (FWIW, I have been director of UX for many projects). If this stands and Kubuntu updates to 5.25.x, I fear we will have a substantial number of support cases based on the 100% failure rate mentioned above.

    Sincerely, Mike

    EDIT: Yes, users can add this critical feature back in, but writing and notifying users is an extremely expensive undertaking, as is writing, testing, and deploying theme scripts to restore the option.

    Edited by Michael Mikowski
  • Like I said, you're welcome to add it back for your own users if you think it's going to be a support problem, as this is configurable.

    In general I agree with you about not breaking userland, but unfortunately we often don't have a way to preserve existing user settings when we change defaults. I wish we always did, and if we did for this, I would have used it (as I used it when I changed some global shortcuts in KWin recently). This is a solvable technical problem, but someone (probably a few someones) needs to add this "don't change existing user settings if they're using the default settings" feature into more places.

    A few years ago I proposed a thing to allow users to opt into (or out of) having default settings changed upon upgrade but it didn't end up going anywhere as nobody (myself obviously included) stepped up to do the requisite technical work that would be needed.

  • Thanks Nate.

    Unfortunately, there is a big added problem: This is applied per screen - at the same level as the wallpaper. So now, to add it back, we have to loop through containers and add the feature to each and every one. Many of our users employ multiple monitors, so this just got way more complicated. While it is preserved for hot-plugged, I'm assuming we'd need to add it for every unrecognized monitor that is ever attached.

    I think this is an example of a simple, single change has unexpected consequences where the work-around is very expensive, intrusive, and hard to maintain. It's not the end of the world, and I understand if you want to keep it as-is. But here is a strong vote for bringing it back for all the reasons discussed above.

    Sincerely, Mike

    ps. We actually have also investigated a more elegant way to apply upgraded and historical preferences, and it is a hard problem. Let me know if there is a way we can sponsor an experienced developer to help with this and other issues.

  • Screenshot_20220629_131059

    While playing around, discovered that the leave button doesn't actually match reality. Probably just a typical race condition. The work-around is to turn off, apply, turn back on, apply again. This must be done for every attached screen.

    Edited by Michael Mikowski
  • I can confirm that. Definitely a bug. Can you file a bug report?

    Regardless, if you're finding that this patch is problematic for your users, you're welcome to ship a patch to revert this commit. It's just two lines so it should revert easily.

    But I stand by the decision made here in KDE. These menu items cluttered up the context menu, which is something we got a lot of complaints about. Addressing that means removing some things by default, and someone was always going to complain about the chosen removals.

Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment