https://bugs.kde.org/show_bug.cgi?id=488828
breakingsp...@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
Resolution|INTENTIONAL |---
--- Comment #7 from breakingsp...@gmail.com ---
Sorry for the delay, this was a fairly useless report without visuals, I
apologize.
Had to focus on several other things before having time to come back and record
the behavior.
Here are videos of my screens using Natural layout, my common interaction with
Overview on the right screen (open browser tabs by topic, divvy them to other
desktops), and the left screen with static unmoving windows. This in in Wayland
but the X11 behavior is identical.
Then the same routine in 6.1 with the new algorithm.
--
The leftmost portrait screen illustrates both the position and scale issue:
These windows are static and won't ever change, they're set in place at launch
by kwin window rules and pinned across virtual desktops (but not tiled using
custom or quick tiling). The old Natural layout barely moved them due to the
presence of no additional windows in the screen, but now they do move quite a
bit and it's jarring and distracting.
The windows now jump across others due to wanting to assume a more gridlike
position, when they should stay in place movement-wise and ease into the
transition if there are no other windows, same as before. The zoom/scale effect
is also stronger than before, which is fine on the rightmost screen but could
potentially be turned down overall.
*Could it be possible to generate a special conditional layout when all current
windows are already visible/tiled per screen, to prevent unnecessary movement
and zoom?*
--
The right screen mostly indicates the position issue due to my most common
window dimensions:
As I'm coming to learn, the number of windows, their dimensions, and positions
dynamically calculate a layout on each invocation, and while windows try to
hold positions, they can travel far and cross other windows if they need to
reach a proper-sized slot. Correct me if i'm understanding this wrong though.
Due to my amount of half-snapped windows, the layout ends up resembling the
former "Closest" grid most of the time, making the windows travel farther than
they would have on Natural in order to preserve their scale, and this makes
them across other windows. I never used Closest in practice, but this seems to
be what it resembles with my usage.
This is what I'm attempting to convey, the new layout tends to lean to more of
a rigid grid due to my most common window dimensions, when I prefer instead to
have them laid out in a more scattered/radial grid and prioritize keeping their
position over scaling.
Now knowing the new system also takes into effect window position, (and now
that I have kdesrc-build fully set up for testing) I want to try adjusting
values to see if I can affect the layout to more prioritize positions and see
if it improves the experience for me.
--
You are receiving this mail because:
You are watching all bug changes.
