https://bugs.kde.org/show_bug.cgi?id=513815
--- Comment #7 from Gagan <[email protected]> --- Correction and further investigation: Repeating Magic Lamp target behaviour with Dodge Windows **Correction to my earlier observations:** After further testing, I found that my initial hypothesis—that the animation destination is determined by panel visibility when a window is opened—was incorrect. The behaviour is more dynamic and appears to depend on changes in the panel's visibility. With the bottom panel configured to **Dodge Windows**, I can reproduce the following sequence: 1. **First window:** The first application window opened consistently minimizes towards its Task Manager icon. 2. **Panel becomes hidden:** When this window causes the panel to hide, subsequently opened windows minimize towards the current mouse-cursor position. 3. **Continuous hidden state:** Newly opened windows continue to have cursor-directed animations as long as the panel remains continuously hidden. 4. **Original window is not required:** The first window does not need to remain open or be responsible for hiding the panel. It can be closed, minimized or moved, provided other windows continue to keep the panel hidden. 5. **Break condition – panel becomes visible:** When the panel becomes visible, all currently open windows switch to icon-directed minimize animations, including windows that were previously targeting the cursor. 6. **Panel becomes hidden again:** If the panel is hidden again, newly opened windows once again minimize towards the cursor. Windows that were already open retain their icon-directed destinations. 7. **The cycle repeats:** If the panel becomes visible again, all currently open windows switch to icon-directed animations once more. **In summary, the observed cycle is:** - First window: icon-directed. - Panel hidden: subsequently opened windows become cursor-directed. - Panel becomes visible: all currently open windows become icon-directed. - Panel hidden again: newly opened windows become cursor-directed again. - The same sequence repeats. The important distinction is that the first window does not need to remain open. Other windows can take over the role of keeping the panel hidden. This suggests that Magic Lamp's animation destination may be influenced by panel visibility transitions and the current state of existing windows, rather than simply being determined when an individual window is opened. **Questions:** 1. Is this intended behaviour or an issue with how KWin/Magic Lamp handles panel visibility changes? 2. Why does the panel becoming visible change the animation destination of all currently open windows? 3. Would it be possible to provide an option that consistently directs Magic Lamp animations towards the current mouse cursor, independently of panel visibility? **System information:** - OS: Fedora Linux 44 - KDE Plasma / KWin: 6.7.5 - Display server: Wayland - Panel visibility: Dodge Windows - Effect: Magic Lamp(In reply to Gagan from comment #6) > ### Correction and further investigation: Repeating Magic Lamp target > behaviour with Dodge Windows > > **Correction to my earlier observations:** After further testing, I found > that my initial hypothesis—that the animation destination is determined by > panel visibility when a window is opened—was incorrect. The behaviour is > more dynamic and appears to depend on changes in the panel's visibility. > > With the bottom panel configured to **Dodge Windows**, I can reproduce the > following sequence: > > 1. **First window:** The first application window opened consistently > minimizes towards its Task Manager icon. > 2. **Panel becomes hidden:** When this window causes the panel to hide, > subsequently opened windows minimize towards the current mouse-cursor > position. > 3. **Continuous hidden state:** Newly opened windows continue to have > cursor-directed animations as long as the panel remains continuously hidden. > 4. **Original window is not required:** The first window does not need to > remain open or be responsible for hiding the panel. It can be closed, > minimized or moved, provided other windows continue to keep the panel hidden. > 5. **Break condition – panel becomes visible:** When the panel becomes > visible, all currently open windows switch to icon-directed minimize > animations, including windows that were previously targeting the cursor. > 6. **Panel becomes hidden again:** If the panel is hidden again, newly > opened windows once again minimize towards the cursor. Windows that were > already open retain their icon-directed destinations. > 7. **The cycle repeats:** If the panel becomes visible again, all currently > open windows switch to icon-directed animations once more. > > **In summary, the observed cycle is:** > > - First window: icon-directed. > - Panel hidden: subsequently opened windows become cursor-directed. > - Panel becomes visible: all currently open windows become icon-directed. > - Panel hidden again: newly opened windows become cursor-directed again. > - The same sequence repeats. > > The important distinction is that the first window does not need to remain > open. Other windows can take over the role of keeping the panel hidden. > > This suggests that Magic Lamp's animation destination may be influenced by > panel visibility transitions and the current state of existing windows, > rather than simply being determined when an individual window is opened. > > **Questions:** > > 1. Is this intended behaviour or an issue with how KWin/Magic Lamp handles > panel visibility changes? > 2. Why does the panel becoming visible change the animation destination of > all currently open windows? > 3. Would it be possible to provide an option that consistently directs Magic > Lamp animations towards the current mouse cursor, independently of panel > visibility? > > **System information:** > - OS: Fedora Linux 44 > - KDE Plasma / KWin: 6.7.5 > - Display server: Wayland > - Panel visibility: Dodge Windows > - Effect: Magic Lamp -- You are receiving this mail because: You are watching all bug changes.
