[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com --- Comment #182 from Trent M --- Hi there, I'm experiencing this as well, but it's a subtle variation on what others have reported. For me, this happens regardless of whether or not I have any external displays, and it occurs on *all* displays. It's similar to the zombie desktop reported by Agron. I have a video of it taking place here: https://www.youtube.com/watch?v=e4dmn-F0p98 I'll also attach the xprop output shown in that video, in case it's relevant. I was hoping it'd be fixed in Plasma 5.25, but I just got the upgrade in Neon (great release, BTW; congrats!) and it's still occurring. Wayland does not work on this computer, so I can't use Wayland to get around it. (In reply to Fushan Wen from comment #181) > Could any people test > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1781 fixes > your issue? Thanks in advance. I am interested in testing this, but I am not sure how I would go about doing so in Neon. Patching system packages has always made me feel uneasy as a general thing, even having been on Linux for a very long time. :x However, I do have a BTRFS subvolume structure that makes it very low-risk to go absolutely ham on the system if I need to. Should I visit a specific Matrix channel for guidance on this? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 --- Comment #183 from Trent M --- Created attachment 149682 --> https://bugs.kde.org/attachment.cgi?id=149682&action=edit xprop output of the zombie desktop / black window Here's that xprop output. Sorry, I forgot to mention a couple things. My starting workspace is number #2; I use wmctrl to move over in a startup script that gets executed in autostart. But because of this, the zombie workspaces for me are actually 1, 3, and 4. And a `plasmashell --replace` does make it go away until the next boot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442901] GTK4 apps have double scaling on hidpi
https://bugs.kde.org/show_bug.cgi?id=442901
Trent M changed:
What|Removed |Added
CC||twilightinz...@gmail.com
--- Comment #40 from Trent M ---
Hi there. I hopped back to Neon from Kubuntu 22.04 to get Plasma 5.27, and
discovered that the fix discussed here breaks my setup as well. I have manually
defined fonts DPI of 120. The DPI was changed not just in xsettingsd, but also
in gtk-{3,4}.0/settings.ini as well. I worked around it by changing those
values to 122880 (120 * 1024) and making the files immutable.
> If plasma is going to pass this setting to xsettingsd, it should _at least_
> respect the setting of "force fonts DPI" in the fonts KCM.
100% this. Hardcoding a value for a workaround when it's based on something
configurable is never correct.
--
You are receiving this mail because:
You are watching all bug changes.
[KScreen] [Bug 466149] New: On Xorg, Plasma's idea of the monitor configuration differs from xrandr's
https://bugs.kde.org/show_bug.cgi?id=466149 Bug ID: 466149 Summary: On Xorg, Plasma's idea of the monitor configuration differs from xrandr's Classification: Plasma Product: KScreen Version: 5.27.0 Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: twilightinz...@gmail.com Target Milestone: --- SUMMARY Hi there. I was initially looking into this as a problem in 5.27 where if your primary monitor is the rightmost monitor, things that rely on the primary monitor being index 0 no longer work correctly, such as the Virtual Desktops Only on Primary KWin script (https://github.com/wsdfhjxc/kwin-scripts/tree/master/virtual-desktops-only-on-primary) But I also found that Steam now starts games on the leftmost monitor as well. My rightmost monitor is primary because of how my physical spaces are arranged at home and at work. I found a related complaint on reddit (https://www.reddit.com/r/kde/comments/114sl90/steam_launches_games_on_wrong_monitor_since_527/) and there, someone mentioned that configuring the primary monitor in xrandr was a workaround for them. But then I actually checked xrandr and found that its idea of the display configuration was somehow completely incorrect. My actual display arrangement is two monitors connected via a Dell WD19S dock, laptop closed, rightmost primary. That's what Plasma shows, too. What xrandr shows is that the laptop monitor is on, the leftmost monitor, and the primary monitor. And then only one of the external monitors is shown as connected. STEPS TO REPRODUCE 1. Connect laptop to a dock with two or more external monitors, and close the lid. 2. Configure in Plasma's display configuration, and set the rightmost monitor as primary. 3. Check xrandr configuration in a terminal. OBSERVED RESULT Plasma and xrandr are in disagreement on which monitor is primary, and what the display configuration actually is. EXPECTED RESULT Plasma and xrandr show the same configuration, and applications/scripts that use the primary monitor put things in the right place. SOFTWARE/OS VERSIONS Linux: 5.19.0-32-generic KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION xrandr output: Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384 eDP-1 connected primary (normal left inverted right x axis y axis) 1920x1080240.00 + 240.00 1680x1050240.00 1400x1050240.00 1600x900 240.00 1280x1024240.00 1400x900 240.00 1280x960 240.00 1440x810 240.00 1368x768 240.00 1280x800 240.00 1152x864 240.00 1280x720 240.00 1024x768 240.00 1024x768i240.00 960x720 240.00 928x696 240.00 896x672 240.00 1024x576 240.00 960x600 240.00 832x624 240.00 960x540 240.00 800x600 240.00 840x525 240.00 864x486 240.00 700x525 240.00 800x450 240.00 640x512 240.00 700x450 240.00 640x480 240.00 720x405 240.00 720x400 240.00 684x384 240.00 640x400 240.00 576x432 240.00 640x360 240.00 640x350 240.00 512x384 240.00 512x384i 240.00 512x288 240.00 416x312 240.00 480x270 240.00 400x300 240.00 432x243 240.00 320x240 240.00 360x202 240.00 360x200 240.00 320x200 239.99 320x180 240.00 320x175 239.99 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1-1 disconnected (normal left inverted right x axis y axis) DP-1-2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 509mm x 286mm 1920x1080 60.00*+ 1600x900 60.00 1280x1024 75.0260.02 1152x864 75.00 1024x768 75.0360.00 800x600 75.0060.32 640x480 75.0059.94 720x400 70.08 DP-1-3 disconnected (normal left inverted right x axis y axis) HDMI-1-0 disconnected (normal left inverted right x axis y axis) DP-1-0 disconnected (normal left inverted right x axis y axis) kscreen-console output: START: Requesting Config Received config. Took 14 milliseconds Screen: maxSize: QSize(16384, 16384) minSize: QSize(320, 200) currentSize: QSize(3840, 1080) - Id: 65 Name: "eDP-1" Type: "Panel (Laptop)" Connected: true Enabled: false Priority: 0 Rotation: KScreen::Output::None Pos: QPoint(0,0) MMSize: QSize(344, 194) FollowPreferredMode: false Scale: 1 Clones: None Mode: "
[KScreen] [Bug 466149] On Xorg, Plasma's idea of the monitor configuration differs from xrandr's
https://bugs.kde.org/show_bug.cgi?id=466149 --- Comment #1 from Trent M --- I am now experiencing an additional problem. When I start up Plasma, the panel appears on the left monitor. When I check the containments window, it believes that the leftmost monitor is the primary monitor. But the system settings window shows that the rightmost monitor is the primary window. Restarting plasmashell doesn't seem to make a difference. To get the configuration back the way I want it, I change the left monitor to primary, hit apply, and then change it back, and hit apply again. I don't know if this part is actually #461822, or if it's more related to my initial submission. Either way, I will have to move back to Kubuntu 22.04 and Plasma 5.25 for now, because my particular multi-monitor situation has regressed pretty badly. I will keep Neon and 5.27 around to get you more info when you need it; please let me know. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 466149] On Xorg, Plasma's idea of the monitor configuration differs from xrandr's
https://bugs.kde.org/show_bug.cgi?id=466149 --- Comment #3 from Trent M --- (In reply to David Edmundson from comment #2) > The xrandr output shows DP-1-1 disconnected, the kscreen output shows > DP-1-1 connected > > Are these different program outputs of the same setup? That's correct. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 466149] On Xorg, Plasma's idea of the monitor configuration differs from xrandr's
https://bugs.kde.org/show_bug.cgi?id=466149 --- Comment #8 from Trent M --- I can confirm this, with some caveats. So, the xrandr command line client is still showing an incorrect configuration. But while I was using Kubuntu 22.04 w/ Plasma 5.25 waiting for fixes on this, I noticed that its xrandr was doing the same thing. It was exhibiting the correct behavior--games start up on the right monitor, the virtual desktops only on primary script worked--but xrandr showed the completely wrong thing. So yes, I can confirm that the *behavior* is now correct again. Virtual desktops only on primary works again, and games are starting up on the correct monitor. Is the xrandr CLI's incorrect information just a red herring? One thing I can say is that xrandr no longer believes the disabled laptop screen is the primary monitor; it now believes DP-1-2 is the primary. That much did change, and that connector is consistent with what the primary monitor is supposed to be. I won't mark it as resolved myself because I'll leave it up to you all to decide whether or not xrandr's CLI saying the wrong thing is actually a problem. The behavior being correct is enough for me to use Neon as my daily driver again. đ -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 469666] New: kinfo attempts to invoke kcmshell6 on Plasma 5
https://bugs.kde.org/show_bug.cgi?id=469666 Bug ID: 469666 Summary: kinfo attempts to invoke kcmshell6 on Plasma 5 Classification: Applications Product: kinfocenter Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: twilightinz...@gmail.com CC: sit...@kde.org Target Milestone: --- SUMMARY Attempting to invoke the new kinfo utility mentioned in Nate's blog simply fails instantly with the following error: `/usr/bin/kinfo: 6: exec: kcmshell6: not found` STEPS TO REPRODUCE 1. open a terminal 2. kinfo OBSERVED RESULT /usr/bin/kinfo: 6: exec: kcmshell6: not found EXPECTED RESULT an output of my system information SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.19.0-41 (available in About System) KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 ADDITIONAL INFORMATION Well, it's just an itty bitty shell script, and here's the entire thing: #!/bin/sh # SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL # SPDX-FileCopyrightText: 2023 Harald Sitter export QT_LOGGING_RULES="*=false" exec kcmshell6 kcm_about-distro --args dump --platform offscreen ...Gee, I wonder where the problem is. ;P If I change kcmshell6 to kcmshell5, it works. -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 469666] kinfo attempts to invoke kcmshell6 on Plasma 5
https://bugs.kde.org/show_bug.cgi?id=469666 Trent M changed: What|Removed |Added Platform|Other |Neon Version|unspecified |5.27.5 -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 469666] kinfo attempts to invoke kcmshell6 on Plasma 5
https://bugs.kde.org/show_bug.cgi?id=469666 --- Comment #3 from Trent M --- Oh, nice! The fix is already in the pipe. Okay, thank you! -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 466149] On Xorg, Plasma's idea of the monitor configuration differs from xrandr's
https://bugs.kde.org/show_bug.cgi?id=466149 --- Comment #10 from Trent M --- Sorry, I guess I didn't explain it clearly. xrandr's CLI says that my active monitors are eDP-1, which is my laptop screen, and DP-1-2, which is my rightmost external monitor. But my actual active monitors are DP-1-1 and DP-1-2. My laptop screen is disabled. The lid's shut because it sits in front of my left monitor. This is reflected in the kscreen-console output. So xrandr incorrectly thinks I'm using eDP-1 and DP-1-2, whereas I'm actually using DP-1-1 and DP-1-2. There's one part of the issue that's solved, the one that affects usability the most. My primary monitor is correct, it's the rightmost one. And things that depend on that information are working again. What isn't solved is that xrandr thinks my leftmost monitor is the laptop screen, whereas it's actually an external screen, and kscreen has this correct. I don't know if it actually breaks anything significant, though. The resulting screen geometry is still correct. Both the laptop monitor and my left monitor are 1080p, and both xrandr and kscreen-console show they're side-by-side with the correct monitor indicated as primary. I was curious what would happen if I made the leftmost monitor primary. So I tried that, and xrandr still thinks the laptop monitor's on. And now it doesn't indicate any primary at all! Here's the xrandr output from that case. Note that my rightmost monitor has now moved to DP-1-3 for no discernible reason. kscreen-console shows this too. One of the very things that motivated the big multi-monitor rewrite! Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384 eDP-1 connected (normal left inverted right x axis y axis) 1920x1080240.00 + 240.00 1680x1050240.00 1400x1050240.00 1600x900 240.00 1280x1024240.00 1400x900 240.00 1280x960 240.00 1440x810 240.00 1368x768 240.00 1280x800 240.00 1152x864 240.00 1280x720 240.00 1024x768 240.00 1024x768i240.00 960x720 240.00 928x696 240.00 896x672 240.00 1024x576 240.00 960x600 240.00 832x624 240.00 960x540 240.00 800x600 240.00 840x525 240.00 864x486 240.00 700x525 240.00 800x450 240.00 640x512 240.00 700x450 240.00 640x480 240.00 720x405 240.00 720x400 240.00 684x384 240.00 640x400 240.00 576x432 240.00 640x360 240.00 640x350 240.00 512x384 240.00 512x384i 240.00 512x288 240.00 416x312 240.00 480x270 240.00 400x300 240.00 432x243 240.00 320x240 240.00 360x202 240.00 360x200 240.00 320x200 239.99 320x180 240.00 320x175 239.99 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1-1 disconnected primary (normal left inverted right x axis y axis) DP-1-2 disconnected (normal left inverted right x axis y axis) DP-1-3 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 531mm x 299mm 1920x1080 60.00*+ 50.0059.94 1680x1050 59.88 1600x900 60.00 1280x1024 75.0260.02 1280x800 59.91 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 832x624 74.55 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 HDMI-1-0 disconnected (normal left inverted right x axis y axis) DP-1-0 disconnected (normal left inverted right x axis y axis) 1440x900 (0x7e) 88.750MHz +HSync -VSync h: width 1440 start 1488 end 1520 total 1600 skew0 clock 55.47KHz v: height 900 start 903 end 909 total 926 clock 59.90Hz -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 466149] On Xorg, Plasma's idea of the monitor configuration differs from xrandr's
https://bugs.kde.org/show_bug.cgi?id=466149 --- Comment #11 from Trent M --- Sorry to double-post; looks like something in the new xrandr output escaped my notice until I posted it here. It *does* actually indicate a primary: DP-1-1, which it thinks is not connected at all. It also doesn't indicate that any particular mode is selected on eDP-1-1; there should be an asterisk by the one in use. So it's not using any mode, but it's connected and assigned to a screen position. đ¤ -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 480179] KDE Connect Daemon crashes after update to Frameworks 5.114.0
https://bugs.kde.org/show_bug.cgi?id=480179 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453345] New: Restarting or refreshing Plasma Shell causes launcher to be unopenable via keyboard shortcut or DBus command
https://bugs.kde.org/show_bug.cgi?id=453345 Bug ID: 453345 Summary: Restarting or refreshing Plasma Shell causes launcher to be unopenable via keyboard shortcut or DBus command Product: plasmashell Version: 5.24.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: twilightinz...@gmail.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 SUMMARY I refresh Plasma Shell via DBus whenever my screen arrangement changes as a workaround to make the minimize effect go to the right place, and sometimes restart it via `plasmashell --replace` if it acts weird in a different way. Any time I restart or refresh it this way, I become unable to open the application launcher both via its keyboard shortcut as well as via the DBus command (and the keyboard shortcut might just be doing the DBus command for all I know). STEPS TO REPRODUCE 1. `qdbus org.kde.plasmashell /PlasmaShell refreshCurrentShell` or `plasmashell --replace` 2. `qdbus org.kde.plasmashell /PlasmaShell activateLauncherMenu` OBSERVED RESULT The application launcher does not open. There is nothing in console output from Plasma Shell or the qdbus command to indicate that there is anything wrong. EXPECTED RESULT The application launcher opens. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.24.4 (available in About System) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453345] Restarting or refreshing Plasma Shell causes launcher to be unopenable via keyboard shortcut or DBus command
https://bugs.kde.org/show_bug.cgi?id=453345 --- Comment #2 from Trent M --- (In reply to Nate Graham from comment #1) > Hmm, those exact steps work for me. Is this X11 or Wayland? X11. I'm using an Optimus laptop with NVidia as the primary GPU to get around an xorg/kernel bug that makes the entire display stack lock up when playing games. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 452512] Many panel applets' Full Representations are too small in frameworks 5.93
https://bugs.kde.org/show_bug.cgi?id=452512 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com --- Comment #8 from Trent M --- (In reply to Nate Graham from comment #5) > JFYI I have notified packagers about backporting the fix to Frameworks 5.93 > (because Frameworks doesn't have minor bugfix releases). So if you're still > experiencing the issue, go bug your distros' packagers to get on that. :) What if the distro is Neon? I've brought it up in several Matrix channels to radio silence. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453345] Restarting or refreshing Plasma Shell causes launcher to be unopenable via keyboard shortcut or DBus command
https://bugs.kde.org/show_bug.cgi?id=453345 --- Comment #5 from Trent M --- (In reply to Nate Graham from comment #3) > Can you try on Wayland? I'm sorry it's taken me so long to get a reply to this. Nate, I have to be real with you. I am absolutely terrified to even *look* in Wayland's direction on this Optimus laptop. Because for the past few weeks, if trying to use Wayland broke anything on my system, I would be in *huge* trouble. I finally found some time to make islolated snapshots of my BTRFS subvolumes and boot into them so I could finally test this. Attempting to start Wayland on this computer takes me to a black screen and a cursor. No panel, no wallpaper. No keyboard shortcuts. Nothing. So Wayland has bigger problems on this setup. Sorry I made you wait so long only to give you no useful information other than "Wayland broke on Optimus, big surprise." -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] New: Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 Bug ID: 452581 Summary: Horizontal Bars style unable to show empty and low states Product: plasma-systemmonitor Version: 5.24.4 Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: twilightinz...@gmail.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- Created attachment 148139 --> https://bugs.kde.org/attachment.cgi?id=148139&action=edit Screenshot of not particularly meaningful horizontal bars. SUMMARY I'd like to use the Horizontal Bars style to show my total CPU usage, RAM usage, and Swap usage. But because of the way the bars are designed to show a dot with the bar's radius even when the value is zero, I can't get any useful information from it that way. If I try tweaking the QML such that it does take zero as a valid value, what ends up happening is that the left side of the bar has zero radius whenever the value is less than the radius. So is this actually a QML bug because of the fact that rectangle radius gets discarded when its width is smaller than its specified radius? The only way I can get the bars to show anything meaningful without looking inconsistent is if I tweak the QML to make their radius zero. STEPS TO REPRODUCE 1. Create a system monitor widget with horizontal bars style 2. Select sensors that you can reasonably expect to be low to zero, like total CPU usage percent and Swap usage percent. OBSERVED RESULT Values of zero are not meaningfully conveyed; they look more like 10% on a 40px vertical panel. EXPECTED RESULT A legitimately empty bar is shown when the value is zero, and some sort of small fill is shown for low values. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.24.4 (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93 Qt Version: 5.15.3 ADDITIONAL INFORMATION N/A -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 --- Comment #1 from Trent M --- I did manage to come up with something. By centering the second rectangle vertically within the parent and then making the height the minimum between parent.height and width x percentage, it at least looks better than no radius and/or letting it just square off the corners when the value is zero. I'll attach my patch and a screenshot of what it looks like now with low values. If this rectangle radius thing is something that can't be fixed in QML, I at least think this will make the horizontal bars more usable and meaningful. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 --- Comment #2 from Trent M --- Created attachment 148140 --> https://bugs.kde.org/attachment.cgi?id=148140&action=edit Screenshot of horizontal bars after patch, using smaller circles for low values. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 --- Comment #3 from Trent M --- Created attachment 148141 --> https://bugs.kde.org/attachment.cgi?id=148141&action=edit Patch to Bar.qml to allow for using smaller circles than the parent's height for low values. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 Trent M changed: What|Removed |Added Attachment #148141|0 |1 is obsolete|| --- Comment #4 from Trent M --- Created attachment 148142 --> https://bugs.kde.org/attachment.cgi?id=148142&action=edit Patch to Bar.qml to allow for using smaller circles than the parent's height for low values. (Corrected.) -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 --- Comment #6 from Trent M --- (In reply to Nate Graham from comment #5) > Looks like a legitimate issue, and your change seems sane to me. Would you > be interested in submitting a merge request with it? I can help! Definitely! And I would very much appreciate the help. The only thing I think I would want to change about my patch as it is now is that I might want to round up the rectangle height for the lowe values somehow such that it's always centered within the bar. So if the bar is 7px high, it will never have a 4px high rectangle that it can't actually center, or if the bar is 8px high, it will never have a 5px rectangle that it can't actually center. I'm sure there's some math to do this, but I haven't thought it up yet, haha. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 --- Comment #8 from Trent M --- I'm not sure if the bar can or can't have an odd-numbered height, but in my earlier implementation, the inner bar *could* have an odd-numbered height, which would result in more space on bottom than on top. I figured out a way to bump the height up to the nearest number that leaves equal space on top and bottom. This does lose precision, but it looks better. I'll attach my patch here anyways, but I think I found where the faces are upstream, so I'm going to get an MR ready. :) -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452581] Horizontal Bars style unable to show empty and low states
https://bugs.kde.org/show_bug.cgi?id=452581 --- Comment #9 from Trent M --- Created attachment 148302 --> https://bugs.kde.org/attachment.cgi?id=148302&action=edit Patch to Bar.qml to use smaller circles than the parent's height for low values, now clamping to values that fit evenly within parent. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451003] Desktop files should be copied instead of symlinked
https://bugs.kde.org/show_bug.cgi?id=451003 --- Comment #2 from Trent M --- (In reply to Nate Graham from comment #1) > Is this still reproducible with Frameworks 5.95? It's working for me, and I > recall some changes that might have fixed it. Can you check? Thanks! I just tried it, and it still creates a symlink to the desktop file in a non-user-writeable system Flatpak installation. Even if there's some (currently failing) logic to check if a .desktop file's location is writeable, like for example if it points to the per-user Flatpak installation instead of a system one, it should still be copying the desktop file instead, because if it's symlinked, an update will overwrite the user's changes. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kservice] [Bug 424716] Hidden=true handling incorrect
https://bugs.kde.org/show_bug.cgi?id=424716 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com --- Comment #1 from Trent M --- Hi. This bug is nearly two years old, and has become an actual problem now due to the advent of immutable distros where there are actual good reasons to hide system applications. For example, we are currently struggling with the fact that the Firefox included in SteamOS--an immutable distro included on the Steam Deck, which ships Plasma--is six versions behind. We need to be able to provide instructions to hide that version without disabling the OS's immutability, and rely on the one from Flathub until Valve changes their system image to rely on Flathub's build of Firefox. We should be able to copy firefox.desktop to `~/.local/share/applications` and make changes to it to hide it, but it doesn't work because of this incorrect behavior. It seems like we can get the system Firefox to disappear from the Internet section of Kickoff with `Hidden=true`, but it still appears if you search for it, and it is still offered as a default web browser. It seems a lot of other behavior that should allow it to at least be disambiguated doesn't work. I wanted to change the shortcut's name to "Firefox (System)" to at least differentiate it from the Flatpak, but that name change is entirely ignored for no discernible reason. I came looking to see if that was a reported bug, and instead found this bug report. It could be possible that a lot of override handling is straight up broken right now, not just Hidden handling. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453345] Restarting or refreshing Plasma Shell causes launcher to be unopenable via keyboard shortcut or DBus command
https://bugs.kde.org/show_bug.cgi?id=453345 Trent M changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Ever confirmed|1 |0 Status|NEEDSINFO |REPORTED --- Comment #10 from Trent M --- (In reply to Nate Graham from comment #9) > Can you confirm that when you run `qdbus org.kde.plasmashell /PlasmaShell > refreshCurrentShell` or `plasmashell --replace`, Kickoff explicitly loses > its default Alt+F1 shortcut? It doesn't seem to *lose* the shortcut, however, the presence of any *default* shortcut is gone, and doesn't ever come back. To clarify what I mean by that, in System Settings, the keyboard shortcut for Plasma -> Activate Application Launcher, there are no checkboxes at all under default shortcuts. The only shortcut that exists is Alt+F1 explicitly defined as a custom shortcut. So I guess the *default* shorcut is lost, and doesn't come back. But the *custom* shortcut is left alone. > If Kickoff also loses the Alt+F1 shortcut, it would make sense. That part of > the bug is fixed in Plasma 5.26 at least, which should effectively fix this > bug for you. Losing the shortcut still isn't ideal though. I suppose it would "effectively" be the case, but with that same definition, I "fixed" the bug by setting Meta+Space to run the qdbus command to open the launcher, which only works if the launcher has an Alt+F1 shortcut. I'd prefer to just bind the launcher to Meta+Space directly, but no keyboard shortcut at all--Alt+F1, Meta+Space, or otherwise--works after restarting plasmashell. Perhaps the "remove shortcut requirement for activating launcher" part of the fix 391322 might have a positive effect on the reliability of shortcuts other than the default one? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 451003] Desktop files should be copied instead of symlinked
https://bugs.kde.org/show_bug.cgi?id=451003 --- Comment #3 from Trent M --- I think I've made a breakthrough here. This is *mostly* a Flatpak-specific issue, and here is why. I just tested out trying to edit an application I've installed in a custom system-wide Flatpak installation, located at `/xusr/flatpak`. I try to change its name, it fails, then I go look at the file it made. It is a symlink instead of a copy, but here's where it gets interesting. Flatpak wants you to put the `exports/share` directory in XDG_DATA_DIRS so that the DE can read the applications in `exports/share/applications`, and it does that automatically nowadays, but here is the rub: everything in that directory is already a symlink! I checked the points-to field of the resulting symlink that was made in `$XDG_DATA_HOME/applications`. It's not pointing to `/xusr/flatpak/exports/share/applications/com.github.unrud.VideoDownloader.desktop`. It's pointing at `/xusr/flatpak/app/com.github.unrud.VideoDownloader/current/active/export/share/applications/com.github.unrud.VideoDownloader.desktop`, which is the *target* of the first file. I think the reason I had not realized this was the case was because if you use `cp` to copy that file, it dereferences all the symlinks on the way to the actual file without you having to specify the `-L` argument. I am not sure why it does that. But Plasma really was already copying the file... it was just copying the symlink as-is. What it needs to do is dereference every symlink it finds on the way. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 --- Comment #218 from Trent M --- Before you all move to a different DE for the time being, can we get some `wmctrl -lG` outputs from people being affected by this issue, along with your monitor arrangements? I believe I have made a strong case for the possibility that the desktop windows are being misplaced somehow, and the black screen is the root window. If we can get confirmation or deconfirmation on whether or not this is happening to you all, it will help the developers working on this issue solve it. Ctrl+Alt+T should be the default shortcut to open a new Konsole window, if you find yourself unable to open a terminal any other way. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 --- Comment #226 from Trent M --- That's my bad, I should have been more specific when I asked for the wmctrl output. This will only be relevant if you are running Plasma on X11. Output from other DEs won't be helpful because this bug is only relevant for Plasma, though it could offer insight to what other X11 DEs are doing with their desktop windows for multi-monitor. And wmctrl won't be helpful on Wayland. I'm surprised it works on Wayland *at all*, but I suppose it makes sense that it only outputs Xwayland windows. And something else I should have been more specific about is that `wmctrl -lG` needs to be run while the black screen situation is occurring, because I know it is sporadic for some of you. The idea is that we want to see where the desktop windows are located, and if they're in the wrong place, we want to catch that. So Greg's output is the one thus far that's relevant to the X11 case. Greg, was this created during a situation where the black screen issue was happening? Because if so, we've deconfirmed the relevance of desktop window placement: the desktop windows and plasma windows are appearing exactly where they should be: 0, 0 for one monitor and 2160, 0 for the other. However, if this was created when the black screen issue *wasn't* happening, then you have useful data in the sense that you know what the output *should* look like when things are working right. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 --- Comment #236 from Trent M --- Gene C is right; be careful that your window titles aren't showing any sensitive information when you share your results. It is my bad for not cautioning against that as well. I apologize. Lukas, your test case proves that my hypothesis is correct in some situations. It does not appear to be the case for all situations, but at least I was not completely off base. See here, when you are first experiencing the error: > 0x02400017 -1 1280 01920 1080 lukas-laptop Arbeitsfläche â Plasma > 0x0240001d -1 1920 01280 1024 lukas-laptop Arbeitsfläche â Plasma These are the desktop windows. The third through seventh columns represent x position, y position, width, and height, in that order. Now see the same windows when you are not having the problem: > 0x02400017 -1 1280 01920 1080 lukas-laptop Arbeitsfläche â Plasma > 0x0240001d -1 001280 1024 lukas-laptop Arbeitsfläche â Plasma One of your monitors' desktop windows stays in the right place, the one at 1280,0. That's your right-side monitor. However, the desktop window that should be covering your left monitor wanders off to 1920,0 in the case where you are experiencing the black-screen bug, leaving the completely useless root window exposed beneath it. And interestingly, it causes the two windows to overlap *partially*, not completely. Lukas, on your right monitor, do you sometimes see the wallpapers partially overlapped when this problem is occurring? The fact that your monitors have different sizes exposes a pretty interesting facet of this problem. During the case where the black screen monitor bug is occurring, the desktop windows don't seem to know which of them is the right-side monitor. The fact that the window for your 1280x1024 monitor goes to 1920,0 suggests that it thinks it's supposed to be on the right side for some period of time, and it just never gets corrected. Because your monitors are different sizes, you could actually fix this with devilspie2 or a KWin script: you would check the sizes of the windows of class plasmashell and type desktop. Whichever one is 1280x1024, you move it to 0,0. Whichever one is 1920x1080, you move it to 1280,0. You would not be able to use KWin's window rules to fix this though, because it doesn't let you match windows on their sizes. For folks with monitors that are the same size though, they're out of luck for a workaround; the windows seem to be identical otherwise. They don't expose any differentiating information via xprop, presumably because the windows are supposed to simply do the right thing by themselves, and they're unfortunately not at the moment. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448675] GTK 4 theme does not inherit color theme like gtk 3 theme
https://bugs.kde.org/show_bug.cgi?id=448675 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com --- Comment #3 from Trent M --- (In reply to Nate Graham from comment #1) > The technology we use to re-color apps (hot-pluggable GTK modules) was > removed by the GTK developers. We tried to talk to the GTK developers about > this but did not get anywhere. They were quite adamantly opposed to our use > case (dynamically re-coloring apps at runtime using theming) and did not > seem to have any interest in working to support it again. > > So we will have to find another way to do it, or else live with this feature > being broken forever. :( Isn't the technology used to recolor GTK apps just a CSS file with a list of color definitions used by the Breeze GTK theme, updated by kde-gtk-config on color scheme change? There's no recoloring module in any GTK3 Flatpak app, yet recoloring works just fine in those. You just have to restart GTK3 Flatpak apps if you change color, and I thought the GTK module was just for *that*. The *real* problem is that kde-gtk-config does absolutely nothing with regards to GTK4 configuration at the moment, even though the GTK4 theme supports the same set of colors as the GTK3 theme. At least, as far as I can tell, it does absolutely nothing. Searching kded/configeditor.cpp in the source for "gtk-3.0" gives plenty of hits, but absolutely nothing for "gtk-4.0". Quizzically, the codebase seems to have a recent commit to not use options deprecated in GTK4, but doesn't actually write any GTK4 files at all. You can probably work around this problem by linking all of the xdg-config/gtk-3.0 files into xdg-config/gtk-4.0. >From here, it's just a hop and a skip to recoloring Adwaita applications if we wanted to. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448675] GTK 4 theme does not inherit color theme like gtk 3 theme
https://bugs.kde.org/show_bug.cgi?id=448675 --- Comment #5 from Trent M --- > Yes, we can do custom CSS but as far as I;m aware, it won't update at runtime > like we currently have; you'll need to restart your GTK apps to see changes. > Someone who's familiar with GTK needs to work on this to make it happen. I may be misinterpreting the intention of your reply here; the vibe I'm getting is that if we can't have hot-reloading, you don't feel that this issue is worth addressing anyways. I'm not inclined to think you actually feel this way. Lack of hot-reloading and needing to restart GTK applications so that they reload gtk.css is a small inconvenience compared to not having the theme follow your colors *at all*, unless you have one of those setups that automatically changes the colors periodically. But that type of setup is already broken by apps that can't use the colorreload module anyways. Anyways, for a fix for this issue to be submitted upstream to kde-gtk-config, what do you think would be better? Writing identical files to the gtk-4.0 directory at the same time as writing to the gtk-3.0 directory, or simply creating a symlink in the gtk-4.0 directory to the relevant files in the gtk-3.0 directory? Should this part of the discussion take place elsewhere? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451003] New: Desktop files should be copied instead of symlinked
https://bugs.kde.org/show_bug.cgi?id=451003 Bug ID: 451003 Summary: Desktop files should be copied instead of symlinked Product: plasmashell Version: 5.24.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: twilightinz...@gmail.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 SUMMARY If you want to make an edit to a .desktop file for an application installed system-wide, like via Flatpak, and attempt to do so via the right-click menu of an application in Kickoff, a symlink to the .desktop file will be created in `$XDG_DATA_HOME/applications` , and the file will be uneditable. STEPS TO REPRODUCE 1. Right click on a Flatpak application in Kickoff 2. Click "Edit Application..." 3. Attempt to make edits to the application OBSERVED RESULT All attempted edits fail, because the file made in `$XDG_DATA_HOME/applications` is a **symlink** to a file that is not user-writable. EXPECTED RESULT A **copy** of the file is made in `$XDG_DATA_HOME/applications`, and is thus editable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.24 KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION The case that made me notice this was attempting to edit Spotify's launcher after installing it via Discover; its default install method is system-wide. I wanted to add `--force-device-scale-factor 1.25` to the command line args but couldn't until I changed the symlink in `$XDG_DATA_HOME/applications` to an actual copy. Even if this is meant to somehow detect when the original .desktop files would be user-editable, like for the user Flatpak installation, I believe it is better to create a copy of the .desktop file so that changes are not lost on updates. I don't want to be forced to redo edits to get my desired scaling back every time Spotify updates. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 451012] New: Occasional "No such ref" error when attempting to install apps in flathub
https://bugs.kde.org/show_bug.cgi?id=451012 Bug ID: 451012 Summary: Occasional "No such ref" error when attempting to install apps in flathub Product: Discover Version: 5.24.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Flatpak Backend Assignee: lei...@leinir.dk Reporter: twilightinz...@gmail.com CC: aleix...@kde.org, jgrul...@redhat.com Target Milestone: --- SUMMARY Sometimes when searching for an application and attempting to install it, it fails with a "No such ref: (app ref) in remote flathub" toast. If you restart Discover, it usually works on the second attempt. STEPS TO REPRODUCE 1. Search for an application that is on Flathub 2. Attempt to install it OBSERVED RESULT Occasionally, an error toast will appear that will go away if you restart Discover and try again. EXPECTED RESULT It just installs the app. It found it in the search, how can it fail on installation? SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.24.2 (available in About System) KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION N/A -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 438608] "Open Folder" dialog freezes app
https://bugs.kde.org/show_bug.cgi?id=438608 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com --- Comment #17 from Trent M --- I reproduced this issue using KDE Neon 5.24 and two specific Flatpak apps: OBS Studio and youtubedl-gui. OBS Studio when trying to pick a directory to save recordings in, and youtubedl-gui when trying to pick a directory to save downloads in. OBS Studio is especially problematic because this app is published by upstream directly on Flathub; it's an official package from them. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 452000] New: System and user remotes with the same name are ambiguous
https://bugs.kde.org/show_bug.cgi?id=452000 Bug ID: 452000 Summary: System and user remotes with the same name are ambiguous Product: Discover Version: 5.24.3 Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Flatpak Backend Assignee: lei...@leinir.dk Reporter: twilightinz...@gmail.com CC: aleix...@kde.org, jgrul...@redhat.com Target Milestone: --- Created attachment 147795 --> https://bugs.kde.org/attachment.cgi?id=147795&action=edit Screenshot of inability to tell remotes apart when going to install an application in Discover. SUMMARY If you want to install an application into the user Flatpak installation, you must also have a remote specifically in that installation. So the most intuitive thing is to add the flathub remote to both the system and user installations. What you end up with as a result, unfortunately, are two remotes that you can't tell apart, and that Discover does not know how to disambiguate or prioritize. The Flatpak CLI sees this as an entirely valid thing to have, and will go out of its way to disambiguate the remotes in all operations: ``` ⯠flatpak install im.riot.Riot Looking for matches⌠Remotes found with refs similar to âim.riot.Riotâ: 1) âflathubâ (system) 2) âflathubâ (user) Which do you want to use (0 to abort)? [0-2]: ``` But Discover keeps both remotes ambiguous in multiple places. STEPS TO REPRODUCE 1. `flatpak --system remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo` 2. `flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo` 3. Search for any application, or go to Settings to try and decide remote priority OBSERVED RESULT You can't tell easily which remote you would be installing from, and you can't decide what remote has priority in Discover's settings. EXPECTED RESULT There is some way to tell which remote is for the system installation and which remote is for the user installation. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.24.3 (available in About System) KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION This can be worked around by giving the remote a different name when adding it, like "flathub-user". But it's not currently possible to rename remotes. If you've already got apps in the user installation, this gets to be a pain pretty quick. You have to uninstall all of your user apps, do a `flatpak --user uninstall --unused` to remove all the runtimes, delete the remote, re-add it, and then reinstall all of your user apps. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 452000] System and user remotes with the same name are ambiguous
https://bugs.kde.org/show_bug.cgi?id=452000 --- Comment #1 from Trent M --- Created attachment 147796 --> https://bugs.kde.org/attachment.cgi?id=147796&action=edit Screenshot of inability to set priority of same-named flathub remotes. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 454578] Mirrored displays are set to 1,0 instead of the 0,0 of the second display, causing desktop misbehaviour
https://bugs.kde.org/show_bug.cgi?id=454578 Trent M changed: What|Removed |Added CC||twilightinz...@gmail.com --- Comment #1 from Trent M --- I am actually experiencing this as well, but not with *mirrored* displays, but rather *vertically stacked* displays. You can reproduce this by just trying to stack the displays vertically in the GUI display configuration. If they already are, drag one away and then drag it back. You'll notice that when you check on the positions, one of them is going to be X = 1 no matter what you do. It just won't let two displays share X = 0 at all. There could be some sort of bad assumption regarding how displays are arranged that is biased toward horizontal arrangements; if you only arrange displays horizontally, it makes sense that you never want them to have the same X position. It causes some really weird breakages when you have the displays misaligned by just one pixel. I had some nasty graphical glitches when I went back to Intel-as-Primary, that went away once I was able to get the displays horizontally aligned via manual configuration. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 --- Comment #195 from Trent M --- Hi there. I actually have managed to fix my version of the issue, and even though it is different from what the rest of you are experiencing, what I discovered may provide a hint for fixing it, so I thought I would stop by and share my findings in hope that they will be helpful, at least for the Xorg case. I had an idea that maybe the window that represents the Plasma desktop had somehow managed to get itself stuck on a specific workspace, and in order to confirm my findings, I used `xwininfo` instead of `xprop` on the black screen and received this output: ``` xwininfo: Window id: 0x979 (the root window) (has no name) Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1920 Height: 2160 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+0 -0+0 -0-0 +0-0 -geometry 1920x2160+0+0 ``` That black screen is actually the root window! Plasma's desktop has a different output: ``` xwininfo: Window id: 0x2400013 "Desktop â Plasma" Absolute upper-left X: 0 Absolute upper-left Y: 1080 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1920 Height: 1080 Depth: 32 Visual: 0x28a Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x2400012 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+1080 -0+1080 -0-0 +0-0 -geometry 1920x1080+0-0 ``` And then, I decided to run `xprop` again, but this time, on the desktop. ``` _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_DESKTOP(CARDINAL) = 1 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_USER_TIME(CARDINAL) = 43952 _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 44930 _NET_WM_STATE(ATOM) = _NET_WM_STATE_BELOW _KDE_NET_WM_DESKTOP_FILE(UTF8_STRING) = "org.kde.plasmashell" XdndAware(ATOM) = BITMAP WM_NAME(STRING) = "Desktop" _NET_WM_NAME(UTF8_STRING) = "Desktop â Plasma" _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1 WM_CLIENT_LEADER(WINDOW): window id # 0x2400015 WM_HINTS(WM_HINTS): Client accepts input or input focus: True window id # of group leader: 0x2400015 WM_CLIENT_MACHINE(STRING) = "Stealth" _NET_WM_PID(CARDINAL) = 2116 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 37748756 WM_CLASS(STRING) = "plasmashell", "plasmashell" WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 0, 1080 user specified size: 1920 by 1080 window gravity: Static ``` The second line is the one most of interest: the desktop is assigned to a specific virtual desktop. That's not supposed to happen! I created a KWin rule that takes windows of class plasmashell and type desktop, and forces them to be visible on all desktops. That caused my version of this issue to be resolved! So what I can state with almost certainty is that the black window that people can't interact with is the root window. The desktop is supposed to cover up that window while being beneath everything else, and for some reason, that is not happening. It is possible that the state of the window representing the Plasma desktop is being mangled in such a way that the window manager is representing it correctly according to its internal state, but incorrectly according to user expectations. I have a multi monitor setup as well. The desktop is represented by a different window on each monitor; `xwininfo` shows different ids for clicking the desktop on each one. And `wmctrl` actually shows the same thing, as shown here. I threw in the G switch in order to get the geometry information; both position and size. ``` ⯠wmctrl -lG 0x04ac 0 40 1080 1880 1080 Stealth 353975 â Black screen on second display (no wallpaper, can't get a context menu on right-click) â Mozilla Firefox 0x05a3 -1 001920 1080 Stealth Spotify 0x03400014 0 40 1080 1880 1080 Stealth Inbox (30 unread) â Evolution 0x07e3 -1 001920 1080 Stealth Ferdium - Discord - Discord 0x06a2 0 40 1080 1880 1080 Stealth Joplin 0x04200013 -1 01080 1920 1080 Stealth Desktop â Plasma 0x04200019 -1 001920 1080 Stealth Desktop â Plasma 0x04200035 -1
[plasmashell] [Bug 453345] Restarting or refreshing Plasma Shell causes launcher to be unopenable via keyboard shortcut or DBus command
https://bugs.kde.org/show_bug.cgi?id=453345 Trent M changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED --- Comment #8 from Trent M --- Hi there. Nate, I noticed in one of your blog posts, you mentioned the following bug fix: > Application Launcher widgets that you activate by pressing the Meta key no > longer require that the Alt+F1 shortcut to be set, which should dramatically > reduce instances where you press the Meta key and nothing happens. After I used the Configure Application Launcher dialog to set the keyboard shortcut to Alt+F1, the qdbus command to open the launcher menu started to work again. What's funny is that if you restart plasmashell, the keyboard shortcut still stops working, but the qdbus command continues to work. The keyboard shortcut I really want for the launcher is Meta+Space, so I left Alt+F1 there, and created a custom shortcut that executes the qdbus command, and it continues to work across multiple restarts of plasmashell. So this bug is tangentially related to #391322, maybe? I think that what this proves is that the two symptoms: "keyboard shortcut stops working after restarting plasmashell" and "dbus command stops working after restarting plasmashell" are separate and not tied to the same root cause. -- You are receiving this mail because: You are watching all bug changes.
