Maximizing window on secondary monitor jumps to main monitor and messes up tiling there.

[StFS]

Just some comments about my experience with multimonitor setup.

I have a huge (32" - 2560x1440) main screen and a very small secondary screen (19" - 1280x1024).

Tiling is only active on my main screen and not on the secondary screen. This is actually fine by me but I'm guessing some people would like to have tiling on both screens. I would like to have a config option that would enable me to choose which monitor tiling is active on and which not. I would even prefer to be able to choose which virtual desktop tiling is enabled on so that I can have one virtual desktop with "normal" floating windows and the rest using tiling (and even some virtual desktops where one monitor is floating but the other one tiling etc.).

The main problem that I'm experiencing though is when I have a window on my secondary monitor and I try to maximize it, it jumps over to the main screen and gets maximized there. Furthermore it messes up the whole tiling of the main monitor.

[StFS]

Ok, a bit more info on this.

It seems that this is only a problem if the window was originally created on the main monitor. If I click on a window on the secondary monitor, press Alt+F2 (which brings the launcher bar up on my secondary monitor) and type in a name of a program there, the program window starts up on the secondary monitor and there I can maximize it. If I then move it to the primary monitor and maximize it, it gets maximized on the primary monitor but does not participate in tiling (it just gets maximized over the other windows that are tiled).

[faho]

Thanks for your information.

This all ties into #5 - I don't have a multimonitor setup, so all that stuff is basically untested.

I would even prefer to be able to choose which virtual desktop tiling is enabled on so that I can have one virtual desktop with "normal" floating windows and the rest using tiling

This feature actually exists it's just undiscoverable (and I haven't found a good solution for that). There's a textfield in the config dialog that by default is filled with something like

3:BladeLayout,1:HalfLayout,-8:

That's a configuration string that sets default layouts and tiling state for virtual desktops (in the format desktopnr:layout,desktopnr:layout - a negative desktop number disables tiling by default).

The reason for this is basically that I couldn't find a good way to express that flexibility in a proper UI.

Now, extending this to support monitors should be fairly easy.

The main problem that I'm experiencing though is when I have a window on my secondary monitor and I try to maximize it, it jumps over to the main screen and gets maximized there.

I'll try to look into that, I should have access to a secondary monitor on the weekend.

In case you or someone else decides to take a stab at it: I suspect the issue starts with tiling not being active on the secondary monitor, so maybe movements across monitors aren't detected.

[faho]

Okay, I've tested this now and I've found what causes it:

We never actually change the screen variable in the tile, so it requests the geometry of the screen it was created on, and gets it. I need to check if just checking if the screen changed in movement handling is enough, since it doesn't seem like there is a proper "screenChanged" signal (or more precisely, there is a signal by that name, but the documentation seems to suggest it's for something else). If there really isn't one, that would substantially complicate making certain screens floating and others tiling.

As to why it then doesn't participate in tiling: That's because the current logic is that maximized clients don't. The idea is that maximization (which is a bit hackish, anyway, as we don't get the initial maximization state) is a way to opt out of tiling for a short while.

[faho]

So, that wasn't quite correct - we actually already checked if it switches monitors, but through detecting it on move (which may or may not be worse than just waiting for the screenChanged signal).

What was missing was setting a variable, which meant that we always looked in the wrong layout, which meant we never did anything to that tile. See d65293dc6bd051257ecb593b9c566ac4552fe46f. That's in the plasma5 branch, but I'll try to backport it so you can test it.

[faho]

I have now moved this to the multimonitor branch. See 694f034f73d3b0dc7b4809fb09a767b3268739b7. If you could test it, it'd be great, but I don't want to push this on people before there's at least a way to disable tiling on a screen, since there are still some issues related to multimonitor left.

[faho]

I'm guessing this is fixed in a88c2ffc5da394ac0fb0e18fa72ff65bc3139bf1.

[piotr-dobrogost]

I'm observing window jumping to another screen when being maximized. Could we have this bug reopened and could somebody please confirm that issue with maximization is still present? Wondering if https://github.com/kwin-scripts/kwin-tiling/issues/130 could help here anyhow?