[konsole] [Bug 482628] Allow disabling toolBar accelerator
https://bugs.kde.org/show_bug.cgi?id=482628 dirkjan changed: What|Removed |Added CC||k...@flowee.org --- Comment #14 from dirkjan --- Can the developers please just make the session toolbar hidden by default for now? This issue took me WAAAY to long to figure out. I love bash's "ALT-P" command (try it). Which pastes here, and that isn't instantly recognizable as being a paste so I didn't understand why this one computer where this toolbar was showing was misbehaving... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 471893] Resizing tiled windows (using Super+Arrow) on one virtual desktops affects all other tiled windows across all virtual desktops
https://bugs.kde.org/show_bug.cgi?id=471893 dirkjan changed: What|Removed |Added CC||k...@flowee.org --- Comment #7 from dirkjan --- would it not be much better for the ‘left’/‘right’ quick-tile system to be rigurous and predictable while the tiles-editor is the way for people to do more complex stuff? I’m very much not happy that an accidental change in window size actually changes something other than the window. I mean, I ended up opening up two konsole’s and showing the number of columns / rows, just to allow me to get back to the 50/50 setup and correct the accidental resize. (i.e. it’s an expensive thing to fix!) If kwin must, let the resize of two windows ‘tiled’ end up resizing those windows with zero change of the quick-tiling data underneath. Which means that if I want to reset it, I just hit the shortcut again. And maybe let anything more complex be done with the tiling system which is opt-in. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466031] Per-virtual-desktop tiling layouts
https://bugs.kde.org/show_bug.cgi?id=466031 dirkjan changed: What|Removed |Added CC||k...@flowee.org --- Comment #11 from dirkjan --- Oded Arbel: closing the quicktiling UX issue as a duplicate is a bit strange as they are two different user-discoverable features that need to be looked at from a user perspective as two different things. More specifically, a user using quick-tiling may never find out about the tiling feature at all. So any solutions in the tiling feature is not going to be relevant. Second: quick tiling is on purpose only 2 or 4 areas of the screen. It is from a UX perspective a very different feature. And as such merging the bugreport is weird. As I wrote on the now closed report: would it not be much better for the ‘left’/‘right’ quick-tile system to be rigurous and predictable while the tiles-editor is the way for people to do more complex stuff? I’m very much not happy that an accidental change in window size actually changes something other than the window. I mean, I ended up opening up two konsole’s and showing the number of columns / rows, just to allow me to get back to the 50/50 setup and correct the accidental resize. (i.e. it’s an expensive thing to fix!) If kwin must, let the resize of two windows ‘tiled’ end up resizing those windows with zero change of the quick-tiling data underneath. Which means that if I want to reset it, I just hit the shortcut again. And maybe let anything more complex be done with the tiling system which is opt-in. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 494276] New: After wake-up the lock screen moves typing from one screen to the next in the mid of my password.
https://bugs.kde.org/show_bug.cgi?id=494276 Bug ID: 494276 Summary: After wake-up the lock screen moves typing from one screen to the next in the mid of my password. Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: k...@flowee.org Target Milestone: --- SUMMARY After wake-up the lock screen moves typing from one screen to the next in the mid of my password. STEPS TO REPRODUCE 1. I wake up my laptop. The laptop screen comes on in half a second. The HDMI connected monitor takes 5 second. 2. I start typing my password on the laptop screen. Some 'bullets' appear in the password field 3. As the monitor comes on, typing continues on that screen. I press enter and login fails. OBSERVED RESULT Half my password on one input field, half on the other. An obvious failure of password check. EXPECTED RESULT My typed data synchronized across both screens and pressing enter thus taking the entire typed password. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.3 ADDITIONAL INFORMATION Wayland. My laptop screen is 'primary'. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 494276] After wake-up the lock screen moves typing from one screen to the next in the mid of my password.
https://bugs.kde.org/show_bug.cgi?id=494276 dirkjan changed: What|Removed |Added Keywords||multiscreen -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 493532] New: hover on decoration doesn't activate window (focus follows mouse)
https://bugs.kde.org/show_bug.cgi?id=493532 Bug ID: 493532 Summary: hover on decoration doesn't activate window (focus follows mouse) Classification: Plasma Product: kwin Version: 6.1.5 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@flowee.org Target Milestone: --- SUMMARY Using focus follows mouse, you see focus move to a target window when you hover over that window with the cursor for a specified delay. I noticed that this only applies to the actual content window. It does not happen if you hover over that target windows decorations. STEPS TO REPRODUCE 1. make sure focus follows mouse is enabled (kcm window behavior) 2. have two windows. Ensure the cursor is inside window 1. Notice how window 1 has focus. 3. Move the cursor to the DECORATIONS of window 2. Say, over the title of the window. You may need to position the windows smartly or increase the delay (same kcm) to ensure you don't get activation on the actual window. OBSERVED RESULT Nothing happens. Window 1 is keeping focus. EXPECTED RESULT Focus should move to window 2 because the decorations you are hovering over should be the same as the actual window. SOFTWARE/OS VERSIONS Linux/KDE Plasma: yes KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6 Qt Version: 6.7.2 ADDITIONAL INFORMATION Wayland. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 497459] screen config keeps on being creatively changed
https://bugs.kde.org/show_bug.cgi?id=497459 --- Comment #3 from dirkjan --- This is wayland only. I don't run X. The screens are connected with displayport. Both sides of the cable are displayport. Mini on graphics card, full size on monitor. I also noticed that there actually is a 1 digit difference between the two screens (its a LONG string, I missed it the first times). All the details are in the files I attached... -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 497459] screen config keeps on being creatively changed
https://bugs.kde.org/show_bug.cgi?id=497459 --- Comment #5 from dirkjan --- Created attachment 176743 --> https://bugs.kde.org/attachment.cgi?id=176743&action=edit more local config Added the info. Request for drm_info is harder, I don't know where that comes from. It is not a command I have or pacman (archlinux) knows about. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 497459] New: screen config keeps on being creatively changed.
https://bugs.kde.org/show_bug.cgi?id=497459 Bug ID: 497459 Summary: screen config keeps on being creatively changed. Classification: Plasma Product: KScreen Version: 6.2.3 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: k...@flowee.org Target Milestone: --- SUMMARY on my desktop I have two identical screens and they always show properly when booting, but after waking up from auto-off-timeout, they quite often get set to weird settings. STEPS TO REPRODUCE 1. have my hardware.. 2. don't touch computer long enough to make the screens go to sleep (the computer itself doesn't sleep) 3. touch the mouse to wake up. OBSERVED RESULT The configuration I boot with is applied. EXPECTED RESULT It looks like a weird combination of all the properties at one time or other I changed get applied. Like, one screen gets 110% but the other gets 125%. I've used the 125 one just once to test if that was good and I stuck to 110 for ages now. Screen rotation gets applied randomly. Which is fun since one is 90⁰ rotated, the two screens either get 0 or 90 applied. Sometimes both 90, sometimes both 0. Sometimes correct and sometimes the exact reverse of what it should be. The 'primary' almost always moves to the wrong monitor. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION the screens are identical, when I press "identify" I get a really long Id on both, which is the same. "BenQ GL2706PQT5H05861SL0" I don't know how to get more details about the screens... -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 497459] screen config keeps on being creatively changed.
https://bugs.kde.org/show_bug.cgi?id=497459 --- Comment #1 from dirkjan --- Created attachment 176612 --> https://bugs.kde.org/attachment.cgi?id=176612&action=edit the config dir. Adding my .local/share/kscreen dir. -- You are receiving this mail because: You are watching all bug changes.
