Im using the "Better Quick Tiles" script, which has the fixed setting for hotkeys "Meta + NumPad[1-9]" to move windows in a 3x2 grid After moving the window everything is OK, and then, when some notifications appear or a random window is closed, the shifted windows move again without pressing "Meta + NumPad[1-9] Not sure what is causing this unintended movement! STEPS TO REPRODUCE 1. Move for example two windows 2. Do something different 3. Windows move by themselve OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS System: Kernel: 5.10.42-1-MANJARO x86_64 bits: 64 compiler: gcc v: 11.1.0 Desktop: KDE Plasma 5.21.5 tk: Qt 5.15.2 wm: kwin_x11 vt: 1 dm: SDDM Distro: Manjaro Linux base: Arch Linux Machine: Type: Desktop Mobo: ASUSTeK model: Z170 PRO GAMING v: Rev X.0x serial: <filter> UEFI-[Legacy]: American Megatrends v: 3805 date: 05/16/2018 CPU: Info: Quad Core model: Intel Core i7-6700K bits: 64 type: MT MCP arch: Skylake-S rev: 3 cache: L2: 8 MiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 64026 Speed: 3900 MHz min/max: 800/4300 MHz Core speeds (MHz): 1: 3900 2: 3900 3: 3900 4: 3900 5: 3900 6: 3900 7: 3900 8: 3900 Graphics: Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: Gigabyte driver: nvidia v: 465.31 bus-ID: 01:00.0 chip-ID: 10de:1c03 class-ID: 0300 Display: x11 server: X.Org 1.20.11 compositor: kwin_x11 driver: loaded: nvidia resolution: 3440x1440~50Hz s-dpi: 109 OpenGL: renderer: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 v: 4.6.0 NVIDIA 465.31 direct render: Yes Audio: Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a170 class-ID: 0403 Device-2: NVIDIA GP106 High Definition Audio vendor: Gigabyte driver: snd_hda_intel v: kernel bus-ID: 01:00.1 chip-ID: 10de:10f1 class-ID: 0403 Sound Server-1: ALSA v: k5.10.42-1-MANJARO running: yes Sound Server-2: JACK v: 0.125.0 running: no Sound Server-3: PulseAudio v: 14.2 running: yes Sound Server-4: PipeWire v: 0.3.30 running: yes Network: Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: kernel port: f000 bus-ID: 00:1f.6 chip-ID: 8086:15b8 class-ID: 0200 IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter> Device-2: Intel Wireless 7265 driver: iwlwifi v: kernel port: e000 bus-ID: 03:00.0 chip-ID: 8086:095a class-ID: 0280 IF: wlp3s0 state: down mac: <filter> Bluetooth: Device-1: Intel Bluetooth wireless interface type: USB driver: btusb v: 0.8 bus-ID: 1-10:2 chip-ID: 8087:0a2a class-ID: e001 Report: rfkill ID: hci0 rfk-id: 1 state: up address: see --recommends Drives: Local Storage: total: 4.55 TiB used: 304.5 GiB (6.5%) ID-1: /dev/nvme0n1 vendor: Western Digital model: WDS100T3X0C-00SJG0 size: 931.51 GiB speed: 31.6 Gb/s lanes: 4 rotation: SSD serial: <filter> rev: 111110WD temp: 46.9 C scheme: MBR ID-2: /dev/sda vendor: Western Digital model: WD40EFRX-68WT0N0 size: 3.64 TiB speed: 6.0 Gb/s rotation: 5400 rpm serial: <filter> rev: 0A82 scheme: GPT Partition: ID-1: / size: 907.15 GiB used: 304.5 GiB (33.6%) fs: ext4 dev: /dev/nvme0n1p1 Swap: ID-1: swap-1 type: partition size: 8.8 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/nvme0n1p2
EDIT: I know, that there is not much information in this description but i will provide information as requested I am very new to manjaro and don't really know where to find a log or something to provide more content
Created attachment 139722 [details] Screen capture of the bug EDIT2: to make clear what i do, i added this screen-capture. What you see is: 1. im closing one of two dolphin instances 2. i re-arrange the left dolphin instance with Better Quick Tiles by pressing "Meta + Num + 1" 3. i open a new instance of dolphin again by pressing "Meta + E" 4. the instance in the background seems to resize to the freshly opened dolphin instance Other stuff is also happening linke only moving the windows etc. It seems to always be a reaction to some other stuff like - Closing another window - Opening another window - A notification pops up For me its strange, that shifting the windows is working absolutely well But then in situations where i do not press "Meta + NumPad [1-9]", these windows start to move and get resized For Information: Im using more than one virtual desktop
And this doesn't happen without the script? If the script triggers it, please report to the script maintainers until we can identify something more specific wrong with kwin.
(In reply to David Edmundson from comment #3) > And this doesn't happen without the script? > > If the script triggers it, please report to the script maintainers until we > can identify something more specific wrong with kwin. Hello, yes it is only happening exactly since i activated this script. 1. I sent a Link to the Author Torge Kummerow (Mail-Adress in the Author-Section of the Information-Window) 2. I reported this bug here, because it is written in the Author-Section "Please use https://bugs.kde.org for problems" I hope this was correct
Hi, I'm the developer. My script only has hooks for the shortcuts, so it should not be causing this. I also use it myself and do not experience this, but I do not use virtual desktops My 2 cents: Could be some custom windows rule. Check System Settings/Window Management/Window Rules Also there is one limitation that can also lead or magnify strange effects. The position set by the script is not saved as the last size/position of the window. Only if modified manually by the user, this gets saved (and restored after maximize for example) See https://bugs.kde.org/show_bug.cgi?id=428272 for details on this But I agree with my previous poster, first make sure you check if this really is gone if you disable the script
Hello and thank you very much for your reply! To get a better idea where some connections could be (causing this error) i played a bit with my settings - This error ONLY occurs if Better Quick Tiles is active --> Has to do with this script - I erased all of my virtual desktops --> Error still present - BUT: I deactivated the "slide behind" effect in "Effects >> Activation >> Slide behind" and this seems to solve the problem Could it be, that there is some connection to the "Slide behind" effect when a new window appears?
Created attachment 139748 [details] Screen capture of the bug for Notifications
OK sorry for the new reply again. It seems, that this unwanted behaviour is not solved by just deactivating "slide behind"-effect. I uploaded another screen-cast after i installed a screen key application to show you my strokes In the Screen capture of the bug for Notifications gif you see 1. super+3 --> Sets the window size to lower right 2. Vol+ --> My custom key vor "next song" media control --> This causes a popup to appear to show the next title 3. During the notification is shown i hit super+3 again --> Window size change during notification is still present 3. Wait for notification to disappear after timer --> Window size changes without any keystroke Here again you can see some connections to Window activities, causing window size and position changes for windows changed by "Better Quick Tiles" If i deactivate Better Quick Tiles --> No error present anymore I tried to see if the same error occurs if im doing the same thing but only using super+arrowRight --> This does NOT cause an error --> Only shifting windows with "Better Quick Tiles" shifts the window I also checked if the meta+num+1-9 shortcut is used by other functions --> I could not find these shortcuts to be used double --> And as you see in the gif --> The unintended Windows size/position-change is not related to any keystroke
Can you please test if you also get this behavior when you disable "Better quick tiles" but use the normal 2x2, built in, quick tile shortcuts? I still bet this is due to the position not being saved and something triggering a "restore last position" that will then not restore the last quick position but instead the last user manipulated position. Also, quite conveniently, KDE Settings now can show you all settings you changed from default (Highlight Changed Settings in the lower left). Make sure you checked this out to not miss some setting you might have forgotten about.
(In reply to cyslider from comment #9) > Can you please test if you also get this behavior when you disable "Better > quick tiles" but use the normal 2x2, built in, quick tile shortcuts? I tested it now several times If the Windows gets moved via normal built in function (Meta + ArrowKeys -or- Meta + Shift + ArrowKeys) the window never "changes size by itsself" (In reply to cyslider from comment #5) > Also there is one limitation that can also lead or magnify strange effects. The position set by the script is not > saved as the last size/position of the window. Only if modified manually by the user, this gets saved (and restored after maximize for example) See https://bugs.kde.org/show_bug.cgi?id=428272 for details on this OK sounds, that it can have to do with this - I can minimize and maximize the window to taskbar and back but the size and position stays always the same - In case of a window "changes size by itsself", it seems that especially only size is changed to an older stored one --> The position where i docked the window stays more or less the same (In reply to cyslider from comment #9) > I still bet this is due to the position not being saved and something > triggering a "restore last position" that will then not restore the last > quick position but instead the last user manipulated position. Yes i agree But i have no clue how to find out what "something" it is --> In the two screen captures you see two very differtent situation Situation1: Opening a second instance of dolphing --> First instance changes size Situation2: Causing a popup to appear --> the one and only Brave instance changes size (In reply to cyslider from comment #9) > Also, quite conveniently, KDE Settings now can show you all settings you > changed from default (Highlight Changed Settings in the lower left). Make > sure you checked this out to not miss some setting you might have forgotten > about. Thanks for this hint! But im not sure for what to search --> Ive changed many settings due to the fact that this is my personal computer which i want to customize
EDIT: I do NOT see the described behaviour from https://bugs.kde.org/show_bug.cgi?id=428272 If i 1. have one randomly placed window 2. rearrange it with Better Quick Tiles 3. double-klick on window-bar to maximise 4. double-klick again on maximised window bar The window goes back to exactly the size and position where Better Quick Tiles has shifted it to!
EDIT2: I have no window rules for e.g. Brave or Dolphin EDIT3: Right now i had the situation, that all 3 of the open Dolphin instances have been set to exactly the same size (but different positions) as soon as i opened up instance nr. 3 by pressing Meta+E
EDIT4: For testing i now did erase all of my window-rules and close all running applications --> Shifting e.g. Dolphin with Better Quick Tiles and then opening additional instances by pushing [Meta + E] or [RightClick > Start new Instance] still changes randomly size of windows
>I tested it now several times >If the Windows gets moved via normal built in function (Meta + ArrowKeys -or- >Meta + Shift + ArrowKeys) the window never "changes size by itsself" Ok, this really surprises me. Curious >> Also, quite conveniently, KDE Settings now can show you all settings you >> changed from default (Highlight Changed Settings in the lower left). Make >> sure you checked this out to not miss some setting you might have forgotten >> about. >Thanks for this hint! >But im not sure for what to search --> Ive changed many settings due to the >fact that this is my personal computer which i want to customize Just follow the dots (Pun intendend :) to see if there is anything you changed that might be related to window behavior. And temporarily undo the change to see if it helps. > I do NOT see the described behaviour from > https://bugs.kde.org/show_bug.cgi?id=428272 Hah, indeed, my own Script is not affected by it... But the original Quick tile (Meta + arrow) still has this issue on my Manjaro. Cool. Hmm, can you try to boot into a Manjaro live CD and try to reproduce this? Best in a VM. If you manage that, tell me how and I can see if I find a reason. I still don't see how my script could be possibly involved as again, it only reacts to shortcut presses and should be inactive in all other cases. But wouldn't be the first time I was surprised by how things work :-) One other thing I could imagine is that you have some other window manager script installed, or something is trying to arrange your windows in a certain way when opening. Maybe some effect? Odd odd odd
OK what i now did is - Start wm Console - Add some "print"-section to your script - Run this script to see when it gets activated Its as you said --> When i open additional instances etc. your scritp does not get active --> has anyone an idea how i can "debug" to see what re-sets my window to the last position? I also did stop and restart plasmadesktop process --> After activation windows also moved (as when im starting a new instance)
Sorry for the late reply! I now even installes VirtualBox, installed Manjaro KDE (same as i have) and did step by step configure it similar to my sysem - Position of taskbar - Theme - Installed Kvantum to manage tehemes - Step by step made the same settings etc. This behaviour does NOT show up in the VM, configured nearly the same as my system! Is there a chance, that this behaviour could be dependent to - Nvidia-Driver (i have on my real pc) - Screen resolution (i have ultra-wide on my real pc) These screen/driver things are the last things i can think of, making a difference to the VM
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!