Awesome: Handle maximize_h and maximize_v in manage

[Elv13]

I mentioned the possibility it might happen in the maximize PR, well, it happened to someone.

Here is a snippet from Awesome 3.5.9 rc.lua (also true in 4.0 and git-master, but not as obvious)

    awful.key({ modkey,           }, "m",
        function (c)
            c.maximized_horizontal = not c.maximized_horizontal
            c.maximized_vertical   = not c.maximized_vertical
    end)

That thing only works if both have the same maximization state. Otherwise you "dance" between max_h and max_v without being able to unmaximize the client. In git-master, it is a little better, as you can maximize it properly, but not unmaximize. But it can also be worst and you can end up dancing between (max_h+max_x) and max_hv.

I conclude it's stupid to preserve partial maximization if the default config offers no way of unmaximizing it (with the keyboard, I know you could using the titlebar, but not anymore). So I propose to add some code in awful.rules to auto-remove it. Any opinons?

[actionless]

that's indeed very annoying when happens to me

[psychon]

...why not just change the default config to only use c.maximize (I guess this already happened) and tell people not to use the "partial maximization" if they run problems with it?
Alternatively: I do not really see the point in partial maximisation. How about dropping that from the C code (yay, more deprecations!).

[actionless]

my bad, i've just realized what in my config i changed it in hotkeys, but not in titlebar

[sudo-nice]

I do not really see the point in partial maximisation. How about dropping that from the C code

Sometimes it's handy to maximize a window in one direction only, to keep other client(s) visible. If it's possible, I would like to preserve it (if this can't be imitated with new placement or such features).

[Elv13]

[15:28] <blueyed> FWIW: when you maximized kmymoney before, the max=false,
 max_h=false, max_v=false will make it take the whole screen (covering the task 
list) when starting it again in a floating layout.
[15:29] <Elv13_> The default rc.lua has a placement=no_overlap+no_offscreen. 
If the client size is maximized, then no_offscreen moves it back to 0x0
[15:30] <Elv13_> (well, 0x0+wibar height)
[15:30] <Elv13_> This is because KDE apps based on KXmlGuiWindow save their 
position and state in ~/.local
[15:31] <Elv13_> Awesome honor the size, but not the position. It should also not
 honor maximization status
[15:32] <Elv13_> as the example from 3.5.9 pointed, this behavior was already 
buggy. The recent changes made it worst
[15:33] <Elv13_> psychon is right, the "best" solution is to drop max_v and max_h,
 but some will disagree, so for now the workaround is better

[blueyed]

As for KMyMoney, it ended up with maximized_vertical and maximized_horizontal in the first config's default callback (but not maximized).
It seems to depend on the state when closing it, e.g. when it is tiled alone and covers the full screen. Using a floating layout changed/influenced this behavior. I've stopped debugging this for now, but setting max/max_h/max_v to false in the manage handler made it better.

[Perlovka]

I've fixed this as follows, just my 2¢ ;)

awful.key({ modkey,           }, "m",
        function (c)
            c.maximized = not c.maximized
            c.maximized_horizontal = c.maximized
            c.maximized_vertical   = c.maximized
            c:raise()
end)

[actionless]

i would only a bit improve it to handle floating clients better:

    function (c)
      c.maximized = not c.maximized
      if not c.maximized then
        c.maximized_horizontal = false
        c.maximized_vertical   = false
      end
      c:raise()
    end,

[Perlovka]

i would only a bit improve it to handle floating clients better:

As I understand, if c.maximized == true then c.maximized_horizontal and c.maximized_vertical are not taken to account, so this check is redundant, isn't it?

[actionless]

let me describe the usecase to clarify it:

1) client have maximized_horizontal and maximized_vertical set
2) user sets maximized
window became maximized
3) user unsets maximized
client still have maximized_horizontal and maximized_vertical set

from the point of logic that behavior (as in default config) is fine, but practically some applications are weirdly setting those maximized_horizontal and maximized_vertical and the modification from my comment above is the only way to get such clients back to normal without manually doing that via awesome-client or so on

[naoliv]

Is this the problem that makes an app being unmaximized only in one direction?

ie, I can properly maximize a terminal, but when unmaximizing it, it's horizontal size doesn't change (so I stay with a wide terminal using all the horizontal width).

[psychon]

@naoliv You want something like this: https://github.com/awesomeWM/awesome/commit/38840c911b37417949c69d4e788c458f20f9f2fa#diff-caa2908d246dcb889391ddaeda8fd13fL308

When you set the individual properties, then first the old geometry is remembered for restore. Then you also set the second property and the partial maximized geometry is saved for restore. So on restore only the last maximisation step is undone.

No idea how this worked previously, but the above is what happens now with awful.placement.

[naoliv]

@psychon this is what is happening:
1) I open some program (a terminal in this example); I am using the float layout and the terminal opens at the top left side

Maximize it normally:

But when I ask to unmaximize it, the horizontal size doesn't change anymore.

ie, after maximizing something, I can never get the size back to the original state.

awesome version is 4.0
I already tried all the config snippets from this issue, but without success.

Is this another problem? (already known, fixed or necessary to open another ticket, maybe?)

[blueyed]

https://github.com/awesomeWM/awesome/pull/1748#issuecomment-303257675 is about fixing this, in case you want to try it.

[Elv13]

Fix merged