[kwin] [Bug 483605] Pop-up Windows Resizing Themselves Automatically
https://bugs.kde.org/show_bug.cgi?id=483605 --- Comment #2 from Ryan Ronnander --- (In reply to David Edmundson from comment #1) > Can you share what scale factor you use? Sure thing, I am using 250% scale factor and "legacy applications apply scaling themselves". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483605] New: Pop-up Windows Resizing Themselves Automatically
https://bugs.kde.org/show_bug.cgi?id=483605 Bug ID: 483605 Summary: Pop-up Windows Resizing Themselves Automatically Classification: Plasma Product: kwin Version: 6.0.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: rronnan...@gmail.com Target Milestone: --- Created attachment 167205 --> https://bugs.kde.org/attachment.cgi?id=167205=edit Pop-up windows resizing themselves video SUMMARY After upgrading to 6.0.1 some application windows or pop-up windows will start dynamically resizing themselves. I've noticed this happening on 3rd party apps such as Zoom and Reaper (so far). STEPS TO REPRODUCE 1. Open application, trigger a dialog pop-up window. OBSERVED RESULT Window constantly resizes and expands. EXPECTED RESULT Window should stay statically sized. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 453534] kcalc process always takes nearly 100% of a CPU thread when it's running
https://bugs.kde.org/show_bug.cgi?id=453534 Ryan Ronnander changed: What|Removed |Added CC||rronnan...@gmail.com --- Comment #8 from Ryan Ronnander --- (In reply to roger.koot from comment #5) > If you resize the kcalc window, the cpu usage drops to expected values. Wow, this actually works, but upon closing and reopening kcalc, the behavior resumes until resized. I cannot reproduce this on other KDE systems. The menu rapidly flickers when this bug occurs, as if some redraw event is constantly being executed until the window is resized. I believe I've tried this on both X11 and Wayland, both hit 100% CPU usage. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 444136] Konsole window upon reload has vertical height too small on my 3 monitor setup with panel in middle screen
https://bugs.kde.org/show_bug.cgi?id=444136 Ryan Ronnander changed: What|Removed |Added CC||rronnan...@gmail.com --- Comment #1 from Ryan Ronnander --- I've noticed similar behavior when moving to a triple monitor configuration with one center horizontal monitor flanked by two vertical monitors a few weeks ago. I believe it may also be related to using "Ctrl + D" to exit Konsole. When you close Konsole in this manner the "remember window position" functionality does not appear to save on exit. I was able to reproduce this just now. Closing Konsole through kwin's titlebar saves Konsole's position and size upon exit allowing Konsole to open as expected during the next launch. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 445595] [multiscreen] - cannot drag windows above primary screen's topmost panel in vertical stacked screens layout
https://bugs.kde.org/show_bug.cgi?id=445595 --- Comment #5 from Ryan Ronnander --- (In reply to Michail Vourlakos from comment #4) > > > 4. If you change Visibility mode for your top latte panel to Windows Go > > > Below isnt that enough to let you move your windows upwards? > > > > Yes, toggling this, waiting for the topmost panel to disappear does let me > > drag windows freely to my topmost monitor screen. > > > > After this procedure, toggling the back to "always visible" restores > > expected functionality as well. I can snap windows up against the top most > > panel, maximize them in against the panel in the expected correct screen, > > and also drag them into my topmost monitor screen space. > > > I looked the Plasma panels code: > https://github.com/KDE/plasma-workspace/blob/master/shell/panelview. > cpp#L1088 , for your scenario plasma panels disable AlwaysVisible visibility > mode and force WindowsGoBelow. So as long as you enable WindowsGoBelow for > your latte panel you will get exact the same behavior. > > This is KWin bug/responsibility, I could also blacklist the case as plasma > is already doing. By reading the plasma devs code it is clear that using > AlwaysVisible visibility in your scenario can break multiple things and this > is why they have blacklisted it. I've switched from lattedoc back to regular plasma panels the past couple of days. I've made sure to use a top panel on my primary lower screen for a global application menu, similar to my previous lattedoc layout. However, I cannot trigger the odd behavior by dragging windows to the top secondary screen. Everything has been functioning as expected with regular panels. My top panel is not set to autohide or anything either. I'm personally going back to plasma panels and removing a "top panel" entirely for daily use here, so I won't be of much more use on this bug report. Should further testing be needed, it should be easy to fake my vertical monitor layout in a true side-by-side monitor desk configuration. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 445595] [multiscreen] - cannot drag windows above primary screen's topmost panel in vertical stacked screens layout
https://bugs.kde.org/show_bug.cgi?id=445595 --- Comment #3 from Ryan Ronnander --- (In reply to Michail Vourlakos from comment #1) > 1. Isnt that the default KWin snapping behavior? Regardless of defaults, this "works" for a while, then doesn't work. More details on this under my #4 reply below. > 2. By dont letting you move them dont you mean that they become maximized > when touching the latte top panel? If I continue to drag the window above the lower primary monitor it will become maximized in the top monitor (more unexpected behavior). Once it is maximized in the top monitor, if I un-maximize the window and then attempt to position the window in the top monitor screen space, it will snap back to the lower primary monitor. > 3. If you use a plasma top panel with visibility "Always Visible" dont you > get the exact same result? I can test this behavior later today, but this is not my normal non-lattedock plasma setup. > 4. If you change Visibility mode for your top latte panel to Windows Go > Below isnt that enough to let you move your windows upwards? Yes, toggling this, waiting for the topmost panel to disappear does let me drag windows freely to my topmost monitor screen. After this procedure, toggling the back to "always visible" restores expected functionality as well. I can snap windows up against the top most panel, maximize them in against the panel in the expected correct screen, and also drag them into my topmost monitor screen space. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 445595] New: Cannot drag windows above primary screen's topmost panel with dual monitor (vertical stacked layout) configuration
https://bugs.kde.org/show_bug.cgi?id=445595 Bug ID: 445595 Summary: Cannot drag windows above primary screen's topmost panel with dual monitor (vertical stacked layout) configuration Product: lattedock Version: 0.10.3 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: rronnan...@gmail.com Target Milestone: --- SUMMARY After a certain amount of time, applications (kwin interaction?) do not to allow me to drag them above the topmost panel when simulating a MacOS or older Gnome setup. Applications without native title bar and borders (Google Chrome for example) do allow themselves to be dragged successfully. In my dual configuration I have my primary screen below my secondary screen in a vertical stacked layout. This puts my secondary monitor above the topmost panel. What's very odd is this is not an issue until a few hours pass by. All of the sudden I am unable to drag windows to my secondary monitor. If I use the meta key I can drag them, but the second I adjust them otherwise they "snap" to my primary screen. If I log out and log back in, the cycle repeats (eventually). Locking the screen is not a trigger to cause the bug. STEPS TO REPRODUCE 1. Configure dual monitors in a vertical "stacked" configuration. 2. Use lattedoc with a top panel. 3. Use desktop normally for an undetermined amount of time (few hours). OBSERVED RESULT Cannot drag windows to secondary screen above topmost panel. EXPECTED RESULT Windows should be able to be freely positioned on any screen regardless of the layout of lattedoc or multi-monitor configuration. SOFTWARE/OS VERSIONS OpenSUSE Tumbleweed KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 378758] New: Add keyboard shortcuts for switching remote sessions
https://bugs.kde.org/show_bug.cgi?id=378758 Bug ID: 378758 Summary: Add keyboard shortcuts for switching remote sessions Product: krdc Version: unspecified Platform: Neon Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: uwol...@kde.org Reporter: rronnan...@gmail.com Target Milestone: --- There are no configurable keyboard shortcuts for switching desktops such as Right_Control + Arrow Key. Don't get me wrong, I love the GUI overlay, but currently it's the only way to switch the current session. -- You are receiving this mail because: You are watching all bug changes.
[keditbookmarks] [Bug 353601] Bookmark editor does not open
https://bugs.kde.org/show_bug.cgi?id=353601 Ryan Ronnander <rronnan...@gmail.com> changed: What|Removed |Added CC||rronnan...@gmail.com --- Comment #2 from Ryan Ronnander <rronnan...@gmail.com> --- (In reply to William L. Thomson Jr. from comment #1) > Have you checked to make sure keditbookmarks is installed? If it is not, > clicking Edit Bookmarks will have no effect. Thanks! This fixed the issue for me as I had resorted to editing config files by hand. I am currently running Ubuntu 16.04 which has been converted to KDE Neon. I'll do some more testing on my laptop with a fresh KDE Neon install. -- You are receiving this mail because: You are watching all bug changes.
