#1176 close kde app maximized does always reopen it fully maximized

[Tuxo Holic]

Hello,
If I close a qt5 application in maximized state the ~/.fluxbox/apps file definition is ignored the next time I start the same app. So it remains fully maximized, no matter how you close it next. The ~/.config/<kdeapp>rc file got updated with the value "Window-Maximized 1080x1920=true"</kdeapp>

Here's what it looks like for kde - konsole.

[MainWindow]
Height 1080=1017
State=AAAA/wAAAAD9AAAAAAAAB4AAAAPaAAAABAAAAAQAAAAIAAAACPwAAAAA
Window-Maximized 1080x1920=true

removing the Window-Maximized line does fix the issue, but config file editing is annoying if it happens often. Why does fluxbox follow a kwin syntax anyway when we have the fluxbox/apps file?

Here's what the entry looks like in ~/.fluxbox/apps to start it centered horizontaly and maximized only vertitcally, not fully.

[app] (name=konsole) (class=konsole)
  [Dimensions]  {73% 100%}
  [Position]    (UPPERLEFT)     {16% 0%}
[end]

I don't use a "role" definition, could this help to override the "MainWindow" Problem?

I shoud also mention I use qt5ct to change the icon theme and font size, I hope it does not have side effects on the window geometry handling.

[Thomas Luebking]

The client does the ~/.config/<kdeapp>rc stuff, that has nothing to do w/ fluxbox.
It will restore the maximization state which is independent from the geometry.
If it does that early enough (I seem to recall that Qt5 had a bug itr) you can add [Maximized] {no} or [Maximized] {vert} to prevent the maximization.</kdeapp>

[Tuxo Holic]

Hello Thomas, I finally had the time to test this more thoroughly and [Maximized] {no} seems to do the trick, Thank you. One thing that worked as well is force the window into full screen mode and back (usually F11 but it depends on the app).

[Thomas Luebking]

Closing.
Not a bug, but incomplete application rule.

[Tuxo Holic]

Oh boy, sorry Thomas to bother you with this one more time, but did you happen to test Debian Bullseye? I just did and kwin is acting up in new ways with the app ruleset: Now the max statement inside qt5 ~/.config/rc files is written like this:

HDMI-1 Window-Maximized 1080x1920=true

and your nifty trick of [Maximized] {no} has no more effect! :-( So basically the only help is go fullscreen (f11 in many cases) and back with your qt5 application - this still works as it does erase the maximization tag in the rc file. Is that something to report upstream to kde devs then? If so: against what project? Is this indeed a kwin issue in your opinion?

[Thomas Luebking]

KWin is a different window manager - what (likely) happens is what I worried before: The client maximizes the window after mapping it, so fluxbox (or any WM, actually) gets the window unmaximized, resizes and repositions it and then the client maximizes it afterwards.

The problem is not KWin (nor fluxbox) and Qt has a truckload of "restoreGeometry fails" bugs :(

I thought whether rules to override _ NET_WM_ALLOWED_ACTIONS might help you, but you probably still want to be able to maximize the window?
Another way would be to allow to ignore client geometry/state requests (so you can maximize the window, but konsole can't maximize itself)
nb. that all of this will require patches to the fluxbox code which I could write, but they're not necessarily upstreamed and the 1.4 relase might never happen anyway (so you'd have to build fluxbox-git yourself)

You can possibly address this from the other side, though.
Does konsole respond to

printf "\x1B[8;32;100t" # ideally this resizes the window to 100x32 chars

?
You might be able to, err… "fix" this from the shells rc … :\

[Tuxo Holic]

Sorry, that printf statement has no effect in Buster or Bullseye kde konsole. VLC player has a qt5 user interface as well and this is basically the only app I often use in fullscreen. VLC is affected by maxi problem as well and people like to use it in fullscreen, other apps don't matter that much. It would be nice to have a qt5 setting maybe in ~/.config/kdeglobals ,that would just tell all qt5 apps to stop re-open closed windows in maximized state :-( This maximize tag should only be set like optionally.

[Tuxo Holic]

To answer you question whether qt5 settings should have the final word or not on geometry or positioning: I always thought it was fluxbox-apps so an app that tries to position it somewhere different or open it in a different size that would be ignored by fluxbox? You can even spot this sometime if you for example open firefox-esr, it might for a second open on the left side, but then immediatly move to the right side with a statement like [Dimensions] {50% 100%}
[Position] (UPPERLEFT) {50% 0%}

[Thomas Luebking]

fluxbox-apps controls what to make out of the window state and geometry hints when it maps, but the client can certainly first map a window, get ruled by fluxbox-apps and then alter its geometry and/or state and fluxbox doesn't intervene here (this would require a rule to make it completely ignore the clients requests itr - which is possible but currently not implemented)

[Tuxo Holic]

Hello, did some more testing in the meantime and observed how other window managers like xfwm or openbox are handling qt5 apps: they both immediately clear the Window-Maximized tag as soon as you click the maximize button one more time. Window size also reverts to how it was before. That's the expected behaviour IMHO, but none of them offers windows size management as sophisticated as fluxbox does :-(

[Thomas Luebking]

I thought the problem was that you couldn't control the windows initial position? Not that you couldn't un-maximzie it?

If you still have a rule in place that downforces the maximization state, the window will likely end up not maximized, but just "big" (and hence clicking the maximization button will have no apparent effect - the maximized and unmaximized geometry are simply identical)

=> xprop?

[Tuxo Holic]

No, it's a size issue, not a placement issuse: most apps seem to register a maximized state immediately in their respective config file, if you close them maximized, they restore itself maximized when you open them next. That's considered a feature these days ... even all the browsers I tested do it. The difference to qt5 behaviour under fluxbox is the following: The Window-Maximized tag should get erased immediately (even before closing) once you click the un-maximize button. This does happen with plasma, xfwm, openbox but it does not happen with fluxbox. With fluxbox it is only cleared if I either fullscreen the app or I put it into minimized state. It does appear as a fluxbox only issue then.

[Tuxo Holic]

Downforce the app with a [Maximized] {no} entry : This still works fine in Debian 10 Buster, it has never worked in upcoming Debian 11 Bullseye, no idea why that is.

[Thomas Luebking]

The Window-Maximized tag should get erased immediately (even before closing) once you click the un-maximize button.

I'm pretty sure that fluxbox removes the maximized state the very moment you unmaximize the window, check xprop -spy _NET_WM_STATE on the window.
What Qt does in its config is otherwise hardly related to anything fluxbox does - the window manager (any window manager) just reads and sets those properties and the client can read them from there.

I'd suggest to temporarily move away your .fluxbox/apps config and check whether that has impact on the behavior.

Not sure whether this is of any help, but you could also redefine the close button to first minimize the window…

Since you stress "immediately", what's the actual use-pattern here? Is there some unmaximize-close automatism involved?

[Tuxo Holic]

xprop -spy _NET_WM_STATE
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ,

That's what it says, the window was already vertically maximized by fluxbox-apps. What fluxbox prevents is clearing the Window-Maximized Tag in qt5 apps, please test against kde konsole,kwrite, vlc with qt5 gui. They all don't remove the tag when you click un-maximize, but they remove it immediately when you minimize or fullscreen those apps. In Openbox,plasma and xfwm they remove it the instant you hit un-maximize.

[Tuxo Holic]

Run tests against an empty apps file and the problem remains: Window-Maximized tag is not cleared by un-maximize, but it is cleared by minimize or fullscreen.

[Thomas Luebking]

I don't run KDE and fluxbox cannot prevent that.

~/.config/vlc/vlc-qt-interface.conf doesn't seem to have those keys regardless of what I do.

What might happen is that fluxbox removes an empty property and other WMs might not and Qt doesn't interpret an absent property as "remove that flag" but as "uhmmm… dunno"
This would fit your perception reg. the minimized and fullscreen windows, as they set other flags on that property.

=> When you spy the property and un-maximize a window, what happens to it?
xprop -f _NET_WM_STATE 32a -set _NET_WM_STATE "" will set an empty property - if the above assumption is correct, then Qt should respond by removing the maximization key from its config.

[Tuxo Holic]

vlc does it indeed different because it is not a kde app: you have geometry=@ByteArray=CODE definitions in ~/.config/vlc/vlc-qt-interface.conf. The relevant one is on line 4, it controls main window size. Remove it and fluxbox-apps can set size correctly again.

Okay, if vlc is the only app you have using QT5 menu dekoration, let me write steps to reproduce the problem and how to recover once it happened:

1. Add this and only this to ~/.fluxbox/apps so we use the same setup:

[app] (name=vlc) (class=vlc) (role=vlc-main)
[Dimensions] {40% 60%}
[Position] (UPPERLEFT) {30% 1%}
[end]

1. make sure you do have vlc-plugin-qt installed and activated (I assume that is already the case)
2. open vlc, it should open the way fluxbox-app set it to
3. hit the square button to maximize the main window
4. test that you can still un-maximize the main window by hitting the square again
5. close vlc by clicking the X button
6. open vlc again, now it should open maximized
7. try to un-maximize the window and confirm it is not possible to do so
8. mouse-grab the lower right window edge and resize it to something not maximized, then quit vlc by clicking X

9. it still reopens maximized, it will continue to do so until you try one of the following 3 recovery methods:

10. grab the lower right edge and resize it to something not maximized, then click the minimize button and un-minimize it by clicking the taskbar entry. Now quit with X. It is fixed and follows the fluxbox-app rule again.

Reproduce the issue so you can test recovery method 2

1. grab the lower right edge and resize it to something not maximized, then hit fullscreen which can be set by keystroke (F or F11) or in the Video menu. Quit the fullscreen with ESC and quit vlc using the X button. It is fixed and follows the fluxbox-app rule again.

Reproduce the issue so you can test recovery method 3

1. modify ~/.config/vlc/vlc-qt-interface.conf: remove line 4 starting with geometry=@ByteArray=CODE and close vlc. It is fixed and follows the fluxbox-app rule again.

That should be it, you should be able to reproduce it now in Debian Buster and the fluxbox version Debian provides. KDE apps will behave in the same way, tested against kwrite, konsole.

[Thomas Luebking]

I actually tested my former suspicion on vlc last night and it restores the un-maximized stated depending on whether I set a dead _NET_WM_STATE propertry before closing it, so Qt just doesn't like that property being withdrawn.

[Thomas Luebking]

diff --git a/src/Ewmh.cc b/src/Ewmh.cc
index 03a824fa..c73c24a9 100644
--- a/src/Ewmh.cc
+++ b/src/Ewmh.cc
@@ -1019,12 +1019,12 @@ void Ewmh::updateState(FluxboxWindow &win) {
             XFree(data);
         }

-        if (!client_state.empty()) {
+//        if (!client_state.empty()) {
             (*it)->changeProperty(m_net->wm_state, XA_ATOM, 32, PropModeReplace,
                                   reinterpret_cast<unsigned char*>(&client_state.front()),
                                   client_state.size());
-        } else
-            (*it)->deleteProperty(m_net->wm_state);
+//        } else
+//            (*it)->deleteProperty(m_net->wm_state);
     }
 }

[Tuxo Holic]

So you can reproduce it now using vlc?

[Thomas Luebking]

I'm not sure how that relates to the original bug, but I could maximize & unmaximize vlc and have it re-open maximized.
I also pre-explained the likely cause, could verify it and posted a patch in https://sourceforge.net/p/fluxbox/bugs/1176/#cc9f which will make fluxbox just empty the property instead of cleaning up.

Please notice that I do not maintain fluxbox ("just a user") and on top of that I cannot even make a compelling case why this needs to be "fixed" because it's Qt which is in violation of the spec.
A (suddenly) absent property isn't an invitation to wet yourself - the spec even recommends the WM to withdraw the property before closing the window and it's general support is declared by the _NET_SUPPORTED atom on the root window. So "no property" means "no state", not "shrug".

[Tuxo Holic]

I will try to build your patch against version 1.3.7 then, so I can confirm it has the desired effect.

[Thomas Luebking]

Try to use the git version - i don't even know whether you can apply it on 1.3.7

[Tuxo Holic]

I could apply it to 1.3.7 and it almost works! When you reopen vlc after it was closed maximized, it still won't let you un-maximize, but it does clear the geometry tag. So the next time you open vlc, it will follow the fluxbox-app ruleset again.

May I recommend for you to spot the expected behaviour with Gimp (a gtk app)? I assume you have it installed? Gimp is behaving exactly like expected: reopen maximized, allow to un-maximize to the state it was before you clicked maximize. From then on re-open not maximized.