Hi,

Present Window effect constantly changes window order in the preview. It confuses the hell out of me. I have no idea in which corner a window is going to land next time I trigger present window effect. How can I disable this changing order? I would like it be say alphabetical and maybe group window from the same app.

Thanks.

i'd say because it traverses the stack and you changed the stack order (raise/lower windows) inbetween?
the natural grid aligns windows close their actual position.

luebking wrote:i'd say because it traverses the stack and you changed the stack order (raise/lower windows) inbetween?
the natural grid aligns windows close their actual position.

Yes, I am constantly moving among windows. I don't use natural grid because it also makes no sense to me. It looks like some things are thrown on the screen without any order.

I am trying out flexible grid to see if that doesn't change order.

I have been unable to find any documentation about these three orders - natural, regular, and flexible. Is there any?

Actually™ I meanwhile tried and even in the regular grid this does not happen because of stack changes (only)
Instead the calculateWindowTransformationsClosest function reproducibly moves windows to the nearest slot in the grid.

=> I assume all your windows take the same (maximized...) geometry?

luebking wrote:Actually™ I meanwhile tried and even in the regular grid this does not happen because of stack changes (only)
Instead the calculateWindowTransformationsClosest function reproducibly moves windows to the nearest slot in the grid.

=> I assume all your windows take the same (maximized...) geometry?

Yes, all of my windows are always maximized as long as it's not a dialog.

Then the order is determined by the stacking order.

2nd sort by class?
-> kwrite, kwrite and ... kwrite ...

2nd sort by title?
Dynamic, we'd actually may have to update geometries *while* in PW mode to keep the sort correct. Eewww..

Windows do not necessarily have an icon rect (taskbar position), nor is that any guaranteed to be static.

Positioning maximized windows according to their restore size might work (but not if you start maximized and run it all the time)

=> The only thing that (we would have to record and then would) maybe work would be the window uptime, ie. how long is this window been mapped.
Still, closing/adding a window will naturally shuffle others around and "minimize" to systray (no: it's *not* minimization, the window is destroyed) would not restore it at its former position either....

Feel free to suggest that as a wish against kwin (effects-windowmanagement component) and wait for Martins opinion.
If me was the kwin maintainer, windows could not be maximized itfp :-P

I can't claim to understand everything you have said but before I file a bug report it would be great to know if there are flaws in my thinking which is as follows.

I rely heavily on muscle memory. If I see Chrome in the left corner I would expect it to be in left corner if nothing has changed. A change would mean I have not added another app to the stack. I basically need a predictable way to know where my windows will land so that I can trigger them with least amount of thinking and looking around. Taskbar widget for example shows all apps alphabetically. That makes sense. I would go one step ahead and say group together all instances of Chrome or my IDE so that I see them clearly in one side of the screen.

Alphabetically, but by *what*?

The troubles you run into are that many windows can have the same class (chromium) and the window title is anything but static (notably changes on browsers with the presently opened tab) - there goes your "muscle memory" (And do you never open/close any windows?)

One can apply many sorting criterias here, but whatever you do - it's not gonna end up static.
The only actually static and pretty much unique attribute is the windows "age".

Another difference is that PW is not a linear layout, ie. if one window is removed, the others don't just slide to the left, but the entire thing is shuffled.

That's (likely) why the primary slot assignment decision relies on the geometry, but that that doesn't work either if you apply the same geometry to all windows...