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.
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>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).Closing.
Not a bug, but incomplete application rule.
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?
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 … :\
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.
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%}
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)
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 :-(
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?
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.
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.
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?
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.
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.
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.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:
[app] (name=vlc) (class=vlc) (role=vlc-main)
[Dimensions] {40% 60%}
[Position] (UPPERLEFT) {30% 1%}
[end]
it still reopens maximized, it will continue to do so until you try one of the following 3 recovery methods:
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
Reproduce the issue so you can test recovery method 3
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.
Last edit: Tuxo Holic 2021-04-19
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.
So you can reproduce it now using vlc?
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".
I will try to build your patch against version 1.3.7 then, so I can confirm it has the desired effect.
Try to use the git version - i don't even know whether you can apply it on 1.3.7
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.