[plasmashell] [Bug 371717] Containment for the second monitor is lost and turns black for 30 seconds on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #55 from Michal Ziabkowski --- For what it's worth, this seems to be fixed in Plasma 5.27. Even with my sleep workaround disabled, I get my wallpaper instantly, just like expected. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466127] New: Tiling configuration works erratically on cloned screens
https://bugs.kde.org/show_bug.cgi?id=466127 Bug ID: 466127 Summary: Tiling configuration works erratically on cloned screens Classification: Plasma Product: kwin Version: 5.27.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Custom Tiling Assignee: kwin-bugs-n...@kde.org Reporter: mz...@o2.pl CC: notm...@gmail.com Target Milestone: --- SUMMARY I have two screens - a monitor (the primary screen) and a TV (which clones the primary screen). When I change the splits in tiling settings dialog, they seem to be changed not for the primary screen, but the other one. The end result is that the config changes don't apply. What I mean by this is that when I drag a window holding Shift, the new splits I've just added aren't there. Looking looking at kwinrc, I have two tiling sections for each screen: [Tiling][112a321c-1187-5b40-909d-f3bcef9080fa] - which seems to be TV [Tiling][8e33597a-6e65-5852-ba3f-f97b7fd8a401] - which is the monitor (primary screen) When changing the settings, they get applied to the first section (the TV), although it's not the primary screen. If I copy the tile settings to the second section (the monitor) and restart kwin, the new splits appear as intended. Additionally, the config dialog doesn't seem to update. It only shows changes after I restart kwin. This might also be related to the issue of settings being applied to the wrong screen. STEPS TO REPRODUCE 1. Set up a primary screen and a cloned screen 2. Open the tiling config dialog 3. Add new splits OBSERVED RESULT Splits aren't added for the primary screen, but the cloned one EXPECTED RESULT The config dialog shows the current (primary) screen and changes are applied to it SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.10-gentoo (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 23.4 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1650/PCIe/SSE2 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] Plasma theme highlight effect doesn't appear on hover in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #15 from Michal Ziabkowski --- For what it's worth, changing my mouse back to libinput didn't change anything. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] Plasma theme highlight effect doesn't appear on hover in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #14 from Michal Ziabkowski --- Created attachment 153467 --> https://bugs.kde.org/attachment.cgi?id=153467=edit Screencast of the Overview effect on a clean account -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] Plasma theme highlight effect doesn't appear on hover in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #13 from Michal Ziabkowski --- Created attachment 153466 --> https://bugs.kde.org/attachment.cgi?id=153466=edit Screencast of Present Windows on a clean account -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] Plasma theme highlight effect doesn't appear on hover in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #12 from Michal Ziabkowski --- Okay, so I tried creating a new user and starting afresh. I don't get the hover effect even on a totally stock Plasma 5.26 config. Attaching screencasts for this and the overview effect. One thing that is non-standard on my system that should not have any bearing on this is that I'm using evdev instead of libinput for my mouse, since the latter lacked some options I needed. Just thought I'd mention this just to be on the safe side. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] Plasma theme highlight effect doesn't appear on hover in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #11 from Michal Ziabkowski --- (In reply to Nate Graham from comment #10) > Oh, I thought from your first comment that you had modified the file locally. > > I'm at a loss to explain why this one single feature is missing the typical > Plasma theme highlight effect on hover, but it works everywhere else. > > Do you see the highlight effect in the Overview effect? I did in fact edit the qml file, but reverted it immediately after noticing it didn't help. Anyway, the overview effect doesn't have the highlight either. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] No hover effect in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #9 from Michal Ziabkowski --- (In reply to Nate Graham from comment #8) > That's odd. It sounds like the highlight effect exists and is being applied > to other things correctly, but not Present Windows. > > Can you clear the cache with `rm ~/.cache/*plasma*`, reboot, and try again? > > Also is it possible that your local overrides have interfered with this? Can > you revert to the distro package version too? Thanks! Clearing the cache and rebooting didn't fix it. What do you mean with local overrides? I'm using the Plasma 5.26 packages from the Gentoo official repo. All I did was unmask 5.26, since 5.25 is the current stable version in Gentoo. Should I downgrade to 5.25.5 then? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] No hover effect in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #7 from Michal Ziabkowski --- (In reply to Nate Graham from comment #6) > Do you see a highlight effect on hover for list and grid items in Kickoff, > or for thumbnails in the Task Manager tooltips, or for list items in System > Tray popups? I don't use Kickoff, but the Application Menu. But I do see a hover effect on the pinned apps to the left of the list and on the list items. I also see it for the systray popup and when hovering over task icons. I have the task thumbnails disabled, so I have no tooltips. What I've tried: switching the Plasma theme, color scheme, window decorations. Nothing helped. Maybe this depends on a kwin effect or a config setting I have disabled? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] No hover effect in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #5 from Michal Ziabkowski --- (In reply to Nate Graham from comment #4) > Thanks. What Plasma theme are you using? I'm using a third-party theme called IOTA-Plasma, but for the sake of testing I've just now switched to Breeze and it doesn't seem to make a difference. I'm still not getting the highlight effect. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] No hover effect in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #3 from Michal Ziabkowski --- Created attachment 153377 --> https://bugs.kde.org/attachment.cgi?id=153377=edit Screencast showing the problem -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] No hover effect in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162 --- Comment #2 from Michal Ziabkowski --- (In reply to Nate Graham from comment #1) > It has a highlight effect that appears behind the window when hovered. Are > you not seeing that? Yeah, I'm not seeing this at all. Uploading a short screencast for reference. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461162] New: No hover effect in Present Windows effect
https://bugs.kde.org/show_bug.cgi?id=461162
Bug ID: 461162
Summary: No hover effect in Present Windows effect
Classification: Plasma
Product: kwin
Version: 5.26.2
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: effects-present-windows
Assignee: kwin-bugs-n...@kde.org
Reporter: mz...@o2.pl
Target Milestone: ---
SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug
symbols.
See
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***
After upgrading from Plasma 5.24 to 5.26, I've noticed that the newly rewritten
Present Windows effect has no visual feedback when hovering the cursor over a
thumbnail. In the old one the hovered item was enlarged and highlighted, which
felt much more organic.
I've tried editing windowview/qml/main.qml and adding this to the
windowThumbnail definition, to no avail:
HoverHandler{
onHoveredChanged: {
if(hovered){
windowThumbnail.scale = 1.2
}
else{
windowThumbnail.scale = 1
}
}
The new effect seems to otherwise work fine, except for this blemish. Are there
any plans to restore the old behavior in some form or is this a bug on my end?
STEPS TO REPRODUCE
1. Activate the Present Windows effect
2. Hover the mouse cursor over one of the window thumbnails
OBSERVED RESULT
There is no animation for the hovered thumbnail.
EXPECTED RESULT
The hovered thumbnail shows visual feedback.
SOFTWARE/OS VERSIONS
Operating System: Gentoo Linux 2.9
KDE Plasma Version: 5.26.2
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.5
Kernel Version: 5.15.71-gentoo (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 23.4 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 1030/PCIe/SSE2
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #51 from Michal Ziabkowski --- I've added a 5-second delay before plasma-plasmashell.service is run with this override: [Service] ExecStartPre=sleep 5 While not ideal, this seems to have worked around my missing wallpaper bug. This confirms my theory that plasmashell is starting too early, before screens are properly configured. I have no clue how one would properly resolve this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #50 from Michal Ziabkowski --- Yes, unfortunately Plasma 5.25 didn't fix anything for me. Still getting a black background for the first 30 or so seconds. It doesn't even have to be a full reboot. Logging out and in again also causes the issue to happen. Tried to make sure plasma-plasmashell and plasma-kwin_x11 start after plasma-kscreen by adding this systemd config override for each (what I alluded to in comment #44): [Unit] After=plasma-kscreen.service Wants=plasma-kscreen.service While it didn't break anything, it didn't fix the bug either. Looking at the timestamps, all three services seem to be starting concurrently still, so I guess the override didn't work. Can anyone familiar with the code weigh in on where the 30 second timeout before the containment fixes itself comes from? I see a TimeoutSec=40sec in plasma-plasmashell.service, but that can't be it, right? The shell does start and the panel is present, it's just the wallpaper that's missing, so it's not as though the entire service is timing out. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #46 from Michal Ziabkowski --- I'm currently on Plasma 5.24.5. And I'm fairly positive that I've been getting the black background consistently ever since upgrading to the 5.24 series. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #44 from Michal Ziabkowski --- A little update: the situation seems to have changed in that now I reliably get a black background which fixes itself in about 30 seconds. Which begs the question - is there some kind of preset timeout somewhere in plasma-shell or kscreen code, after which the outputs are re-probed or the containment is updated? Unlike what I reported earlier, now the behavior is totally reproducible. My educated guess is that there is a race condition between plasma-shell and kscreen. The latter is probably reconfiguring my other screen to be 1080p AFTER Plasma is already running and the containment has been created. I haven't mentioned it, since it didn't seem relevant at the time, but I'm using systemdBoot=true. It's probably worth seeing if forcing plasma-kscreen.service to start before plasma-plasmashell.service (but after plasma-kwin_x11.service, I assume?) changes anything. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #42 from Michal Ziabkowski --- It seems I've spoken too soon. The bug still appears, but seems much harder to trigger without multiple activities. I've gone through several reboots not being able to replicate it until it suddenly happened. So while multiple activities seem to exacerbate the issue, the only real constant is having multiple screens. Is there anything else I could to help debug this? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #41 from Michal Ziabkowski --- After testing for a few days, I can say pretty conclusively that removing the second activity seems to have resolved the issue. So whatever it is, it seems to be triggered by the combination of multi-screen (different native resolutions might also be at play) AND multiple activities. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #40 from Michal Ziabkowski --- Created attachment 146126 --> https://bugs.kde.org/attachment.cgi?id=146126=edit kactivitymanagerdrc Also attaching my kactivitymanagerdrc (before removing the second activity) for reference. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #39 from Michal Ziabkowski --- Created attachment 146124 --> https://bugs.kde.org/attachment.cgi?id=146124=edit appletsrc after a few reboots I'm attaching my appletsrc after a few reboots with the other screen turned on, just in case. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #38 from Michal Ziabkowski --- I've found something that might also be related. My systemd journal (I'm using the systemd session) has a dozen or so instances of this just a few seconds after boot: plasmashell[584]: requesting unexisting screen 2 Moreover, I'm getting the same message with screen -1 every 15 minutes or so, which seems worrying. I'll try to remove one of my activities and see if it still happens with a single one. For the record, I have tried removing and recreating both activities and it didn't fix the issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371717] Containment for the second monitor is lost and reset to its default settings on boot or when it is connected
https://bugs.kde.org/show_bug.cgi?id=371717 --- Comment #37 from Michal Ziabkowski --- Cross-posting from bug 447388, as advised by Nate Graham: Okay, I've finally found some time for some more extensive testing. To remove some variables out of the equation, I purged my appletsrc, changed the wallpapers for both my activities (I have two with different wallpapers) and rebooted a few times. I can attach the config file, but I believe the changes between runs are more interesting: After the first reboot, the path to the wallpaper changes and a new containment is added: @@ -22,7 +22,7 @@ DialogWidth=800 [Containments][1][Wallpaper][org.kde.image][General] -Image=/usr/share/wallpapers/SafeLanding/ +Image=file:///usr/share/wallpapers/SafeLanding/contents/images/5120x2880.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][2] @@ -92,6 +92,20 @@ Image=/usr/share/wallpapers/OneStandsOut/ SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers +[Containments][25] +ItemGeometries-1920x1080= +ItemGeometriesHorizontal= +activityId=c850a35c-21b5-4a3d-a501-e439889d7d98 +formfactor=0 +immutability=1 +lastScreen=2 +location=0 +plugin=org.kde.plasma.folder +wallpaperplugin=org.kde.image + +[Containments][25][Wallpaper][org.kde.image][General] +Image=file:///usr/share/wallpapers/Next/contents/images/1920x1080.png + [Containments][8] activityId= formfactor=2 On the next reboot, the wallpaper path changes again, for the other activity, it seems: @@ -89,7 +89,7 @@ DialogWidth=800 [Containments][24][Wallpaper][org.kde.image][General] -Image=/usr/share/wallpapers/OneStandsOut/ +Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/1920x1080.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][25] Then it changes again on the next reboot: @@ -89,7 +89,7 @@ DialogWidth=800 [Containments][24][Wallpaper][org.kde.image][General] -Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/1920x1080.jpg +Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/2560x1600.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][25] As a reminder, this is an X11 install with two screens, a 1080p one and a 4k one. The latter is set to clone the first one (without scaling) for convenience. It's possible that there are TWO bugs at play here. The changing wallpaper paths might also warrant some scrutiny, but the bug happens with my own wallpapers with no multiple versions for different resolutions, so it's likely not the main culprit. I have conclusive evidence that disconnecting the TV works around the bug. After doing that I couldn't reproduce it, the proper wallpaper appeared instantly. With the TV plugged in, the wallpaper would change to the proper one after 40 or so seconds. Sorry if this is hard to read. I can post more info, just tell me what you need. Please note that this is still on Plasma 5.23, but I got the exact same bug on Plasma 5.23.90, so whatever causes it isn't yet fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447388] Wallpaper reset erratically after upgrade to Plasma 5.23
https://bugs.kde.org/show_bug.cgi?id=447388 --- Comment #7 from Michal Ziabkowski --- Okay, I've finally found some time for some more extensive testing. Sorry it took so long. To remove some variables out of the equation, I purged my appletsrc, changed the wallpapers for both my activities (I have two with different wallpapers) and rebooted a few times. I can attach the config file, but I believe the changes between runs are more interesting: After the first reboot, the path to the wallpaper changes and a new containment is added: @@ -22,7 +22,7 @@ DialogWidth=800 [Containments][1][Wallpaper][org.kde.image][General] -Image=/usr/share/wallpapers/SafeLanding/ +Image=file:///usr/share/wallpapers/SafeLanding/contents/images/5120x2880.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][2] @@ -92,6 +92,20 @@ Image=/usr/share/wallpapers/OneStandsOut/ SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers +[Containments][25] +ItemGeometries-1920x1080= +ItemGeometriesHorizontal= +activityId=c850a35c-21b5-4a3d-a501-e439889d7d98 +formfactor=0 +immutability=1 +lastScreen=2 +location=0 +plugin=org.kde.plasma.folder +wallpaperplugin=org.kde.image + +[Containments][25][Wallpaper][org.kde.image][General] +Image=file:///usr/share/wallpapers/Next/contents/images/1920x1080.png + [Containments][8] activityId= formfactor=2 On the next reboot, the wallpaper path changes again, for the other activity, it seems: @@ -89,7 +89,7 @@ DialogWidth=800 [Containments][24][Wallpaper][org.kde.image][General] -Image=/usr/share/wallpapers/OneStandsOut/ +Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/1920x1080.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][25] Then it changes again on the next reboot: @@ -89,7 +89,7 @@ DialogWidth=800 [Containments][24][Wallpaper][org.kde.image][General] -Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/1920x1080.jpg +Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/2560x1600.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][25] As a reminder, this is an X11 install with two screens, a 1080p one and a 4k one. The latter is set to clone the first one (without scaling) for convenience. It's possible that there are TWO bugs at play here. The changing wallpaper paths might also warrant some scrutiny, but the bug happens with my own wallpapers with no multiple versions for different resolutions, so it's likely not the main culprit. I have conclusive evidence that disconnecting the TV works around the bug. After doing that I couldn't reproduce it, the proper wallpaper appeared instantly. With the TV plugged in, the wallpaper would change to the proper one after 40 or so seconds. So if this is hard to read. I can post more info, just tell me what you need. Please note that this is still on Plasma 5.23, but as I mentioned in a previous comment, I got the exact same bug on Plasma 5.23.90, so whatever causes it isn't yet fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447388] Wallpaper reset erratically after upgrade to Plasma 5.23
https://bugs.kde.org/show_bug.cgi?id=447388 --- Comment #4 from Michal Ziabkowski --- Well, upgrading to Plasma 5.23.90 doesn't seem to have helped. After upgrading and rebooting I got the same black wallpaper again. Moreover, on some reboots this delay before the actual wallpaper is display doesn't seem to happen, but it's like 1 in 10 boots, maybe not even that. When I get the time I will try with a fresh Plasma profile to see what happens to the containments in appletsrc between boots. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447388] Wallpaper reset erratically after upgrade to Plasma 5.23
https://bugs.kde.org/show_bug.cgi?id=447388 --- Comment #2 from Michal Ziabkowski --- (In reply to Marco Martin from comment #1) > I think more than a wallpaper reset this is often plasma thinks there is no > containment for that screen and creates a new one, probably driving to many > stray ones in the appletrs. > > can you post your ~/.config/plasma-org.kde.plasma.desktop-appletsrc ? > > also can you test if this still happens on 5.24? You may be onto something here. I've seen containment ids being added seemingly at random when examining my appletsrc, but I thought that some legacy cruft in my old config was to blame, so I disregarded and forgot about it. As I mentioned before, the bug also happens with a fresh appletsrc, though. But I never checked what goes on with the ids in a fresh appletsrc, so that would be a reasonable next step, I guess. I've yet to test on Plasma 5.24, so I will get back to you on that. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447388] New: Wallpaper reset erratically after upgrade to Plasma 5.23
https://bugs.kde.org/show_bug.cgi?id=447388 Bug ID: 447388 Summary: Wallpaper reset erratically after upgrade to Plasma 5.23 Product: plasmashell Version: 5.23.4 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Multi-screen support Assignee: aleix...@kde.org Reporter: mz...@o2.pl CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY Ever since upgrading to Plasma 5.23, one of three things will happen on a power cycle: a) I am greeted with a black background instead of the wallpaper b) the wallpaper is reset to the default one (/usr/share/wallpapers/Next/contents/images/1920x1080.png) c) more rarely the wallpaper is reset to one of the included I'd used previous (e.g. /usr/share/wallpapers/summer_1am/contents/images/2560x1600.jpg) The interesting thing is that the proper wallpaper will restore itself, if I wait about 20-30 seconds. I've tried deleting my plasma-org.kde.plasma.desktop-appletsrc and kactivitymanagerdrc, to no avail. My setup is a 1080p monitor connected via DVI and a 4k TV connected via HDMI. I have the latter set to 1080p and mirroring the primary 1080p screen. This seems similar to https://bugs.kde.org/show_bug.cgi?id=443832. However, I'm on nvidia-drivers. And that bug was filed against Plasma 5.22, whereas my issue only started with 5.23 and downgrading to 5.22 indeed makes the issue go away. One more pertinent piece of information: when I unplug the tv, the bug seems to go away. Hence why I've filed this against multi-screen support. STEPS TO REPRODUCE 1. Set custom wallpaper 2. Reboot OBSERVED RESULT The wallpaper is replaced by a blank background or the default wallpaper, then fixes itself after some seconds have passed EXPECTED RESULT The proper wallpaper is visible from the start SOFTWARE/OS VERSIONS Linux/KDE Plasma: Operating System: Gentoo Linux 2.8 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 Kernel Version: 5.15.10-gentoo (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 23.5 GiB of RAM Graphics Processor: NVIDIA GeForce GT 1030/PCIe/SSE2 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433471] Cover Switch and Flip Switch animations works unreliably after upgrade to Plasma 5.21
https://bugs.kde.org/show_bug.cgi?id=433471 --- Comment #9 from Michal Ziabkowski --- Applied the commit from the pull request above and it seems to resolve the issue for me. I've been using it for a week with no obvious side-effects. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433471] Cover Switch and Flip Switch animations works unreliably after upgrade to Plasma 5.21
https://bugs.kde.org/show_bug.cgi?id=433471 --- Comment #7 from Michal Ziabkowski --- Confirmed. But I see the same thing happens with any video playing, not just in a browser. I have a suspicion that it has to do with the window contents constantly changing and being marked as dirty, leading to the animation not being skipped as it would. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433471] New: Cover switch animation works unreliably after upgrade to Plasma 5.21
https://bugs.kde.org/show_bug.cgi?id=433471 Bug ID: 433471 Summary: Cover switch animation works unreliably after upgrade to Plasma 5.21 Product: kwin Version: 5.21.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: mz...@o2.pl Target Milestone: --- SUMMARY After upgrading to Plasma 5.21, I've noticed something off about the cover switch animation, which I'm using as the Alt-Tab switcher. When I keep pressing Alt-Tab in quick succession, I always get the rotation animation. But when doing it at a normal pace, I get the animation more or less half the time and an instant switch otherwise, which feels visually jarring. On a related note, the animation speed settings in the KCM doesn’t seem to do anything. Setting it to something as high as 1000 (I assume miliseconds?) didn't change a thing. STEPS TO REPRODUCE 1. Set Alt-Tab switcher to Cover Switch 2. Press Tab a few times while holding Alt OBSERVED RESULT The animation isn't displayed most of the time. EXPECTED RESULT The animation is displayed every single time when switching between tasks. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 428024] Toggle Night Color global hotkey broken after upgrading to Plasma 5.20
https://bugs.kde.org/show_bug.cgi?id=428024 --- Comment #10 from Michal Ziabkowski --- Yes, that seems to be exactly it. Which in itself wouldn't pose a problem, but the identifier used i18n by mistake, so it changed once the translation was in place. About the merge request, sure, but can I use Github? I haven't used the new invent.kde.org infrastructure. If I need to use the latter, this will take a bit longer. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 428024] Toggle Night Color global hotkey broken after upgrading to Plasma 5.20
https://bugs.kde.org/show_bug.cgi?id=428024 --- Comment #7 from Michal Ziabkowski --- No, I've been on Polish locale for years and definitely haven't changed anything. But I do distinctly recall the name for this shortcut being in English at one point, just after it was introduced. Sometimes the translations are spotty right after a new major release and it seems like this was the case here. Changing i18n to QStringLiteral in setObjectName and rebuilding KWin indeed made the shortcut work again for me. Regardless, the root of the problem is that identifiers shouldn't be dependent on current locale, yes. And a cursory glance at kglobalshortcutsrc reveals that all other identifiers are in English, as I'd expect. And looking at the code for other global shortcuts in KWin, this use of i18n for the object name seems like a simple mistake. Others use QStringLiteral there, so the identifier is always in English. So it's a bug with how global shortcuts are saved in general, just an oversight with this particular entry. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 428024] Toggle Night Color global hotkey broken after upgrading to Plasma 5.20
https://bugs.kde.org/show_bug.cgi?id=428024
--- Comment #5 from Michal Ziabkowski ---
So here's an interesting thing I've discovered:
The global shortcut seems to work on a fresh user account, but here's the
kicker: the line written in kglobalshortcutsrc is different.
On my old, non-working profile, the global shortcut line is:
Toggle Night Color=Meta+N,none,Toggle Night Color
On the new, fresh one it's localized in Polish:
Przełącz barwy nocne=Meta+N,none,Przełącz barwy nocne
I remember this shortcut not having a localized caption when I first set it.
And apparently now it's localized in Plasma 5.20. However, the global shortcuts
kcm still shows the old, English name and not the new localized one, which
apparently the shortcut not to work altogether.
But something about this seemed wrong, so I took a closer look at the KWin
source code. This stood out to me in colorcorrection/manager.cpp:
toggleAction->setProperty("componentName", QStringLiteral(KWIN_NAME));
toggleAction->setObjectName(i18n("Toggle Night Color"));
toggleAction->setText(i18n("Toggle Night Color"));
I believe the issue stems from setObjectName using i18n instead of
QStringLiteral, so the localized caption is used as the shortcut identifier.
This bug wasn't reproducible on your setup, since you're likely using English
locale, avoiding the issue entirely.
--
You are receiving this mail because:
You are watching all bug changes.
[kdeplasma-addons] [Bug 428024] Toggle Night Color global hotkey broken after upgrading to Plasma 5.20
https://bugs.kde.org/show_bug.cgi?id=428024 --- Comment #2 from Michal Ziabkowski --- Yes, kglobalaccel5 is running. Tested several other global shortcuts from different groups and they do work just as intended. It's just this one. I set the shortcut in the shortcuts KCM, under the KWin heading. It's set to Meta+N. It didn't conflict with any other shortcut before, nor should it now. I don't see any other global shortcuts with this combination, nor did I get a conflict warning. And it is indeed present in kglobalshortcutsrc. The issue appeared right after upgrading to Plasma 5.20, even without me changing a thing in my global shortcuts config. But, as previously stated, I set the global shortcut again just in case. It didn't help. Tried changing the hotkey to something else and no change either. The changes are saved to the config file, other shortcuts work, just not this one. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 428024] New: Toggle Night Color global hotkey broken after upgrading to Plasma 5.20
https://bugs.kde.org/show_bug.cgi?id=428024 Bug ID: 428024 Summary: Toggle Night Color global hotkey broken after upgrading to Plasma 5.20 Product: kdeplasma-addons Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Night Color Control Assignee: plasma-b...@kde.org Reporter: mz...@o2.pl CC: kwin-bugs-n...@kde.org, vlad.zahorod...@kde.org Target Milestone: --- SUMMARY After upgrading to Plasma 5.20, the Toggle Night Color global hotkey I had set-up stopped working. The colors don't change and there's no OSD notification. I tried setting the hotkey again, but it didn't change anything. For what it's worth, toggling from the systray icon works. I get the expected action - notification and color change. It's just the keyboard shortcut action that seems to be broken. STEPS TO REPRODUCE 1. Set Toggle Night Color global hotkey 2. Press it OBSERVED RESULT Nothing happens. EXPECTED RESULT Night color is toggled. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux KDE Plasma Version: 5.20.0 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 427824] Tilde (~) expansion no longer works
https://bugs.kde.org/show_bug.cgi?id=427824 Michal Ziabkowski changed: What|Removed |Added CC||mz...@o2.pl --- Comment #1 from Michal Ziabkowski --- Experiencing the same bug here. But I think it's actually in Plasma 5.20, not the krunner framework itself. I actually use a command with a tilde daily and it only broke for me the day after I'd upgraded to Plasma 5.20. I've had krunner 5.75.0 installed for a few days more before that with no issues. Operating System: Gentoo Linux KDE Plasma Version: 5.20.0 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407084] Changed behavior of profile shortcuts in Konsole
https://bugs.kde.org/show_bug.cgi?id=407084 --- Comment #4 from Michal Ziabkowski --- While it is disputable what the primary action for profile shortcuts should be (IMO switching profiles and starting a new tab are equally valid use-cases), I'm honestly not inconvenienced much by this change, just a bit surprised that my old shortcut suddenly had a different behavior. In my specific case, I haven't actually used the other profiles much recently, so changing my config and/or habits is feasible. If this behavior was changed for the sake of usability, I don't mind it. It's just some people might be confused as to what happened after upgrading, just like I was. In any case, thank you for the clarification. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407084] Changed behavior of profile shortcuts in Konsole
https://bugs.kde.org/show_bug.cgi?id=407084 --- Comment #2 from Michal Ziabkowski --- I see. What alternative is there for the old functionality, i.e. if someone wanted to have a shortcut for quickly opening a tab with a given profile? The New Tab actions for profiles aren't listed in the shortcut settings. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407084] New: Changed behavior of profile shortcuts in Konsole
https://bugs.kde.org/show_bug.cgi?id=407084 Bug ID: 407084 Summary: Changed behavior of profile shortcuts in Konsole Product: konsole Version: 19.04.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: mz...@o2.pl Target Milestone: --- SUMMARY Before Konsole 19.04, when you set a keyboard shortcut for a Konsole profile (in Settings/Manage Profiles), that shortcut would open a new tab with that profile. With Konsole 19.04 the shortcut switches the current profile for the currently open tab instead. I'm not sure if this was intentional or a regression that slipped in. In any case, browsing the menu confirms that the shortcuts are assigned to the Switch Profile actions instead of the New Tab ones. The same thing happens with a clean config as well. STEPS TO REPRODUCE 1. Set keyboard shortcut for profile in Settins/Manage Profiles 2. Use said shortcut OBSERVED RESULT The shortcut switches the profile for the currently open tab. EXPECTED RESULT A new tab is opened with the given profile. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.3 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 403106] Invalid rendering of borders in Midnight Commander under Konsole 18.12
https://bugs.kde.org/show_bug.cgi?id=403106 --- Comment #1 from Michal Ziabkowski --- Created attachment 117405 --> https://bugs.kde.org/attachment.cgi?id=117405=edit The correct rendering of mc using Konsole 18.08.3 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 403106] New: Invalid rendering of borders in Midnight Commander under Konsole 18.12
https://bugs.kde.org/show_bug.cgi?id=403106 Bug ID: 403106 Summary: Invalid rendering of borders in Midnight Commander under Konsole 18.12 Product: konsole Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: font Assignee: konsole-de...@kde.org Reporter: mz...@o2.pl Target Milestone: --- Created attachment 117404 --> https://bugs.kde.org/attachment.cgi?id=117404=edit The incorrect rendering of mc using Konsole 18.12.0 After upgrading to Konsole 18.12.0, I noticed that window borders in Midnight Commander were being rendered incorrectly. What I mean by that they are more squiggly instead of straight lines. Downgrading to 18.08.3 fixes the issue, so this seems like a regression introduced with the emoji support. To better explain what I mean I've attached screenshots of how it looked like in 18.08 and how it looks now. Though it shouldn't matter, the font I use is DejaVu Sans Mono. Midnight Commander is version 4.8.21 with Unicode support. The problem is present using other appearance presets in Konsole. I've ruled out it being a problem with Midnight Commander, as it's still present after removing the mc config. For testing purposes I also ran mc with LC_ALL=C, but this didn't change the rendering. Package versions used: Konsole 18.12.0 Qt 5.11.3 Plasma 5.14.5 KDE Frameworks 5.53.0 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 400158] Cannot reorder tasks after upgrading to Plasma 5.14.1
https://bugs.kde.org/show_bug.cgi?id=400158 Michal Ziabkowski changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #3 from Michal Ziabkowski --- Interestingly enough, after changing FolderTools.js back to the current version and trying many different things, I cannot reproduce the bug anymore. Must've been a one-time thing. Hmm, is it possible the kbuildsycoca cache wasn't up-to-date, and as such, the new mimetype introduced by said commit, didn't work as intended? That's my best guess. For the record, none of the items were pinned nor grouped. The only options changed were disabling the tooltips and setting the filter to current activity only. I updated Plasma one day and after a fresh boot the next day, I noticed I couldn't drag the tasks around anymore. But as it seems to have resolved itself on its own, I'm closing this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 400158] New: Cannot reorder tasks after upgrading to Plasma 5.14.1
https://bugs.kde.org/show_bug.cgi?id=400158 Bug ID: 400158 Summary: Cannot reorder tasks after upgrading to Plasma 5.14.1 Product: plasmashell Version: 5.14.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager Assignee: h...@kde.org Reporter: mz...@o2.pl CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY After upgrading to Plasma 5.14.1 from Plasma 5.13.5, I can no longer reorder tasks in the task manager (icon-only task manager) by dragging icons around. I get the red "cannot drag'n'drop here" sign instead of the usual cursor. I've been able to narrow the regression down to commit c801276a593c3787fa07fc6640028bcc32dfffd0. When I revert the change in FolderTools.js, I get the old, expected behavior back. STEPS TO REPRODUCE 1. Try dragging a task icon and drop it elsewhere in the task manager OBSERVED RESULT Cannot use drag'n'drop to reorder. EXPECTED RESULT The task is reordered. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.14.1 KDE Frameworks Version: 5.51.0 Qt Version: 5.11.2 -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 185030] Revival of kio_rar and kio_p7zip
https://bugs.kde.org/show_bug.cgi?id=185030 --- Comment #18 from Michal Ziabkowski <mz...@o2.pl> --- Actually, I've moved them to gitlab. Haven't done anything with the code, though. Anyway, here are the links: https://gitlab.com/kio_rar_kde4 https://gitlab.com/kio_p7zip_kde4 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 373653] Konsole occasionally displays the wrong context menu on right click
https://bugs.kde.org/show_bug.cgi?id=373653 --- Comment #7 from Michal Ziabkowski <mz...@o2.pl> --- I've actually found a better, sure-fire way to trigger the bug: 1) Right-click to display the normal popup 2) Right-click anywhere inside the application window This also causes the "Configure shortcut" popup to be displayed. >From what I know, the popup in question should only display when right-clicking menu items, which lets you customize the hotkeys. It seems as though the wrong event is triggered somehow. I can confirm the bug is not Konsole-exclusive. Just tried ark and got the same behavior. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 373653] Konsole occasionally displays the wrong context menu on right click
https://bugs.kde.org/show_bug.cgi?id=373653 --- Comment #2 from Michal Ziabkowski <mz...@o2.pl> --- Yes, that's a good observation. However, you don't even need to right-click the popup. It seems that as long as the normal popup is open, right-clicking anywhere inside the terminal will display the other "Configure shortcut" popup. This is a regression in that right-clicking again used to close the current popup and redisplay it in the new location, and not display the other, completely different popup. The bug is still reproducible in Konsole 16.12.1 and Qt 5.7.1. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 374253] Single file/folder archives are not detected properly
https://bugs.kde.org/show_bug.cgi?id=374253 --- Comment #8 from Michal Ziabkowski <mz...@o2.pl> --- Your test archive seems to be detected properly. My archive was created from the command line using zip v3.0: zip test2.zip test2/test However, a zip archive created with 7zip v16.02 also causes this bug: 7z a test2.zip test2/test The archives in question seem to be valid. A quick file comparison reveals the structure is somewhat different for some reason. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 374253] Single file/folder archives are not detected properly
https://bugs.kde.org/show_bug.cgi?id=374253 --- Comment #5 from Michal Ziabkowski <mz...@o2.pl> --- Indeed, if there is a single folder with more than one file, the archive is treated as a single folder archive. If however, the folder contains only one file, it is not. Another problem is that the configuration option doesn't mention "more than one top-level folder", but "more than one top-level entry", which covers both files and folders. At least that's one possible interpretation. So either the string should be clarified or the behavior changed in line with the description. The crucial question is why should single file archives be treated differently than single folder ones? When extracting an archive with a single file inside, I believe most people wouldn't expect a folder to be created. I understand this was changed for semantic reasons, but the old behavior made more sense in my opinion. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 374253] Single file/folder archives are not detected properly
https://bugs.kde.org/show_bug.cgi?id=374253 --- Comment #4 from Michal Ziabkowski <mz...@o2.pl> --- I've attached two test archives. However, the bug happens with all archives I've tried. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 374253] Single file/folder archives are not detected properly
https://bugs.kde.org/show_bug.cgi?id=374253 --- Comment #3 from Michal Ziabkowski <mz...@o2.pl> --- Created attachment 103048 --> https://bugs.kde.org/attachment.cgi?id=103048=edit Archive with single folder -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 374253] Single file/folder archives are not detected properly
https://bugs.kde.org/show_bug.cgi?id=374253 --- Comment #2 from Michal Ziabkowski <mz...@o2.pl> --- Created attachment 103047 --> https://bugs.kde.org/attachment.cgi?id=103047=edit Archive with single file -- You are receiving this mail because: You are watching all bug changes.
[khotkeys] [Bug 373655] Input Actions daemon checkbox in Custom Shortcuts kcm doesn't reflect actual configuration
https://bugs.kde.org/show_bug.cgi?id=373655 --- Comment #2 from Michal Ziabkowski <mz...@o2.pl> --- I'm hesitant to do that, since this is probably not the proper fix, just a quick workaround. It would be nice if someone with a deeper insight could look into the actual cause of the problem. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 374253] New: Single file/folder archives are not detected properly
https://bugs.kde.org/show_bug.cgi?id=374253 Bug ID: 374253 Summary: Single file/folder archives are not detected properly Product: ark Version: 16.12.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: elvis.angelac...@kde.org Reporter: mz...@o2.pl CC: rthoms...@gmail.com Target Milestone: --- After upgrading from the old KDE4-based Ark to the one based on KDE Frameworks, the single file/folder detection seems to have stopped working altogether. Despite the "Extract to a subfolder if the archive has more than one top-level entry" option being enabled, "Extraction into subfolder" is still enabled by default when trying to extract single file/folder archives. I've been able to reproduce this with a few archive types, including 7z, rar and zip. It seems to be a general bug in the logic. Disabling "Extract to a subfolder if the archive has more than one top-level entry" works as intended and disables subfolder extraction. Steps to reproduce: 1) Enable "Extract to a subfolder if the archive has more than one top-level entry" 2) Open an archive containing a single file or folder 3) Click Extract Result: "Extraction into subfolder" is enabled, when it shouldn't Ark 16.12.0 KDE Frameworks 5.29.0 Qt 5.7.1 -- You are receiving this mail because: You are watching all bug changes.
[khotkeys] [Bug 373655] New: Input Actions daemon checkbox in Custom Shortcuts kcm doesn't reflect actual configuration
https://bugs.kde.org/show_bug.cgi?id=373655
Bug ID: 373655
Summary: Input Actions daemon checkbox in Custom Shortcuts kcm
doesn't reflect actual configuration
Product: khotkeys
Version: 5.8.4
Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: k...@michael-jansen.biz
Reporter: mz...@o2.pl
Target Milestone: ---
Created attachment 102783
--> https://bugs.kde.org/attachment.cgi?id=102783=edit
Use !settings->isDaemonDisabled() to set the daemon checkbox
While input actions work just fine, it seems the "Start the Input Actions
daemon on login" checkbox doesn't reflect the actual configuration. My
khotkeysrc has Disabled=false in [Main]. However, in the gui the option appears
as the daemon is disabled, i.e. the checkbox is unchecked.
Further investigation shows the config is loaded properly, it's never used in
GlobalSettingsWidget::doCopyFromObject, which instead does:
ui.enabled->setChecked(file.readEntry("X-KDE-Kded-autoload", false));
At least on my install this always returns false, since the .desktop doesn't
have this key.
Enclosed please find a quick fix, which uses !settings->isDaemonDisabled() to
set the checkbox. I'm unsure, however, if that's the proper fix.
Here are some system specs:
kde-frameworks 5.29.0
Qt 5.6.2
xcb platform
--
You are receiving this mail because:
You are watching all bug changes.
[Oxygen] [Bug 373654] New: Missing media-mount action icon in Oxygen icon theme
https://bugs.kde.org/show_bug.cgi?id=373654 Bug ID: 373654 Summary: Missing media-mount action icon in Oxygen icon theme Product: Oxygen Version: 5.8.4 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: icons Assignee: n...@oxygen-icons.org Reporter: mz...@o2.pl Target Milestone: --- The oxygen icon theme are missing the media-mount action icon, which is used by the device notifier following commit ec87c140122c7343fd1bca219d0a394d07bdc5b7. The icon in question is only present in the breeze and breeze-dark icon themes. This leads to the mount action being hard to discover, since no icon is displayed unless using the breeze and breeze-dark themes. The problem can be easily worked around by copying the old emblems/emblem-mounted icon, but an upstream fix would be appreciated. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 373653] New: Konsole occasionally displays the wrong context menu on right click
https://bugs.kde.org/show_bug.cgi?id=373653 Bug ID: 373653 Summary: Konsole occasionally displays the wrong context menu on right click Product: konsole Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: mz...@o2.pl Target Milestone: --- When right-clicking, there is a 1-to-5 chance than Konsole will display a context menu with the "Configure shortcut..." and "Add to Toolbar" (inactive) options instead of the regular Konsole one. The likelihood of the wrong menu appearing increases when clicking in rapid succession. Upon some quick investigation, this seems to be the menu from kxmlgui's KMenuMenuHandler, which is erroneously displayed for some reason. The bug is similar to #351595. However, I've never had two menus displayed at the same time unlike the reporter of that bug, so I'm filing this as a separate issue. I am quite certain it is not a mouse issue, since the problem only appeared when I switched from the old KDE4-based Konsole to the frameworks-based one. The way to reproduce is really simple: 1) Start Konsole 2) Right-click a few times somewhere in the middle of the terminal Here are some system specs: Konsole 16.08.3 kde-frameworks 5.29.0 Qt 5.6.2 xcb platform -- You are receiving this mail because: You are watching all bug changes.
