*** Bug 358968 has been marked as a duplicate of this bug. ***

I recently helped someone to install openSUSE Tumbleweed on a laptop with highdpi display. Initially, the font was very small.

On the internet I found this article: https://unix.stackexchange.com/questions/219058/scaling-the-desktop-kde which helped to find the scaling option:

System Settings/Configure Desktop → Display and Monitor → Display Configuration → (Scroll down) -> Click "Scale Display" button. For German installations (which his was) the naming on each step is different and therefore harder to find out.

If not on the first level of the menu, one could add a submenu "Display" with the following options:
- Resolution (-> opens Displays dialog)
- Scaling (e.g. for HiDPI displays) (-> opens Displays dialog)
- Multiscreen setup (-> opens Displays dialog)

Each would open the same dialog but I think it helps getting the user quickly up and running with a properly configured display.

See also https://bugs.kde.org/show_bug.cgi?id=389249 (Make Desktop toolbox also available in System Tray).

Code to open kcm-kscreen should be similar to code for the clock applet opening kcm-clock.

Patch: https://phabricator.kde.org/D14830

*** Bug 417188 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/704

This has been rejected by a senior Plasma dev on multiple occasions; closing, sorry. Not my preferred outcome either, but sometimes that's life.

*** Bug 443810 has been marked as a duplicate of this bug. ***

I respectfully request that the Senior Dev, who is rejecting this request, please reconsider.

I feel very strongly about this particular request and I consider it a practical requirement that every desktop environment make "Display Settings" accessible via each and every working monitor. This way, anytime there is an issue with the primary monitor's ability to display, you always have the ability to configure, as Primary, one of the monitors that remains working.

This is especially crucial for a Desktop Environment like KDE Plasma, whose default settings provide no panels (and therefore no Application Menu) for any other display than the primary one.

For example, if a laptop's monitor stops displaying, its not so easy to just "unplug" it. It remains the primary monitor even though it isn't displaying anything. The laptop itself may not even realize that there's a physical issue with its primary display. What if you have important unsaved work on this built-in primary monitor that's no longer displaying?

You don't need to have a bad monitor to reproduce this scenario. It takes only 3 steps

STEPS TO REPRODUCE

1. Log into the KDE Plasma Desktop in a dual Monitor Set up.
2. Turn you primary monitor's display away from you, so that you cannot see anything displayed at all.
3. Attempt to access "Display Setting" on the remaining non-primary monitor (so that you can disable the primary monitor that theoretically isn't working and make the working monitor primary).

Source: https://bugs.kde.org/show_bug.cgi?id=443810

I'm typically not one who advocates the imitation MS Windows, but in this case, I see practical reasons as to why they put "Display Settings" into the right-click-context-menu of every display connected to the PC.

However, even without these practical considerations, I'm a big advocate of putting settings "at the place where they're used" as a matter of convenience. Since "Display Settings" are used to configure Displays, I can't think of a more pertinent menu-option-candidate for the right-click-menu of each monitor's desktop.

Please reconsider.

^^ Seems reasonable to me, maybe we can reconsider?

Recoverability is a sound argument.  

(FWIW, meta+p would also resolve this case, but I am aware that's not discoverable)

It would require other changes to exist before that helps anything.

If we added this menu right now. You right click, you select display settings, where that window appears is not explicit. If it appears on the primary monitor you still wouldn't be able to access it.

I thought windows opened on the window that has the cursor on it by default now

er, on the *screen

Indeed, active screen follows mouse is default now, so that's not a problem. System Settings will appear on the screen you right-click on to open it since the mouse is there.

I don't think so.

src/kcmkwin/kwinoptions/kwinoptions_settings.kcfg:
    <entry key="FocusPolicy" type="Enum">
        <default>ClickToFocus</default>

I know it changed but also got reverted as it broke all the unit tests, I don't think it changed again.


But to make sure I'm seen as compromising, here's a list of pre-requisites, then I promise I won't block anything:

 - Window should appear on the same screen (I won't be a pedant and argue about "what if it's already opened" or "what if the user changed...")

 - I would like other solutions to at least be considered. i.e integrating into edit mode It already has some KCM shortcuts, screen layout is loosely related to other layouts. 

 - A commit message that is phrased properly and problem driven like #9 (Nate, you know me well enough to know what I'm after:) )

Edit, that was obviously the wrong line of config

    <entry name="Placement" type="Enum">
        <default>Smart</default>

I see 

    <entry key="ActiveMouseScreen" type="Bool">
        <default>true</default>
    </entry>

at https://invent.kde.org/plasma/kwin/-/blob/master/src/kcmkwin/kwinoptions/kwinoptions_settings.kcfg#L139

That's different from what you're thinking of.

> Nate, you know me well enough to know what I'm after:)
I do. :)

I don't mind the idea of adding it into Edit mode, though. However there's a limited amount of horizontal space there, and I don't think it would necessarily solve the discoverability problem:

The two ways that you enter edit mode are long-press on the desktop and right-click on the desktop. In the case of long press, we're not solving the problem because that's also not discoverable, and in the case of right-click, well, if the user knows how to right-click on the desktop to go into edit mode, then they will surely see a "Configure Displays" item in the context menu. :)

Still, it makes more sense than the button to open the Activity Switcher, which has nothing to do with global editing.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/613

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1129

Git commit c911754653af3d59cda63f6cb3b741fbe41b37e9 by Nate Graham.
Committed on 20/10/2021 at 16:18.
Pushed by ngraham into branch 'master'.

Edit mode toolbar: Replace Activity Switcher button with KScreen KCM button

The Activity Switcher has nothing to do with editing global settings, so
it is not an appropriate thing to be on this toolbar.

Let's replace it with a button to open the KScreen KCM, which does
involve editing global things, and letting people access it from here
may help in cases where something's gone wrong and the screen with their
panel isn't showing it anymore so they can't access a means to launch
apps to get to System Setitngs to get to the KScreen KCM to juggle
things around and try to fix the problem.

M  +3    -4    toolboxes/desktoptoolbox/contents/ui/ToolBoxButton.qml

https://invent.kde.org/plasma/plasma-desktop/commit/c911754653af3d59cda63f6cb3b741fbe41b37e9

I have no clue how to access the "Activity Switcher" without Googling it. The only thing I know how to do, on a completely blank desktop, is to right-click it. From the context-menu produced, the closest thing I see to an "Activity Switcher" is "Activities". Clicking that, produces this:
https://i.imgur.com/ihZ6A5s.png

My request, and the submitter's request, was to put the "Display Settings" menu-item into the right-click-context-menu of every monitor's desktop. And in my own bug report, I additionally requested (with foresight) that you should also ensure that it opens on the very desktop that was right-clicked.

I hope someone at KDE appreciates directness: because anything that compromises the exactness of my prior sentence, compromises perfection. Assuming the "Activity Switcher" was something I used, and that it was easily "discoverable" from my "blank screen" (while ignoring panels to simulate default), was a false assumption. How, someone considers "Activity Switcher" a more pertinent location for "Display Settings", than the desktop's right-click menu, is beyond me.

Compared to GNOME, I'm thankful for any compromise from development. However, I consider this compromise less discoverable than what was requested.

Additionally, and separately, I also consider it less than optimal that panel-creations, created on an non-primary display, by default get place onto the primary desktop (sometimes overlaying an existing panel --terrible placement)! The oversight, of not putting display settings into the right-click context menu of each monitor's desktop, would have been easier to overcome had I been able to create a panel (with an Application Menu) onto the the very desktop that I right clicked to do so.

Again, I hope you appreciate directness: because I have plenty of it when I'm drinking.

My apologies: clicking "Activities" from the right-click-context-menu produced this:
http://neartalk.com/ss/ActivitySwitcher.png

>My request, and the submitter's request, was 

We don't take requests. We discuss problems.
If you have a problem we explore all solutions. Judging a proposal and only going with the route-zero approach is exactly the sort of thing that made me close the previous proposal.

"Zero route" approach? You closed the previous proposal because you didn't consider all the ramification of not granting it.

Now that you see more ramifications, you impose ridiculous requirements on Nate: causing him to implement a solution that's less than optimal.

Sometimes, the route propose by the reporter, is exactly optimal. Anything less leads to impertinence, as I see here.

If you want to surprise me, admit the proposal (as proposed) is optimal and don't try to make Nate shoehorn the request into an "Activity Switcher", when the more pertinent placement is EXACTLY as requested.

I don't expect my directness to persuade you at all. If anything you'll be completely put off by my words despite what truth they may hold. Again, I've been drinking. And my tact right now is deficient at best. I'm proud that I've at least restrained my profanity.

1) that MR did not put it in the activity switcher, it's somewhere else. 

2) I did say I wouldn't block it going in the context menu.

You know, I have to admit, you didn't pre-reject Nate from putting this into the context-menu. I'm not sure why I developed the perception that he was scared of not meeting your expectations of not doing so. I guess it was due to the utmost respect he obvious has for you.

I have a high regard for Nate, from the other bugs I've submitted. I guess I just detected from him, an apprehension to not disappoint you in this regard, but reviewing your words I see how this was probably unfounded.

Now, I will direct my drunk anger to Nate. Why didn't you put this in the right-click-context-menu as requested by multiple people?

I did. ...Well, at least, I proposed it: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1129

It still needs to be reviewed and approved before it'll be merged.

And yes, I do have the utmost respect for David. His reasoning that this needs to solve a real problem isn't unreasonable. I think we have found one though, which is why I submitted that merge request.

This is despite the fact that personally I think the desktop context menu is too cluttered and needs fewer things in it by default, not more. So submitting that work actually makes my future decluttering work harder, not easier, if it gets merged. That's how you know I think it does actually solve a real-world issue some people are having. :)

Gentlemen, please accept my apologies for being contentious and for jumping to false conclusions.

Git commit 4c8217008593f34fdd70ce8b579d1979a6b994a4 by Nate Graham, on behalf of Ezike Ebuka.
Committed on 19/12/2021 at 17:32.
Pushed by ngraham into branch 'master'.

Add "Configure Displays" action to desktop context menu

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>
FIXED-IN: 5.24

M  +1    -0    containmentactions/contextmenu/CMakeLists.txt
M  +35   -0    containmentactions/contextmenu/menu.cpp
M  +2    -0    containmentactions/contextmenu/menu.h

https://invent.kde.org/plasma/plasma-workspace/commit/4c8217008593f34fdd70ce8b579d1979a6b994a4

Great news! Thanks for that!

You're welcome!