[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 --- Comment #15 from Matthew Guiddy --- Just posting to say that this is now fixed for me now that I updated to 5.27. Operating System: openSUSE Tumbleweed 20230220 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 --- Comment #14 from Matthew Guiddy --- Created attachment 153684 --> https://bugs.kde.org/attachment.cgi?id=153684=edit Shaded windows still not valid target for snapping Updated video showing shaded windows not being a valid target for snapping after the bug was marked as fixed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 --- Comment #13 from Matthew Guiddy --- Sorry to be a bother, but I see it says "Version Fixed In: 5.26", however I still cannot snap to shaded windows despite the installed version being 5.26.3. I won't change the status in case there's a misunderstanding on my part. In order to rule out something unique to my install, I tried it on a fresh Tumbleweed install in a VM and a KDE Neon Live disk running in a VM. Same result, shaded windows are not a valid snap target. I'll add a new video attachment of testing on a KDE neon live disc. Tumbleweed SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSUSE Tumbleweed 20221110 (available in About System) KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 Kernel Version: 6.0.7-1-default (64-bit) Graphics Platform: X11 KDE neon Live SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.26 (available in About System) KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 Kernel Version: 5.15.0-52-generic (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 461713] New: Unexpected behavior occurs when certain alarm types are set to trigger within an hour of Daylight Savings Time ending.
https://bugs.kde.org/show_bug.cgi?id=461713 Bug ID: 461713 Summary: Unexpected behavior occurs when certain alarm types are set to trigger within an hour of Daylight Savings Time ending. Classification: Applications Product: kalarm Version: 3.5.2 Platform: OpenSUSE OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: djar...@kde.org Reporter: mgui...@yahoo.com Target Milestone: --- Created attachment 153683 --> https://bugs.kde.org/attachment.cgi?id=153683=edit Video showing the bug in action. SUMMARY They key problem seems to be alarms set to for recurrence. "One time" alarms did not seem to cause a problem. "Command Alarms", with "Daily Recurrence", set to trigger during the hour before Daylight Savings Time ends will continually trigger. I also noticed a spike in CPU usage for kalarm. I marked as major severity because I imagine this could potentially cause system instability if the command is CPU or resource intensive. "Sound Alarms", with "Daily Recurrence", set to trigger during the hour before Daylight Savings Time ends will continually trigger, but will wait until the sound finishes playing before starting again. I also noticed near 100% cpu usage for kalarm. "Daily Recurrence" "Display Alarm" fails to display the alarm. kalarm shoots to nearly 100% cpu usage. Longer description of testing process in Additional Information section. STEPS TO REPRODUCE 1. Set timezone to be a timezone that observes Daylight Savings Time. For example, "America/New York" 2. Set system time to before the hour before Daylight Savings Time ends (2AM on November 6th) so you can set an alarm for November 6th, sometime between 1 AM and 2 AM. For example, " timedatectl set-time '2022-11-06 00:51:45' " 3. Create a "Command Alarm" set to trigger on November 6th, between 1AM and 2 AM. Alarm must have "Daily Recurrence" set. For example, 2022-11-06 01:52 4. Set system time to a few seconds before alarm trigger time. For example " timedatectl set-time '2022-11-06 01:51:45' " 5. Wait until alarm trigger time. OBSERVED RESULT Command executes at set time but the alarm will continue to trigger as fast as the system can handle. If the command completes before 251 processes are created, it will trigger for an unknown length of time. If the command does not complete, kalarm will throw an error once 251 processes are created. EXPECTED RESULT The command runs once at the expected time. However, how kalarm handles the timezone change is debatable. It shouldn't run twice, but, in this example, should it run at 1:52 AM before the time change, or 1:52 AM after the time change. WORKAROUND Do not set alarms during the hour before the end of Daylight Savings Time. SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSUSE Tumbleweed 20221110 (available in About System) KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 Kernel Version: 6.0.7-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION I have a daily recurrence command alarm set for around 1:55 AM that silently starts recording TV. The command runs for around 1 hour. On November 6th, once it triggered, I started getting errors stating the command failed. I also noticed my system feeling sluggish. Upon investigating, I noticed a couple hundred processes running that were the expected command. Killing them just resulted in kalarm starting new ones. I had to pause the alarm to get things settled. In order to rule out any unique changes I've made to my system, I installed Tumbleweed fresh in a VM and reproduced the bug. I first used the following command to test: while true; do touch ~/Testing/test-$(date +%Y%m%d%H%M%S%N) && sleep 60; done It resulted in 251 processes starting, each running the command as expected. Then kalarm would throw a "Failed to execute command". To see what would happen if a command was run that would quickly complete, I tested the following: touch ~/Testing/test-$(date +%Y%m%d%H%M%S%N) It resulted in over 1000 test files being created in the few seconds before I disabled the alarm. The above tests were run with an alarm set to "Daily Recurrence". It seems alarms of all type that are set to "No Recurrence" do not trigger the bug. "Daily Recurrence" "Sound Alarms" will trigger the bug, however it manifests differently. It doesn't overlap playing of the sound, it will wait until the sound completes before starting again. However, during this time kalarm shoots to nearly 100% cpu usage. "Daily Recurrence" "Display Alarm" fails to display the alarm. kalarm shoots to nearly 100% cpu usage. I do not have email set up in order to test "Email Alarms". I have not tested what happens to an alarm set to go off in the hour that is skipped at the start of Daylight Savings Time. However I would
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 Matthew Guiddy changed: What|Removed |Added Version|5.8.5 |5.25.3 --- Comment #10 from Matthew Guiddy --- Just updating the report to state it still happens in 5.25.3. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 Matthew Guiddy changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED Ever confirmed|1 |0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 --- Comment #8 from Matthew Guiddy --- (In reply to kde.org from comment #7) > This issue report is quite old. Can you please confirm, that it still > persists with KDE 5.23? Just updated Tumbleweed a couple days ago and it is still happening. Based on version numbering, Tumbleweed is on KDE 5.23.2 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384217] Applications launched via Launcher share the same volume control.
https://bugs.kde.org/show_bug.cgi?id=384217 --- Comment #1 from Matthew Guiddy <mgui...@yahoo.com> --- Created attachment 107612 --> https://bugs.kde.org/attachment.cgi?id=107612=edit Firefox was launched via Panel shortcut widget. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384217] New: Applications launched via Launcher share the same volume control.
https://bugs.kde.org/show_bug.cgi?id=384217 Bug ID: 384217 Summary: Applications launched via Launcher share the same volume control. Product: plasmashell Version: 5.10.5 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: k...@davidedmundson.co.uk Reporter: mgui...@yahoo.com CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 107611 --> https://bugs.kde.org/attachment.cgi?id=107611=edit Firefox was launched via Kickoff When launching applications via Kickoff and/or Kicker, they usually show up as "Plasma" to pulseaudio instead of the actual application name. It's almost like Kickoff/Kicker is launching applications as child processes. I've been experiencing this on and off since I first upgraded to Opensuse Tumbleweed and Plasma5. Only recently tested the bug on a fresh install on a virtual machine using Tumbleweed. I am attaching the output of "pacmd list-sink-inputs" of Firefox launched via Kickoff vs launched via a shortcut widget placed on the Panel. I decided to submit the bug here instead of pulseaudio because it will occasionally work as intended. Reproducible: Almost always - It might work correctly for a short while after a reboot, but it invariably starts to act up. Steps to Reproduce: 1. Launch an application via Kickoff or Kicker 2. Play audio in the application 3. View list of sinks via pavucontrol application, Audio Volume widget, or the command "pacmd list-sink-inputs" Actual Results: Shared volume control between all applications started via Kickoff or Kicker with "Plasma" being the application name. Expected Results: Application independent volume control with the name of the application listed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 --- Comment #3 from Matthew Guiddy <mgui...@yahoo.com> --- Created attachment 103717 --> https://bugs.kde.org/attachment.cgi?id=103717=edit Visual example of shaded windows not snapping. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 --- Comment #2 from Matthew Guiddy <mgui...@yahoo.com> --- A shaded window will not snap to the geometry of another shaded window. A shaded window will snap to screen edges and the geometry of unshaded windows. An unshaded window will not snap to the geometry of a shaded window. I will upload a gif showing this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375740] New: Shaded windows no longer valid target for snapping.
https://bugs.kde.org/show_bug.cgi?id=375740 Bug ID: 375740 Summary: Shaded windows no longer valid target for snapping. Product: kwin Version: 5.8.5 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: mgui...@yahoo.com Target Milestone: --- Until fairly recently I have been able to snap windows (shaded or unshaded) to shaded windows. I first noticed that a shaded window would not allow other windows (shaded or unshaded) to snap to it a few days ago. Going by my update logs, I suspect this is a side effect of the fix for https://bugs.kde.org/show_bug.cgi?id=365892 Reproducible: Always Steps to Reproduce: 1. Shade a window. 2. Attempt to snap another window to the shaded window. Actual Results: The second window fails to snap to the shaded window. Expected Results: The second window should snap to the edges of the shaded window. -- You are receiving this mail because: You are watching all bug changes.
