search

esjeon / krohnkite

A dynamic tiling extension for KWin
MIT License
1.67k stars 69 forks source link

Can't maximize windows: the script pretends to keep tiling them #64

Open alxlg opened 4 years ago

alxlg commented 4 years ago

Symptom When I maximize a tiled window the screen gaps are applied to it too: immagine

If I make it float and then maximize it's OK: immagine

How to Reproduce

  1. Set screen gaps
  2. Maximize a tiled window
  3. See screen gaps are kept

Expected behavior There shouldn't be gaps like in the second image

Environment

esjeon commented 4 years ago

I guess you actually meant Monocle layout? The behavior is intentional. You can change this in the settings by checking "Fully maximize windows" option, though it also remove borders.

alxlg commented 4 years ago

guess you actually meant Monocle layout?

Ehm no, this happens with every layout.

You can change this in the settings by checking "Fully maximize windows" option, though it also remove borders.

I see and I have it enabled but I would need to switch back and forward to monocle layout, at that point I prefer to float the window and then maximize.

What I'm talking about is KWin/X11 "maximize" action. Here there is a gif where I show that I need to make a window "Float" before maximizing it, otherwise it has gaps: https://imgur.com/a/r5Y359f

This looks more like a bug to me: why maximized windows should be affected by a tiling script in the first place? I hope it's more clear now.

esjeon commented 4 years ago

This looks more like a bug to me: why maximized windows should be affected by a tiling script in the first place? I hope it's more clear now.

My mind is totally blown up right now, because Krohnkite currently does not support native maximization at all. Maximized window should simply return to where it was. The only possibility I can think of is that maybe another script is still in effect and handling the maximization event. If this is the case, restarting the session would stop this happening.

alxlg commented 4 years ago

The only possibility I can think of is that maybe another script is still in effect and handling the maximization event.

I disabled all the other script, killed Latte Dock, removed any Plasma widget and restarted Kwin: I can confirm it's Krohnkite applying screen gaps to maximized windows. Those are for sure Krohnkite's gaps, I can increase/decrease them from its settings. The thing is: the script shouldn't affect maximized windows because since they are maximized they can't be tiled.

Edit: maybe in your setup this isn't obvious because you don't use maximization at all, but maximized windows are still very useful with your script. As mentioned I also use a script that moves maximized windows to a new desktop that would be a perfect match with your script if it wasn't for those gaps. Also when I maximize a window the borders are removed by Latte Dock and window controls are drawn by a plasmoid in it, as you can see in the screenshots.

esjeon commented 4 years ago

As mentioned I also use a script that moves maximized windows to a new desktop

Ah, now I get it. So, the window was NOT being maximized, but only moved to another desktop and was being tiled normally, thus the gap.

maximized windows are still very useful with your script

I agree. It's just that Krohnkite was initially designed to mimic dwm, which has no maximization. I'll definitely add support for native maximization.

alxlg commented 4 years ago

@esjeon

So, the window was NOT being maximized, but only moved to another desktop

No, the window is being maximized (and I can de-maximize it) but if I have that script enable it's also moved to a new desktop, that's all... with that script enabled or disabled there is no difference, I mentioned it because I prefer to continue to use it and Kwin's native maximization instead of switching to your concept (monocle layout). I suggest you to try my config, it's very convenient! ;)

alxlg commented 4 years ago

As a workaround I just noticed that one can drag a tiled window to the top border to maximize it (if Kwin is set to do so): this will un-tile the window and maximize it at the same time! Sadly when demaximizing the window needs to be tiled again with the script's shortcut.

Edit: this works only when there are 2+ windows tiled.

alxlg commented 4 years ago

@esjeon I think I tried 4ac5360 (I used make run command on master, but not sure how could that work since I wasn't able to build it with make install), since 0.7 the behavior changed but there are still at least 3 problems:

  1. When a window is maximized while Krohnkite is active Plasma and Latte panels that autohide don't show up anymore on mouse hovering. Demaximizing the window restore normal behavior. If the window is launched as already maximized no problem. If Krohnkite is not running there is no problem.

  2. When window A is maximized and window B is launched, window A is affected by tiling while its state is still set to maximized

  3. When window A is NOT maximized and window B is launched as already maximized, window B is affected by tiling while its state is still set to maximized

Also, is there a way to load the configuration of an installed Krohnkite while running it from somewhere else with make run? I would like to test master with different settings.

esjeon commented 4 years ago

You may want to try a newer version, something after dab4b89cdcf2e17a80d7e08c48f4cc444640623e.

  1. Krohnkite explicitly enables keepAbove for maximized windows, and latte dock is basically hidden behind windows. I thought it's better to prevent other windows from sitting above maximized ones. This was a totally arbitrary decision. Maybe this can be made optional instead of choosing just one behavior.

  2. I think this should be fixed by dab4b89cdcf2e17a80d7e08c48f4cc444640623e.

  3. This is actually an issue with KWin API. The API doesn't directly expose the maximization state, and scripts can only detect window maximization through event signals. However, one can still guess the maximization state from the window geometry. IIRC, kwin-tiling is doing this.

Also, is there a way to load the configuration of an installed Krohnkite while running it from somewhere else with make run?

Sadly, no. But it should be possible to implement external config file.

alxlg commented 4 years ago

Maybe the ideal solution to 1 is moving the window to a new virtual desktop when maximized (and back when demaximized) and if there is already a maximized window on the current desktop and a new window is launched, move the latter to the next desktop

esjeon commented 4 years ago

While I like the idea itself, I think it's too specific. Switching and creating virtual desktops from WM can interfere with the workflow and the window management rules that people have in their mind.

I think the solution for 1 is to set "keep below" to tiled windows, and unset both above and below for those . Krohnkite used to do that, but I changed it without concrete reasons. This might cause issues w/ some desktop utils, but, if hinted properly, they are placed in different layers, so won't be much of a problem.

alxlg commented 4 years ago

@esjeon problem is, if I have 2+ maximized windows on the same desktop I can't switch between them, there is always one of them above all the others. I don't think with "keep below" it would be different. Maybe by default Krohnkite could just ignore maximized windows (if this can't be properly implemented with KWin API we could ask to its developers to add a way to check if a window is maximized or not, it seems reasonable to me). Eventually there could be an option to enable the behavior I described in my previous comment. After all I think in Plasma "virtual desktops" are not desktops for real, Activities are, instead VDs are more "layers" of windows so for me it makes sense for a tiling script to add more layers to manage maximized windows.

esjeon commented 4 years ago

problem is, if I have 2+ maximized windows on the same desktop I can't switch between them, there is always one of them above all the others

It should be possible to cycle through only maximized windows.

Maybe by default Krohnkite could just ignore maximized windows (if this can't be properly implemented with KWin API we could ask to its developers to add a way to check if a window is maximized or not, it seems reasonable to me)

Yeah, I thought the same, but ignoring maximization gave me little itches. I'm just exploring the possibilities.

Eventually there could be an option to enable the behavior I described in my previous comment.

Perhaps. But I wonder if it's really necessary to integrate it into Krohnkite atm.

Also, there has been another suggestion regarding maximization (#79). The idea is that maximization simply toggles monocle layout. This sounds like a less painful path in the current management model.

Including the new suggestion, I think there are three options:

  1. Ignore maximization - which had worked just okay
  2. Let KWin control the maximized windows - need to implement focus cycling
  3. Toggle monocle - a new option

Maybe I can implement all of these and let users choose. I'm pretty sure the architecture can still survive this kind of abomination. lol

alxlg commented 4 years ago

@esjeon in the meanwhile can you please remove the part of the code that set the keepAbove property to maximized windows? I tried to look at the code and remove it with no success. If you don't want to change master branch please tell me how to make this change to the script (a diff patch is fine too). Thank you!

esjeon commented 4 years ago

What you're looking for is this line:

https://github.com/esjeon/krohnkite/blob/c878120074fedbbde966dd6bd5b8cf722e0d54f9/src/engine/window.ts#L161

The third argument is "keepAbove", and changing it to true will keep maximized windows above.

alxlg commented 4 years ago

@esjeon thank you, I edited the line (I actually wanted false), I tested it with make run and it worked as expected. Then I wanted to install it to take advantage of config options, so I run make install, the script correctly appeared in KWin Scripts KCM but enabling it does nothing. Did I do something wrong?

esjeon commented 4 years ago

the script correctly appeared in KWin Scripts KCM but enabling it does nothing.

Maybe you forgot to make stop before enabling the script? This might cause a race condition.

Btw, I just realized this line here: https://github.com/esjeon/krohnkite/blob/c878120074fedbbde966dd6bd5b8cf722e0d54f9/src/driver/kwin/kwinwindow.ts#L100

This block is redundant, and you might want to remove it too.

alxlg commented 4 years ago

@esjeon I run make stop and repeated multiple times, at the end I got it working by:

  1. cloning the repo
  2. make the two changes you said
  3. run make uninstall
  4. restart Kwin
  5. run make install
  6. enable from Scrips KCM

Without make run/stop. Now everything seems to work as expected, thank you very much!

CarlosEkisde commented 4 years ago

the script correctly appeared in KWin Scripts KCM but enabling it does nothing.

Maybe you forgot to make stop before enabling the script? This might cause a race condition.

Btw, I just realized this line here:

https://github.com/esjeon/krohnkite/blob/c878120074fedbbde966dd6bd5b8cf722e0d54f9/src/driver/kwin/kwinwindow.ts#L100

This block is redundant, and you might want to remove it too.

Thank you, I was also looking for this. The default behavior kind of annoys me :P because I couldn't reach the panel.

torma616 commented 3 years ago

Even with the changes outlined above, I'm still getting gaps on maximized windows. Any advice?