If you open a window on a certain monitor and close it afterwards; the next time you start it it will keep its last known size. However, if you have two monitors, and reopen the application on the other monitor which has a different resolution (height is smaller), then an application that was maximized before, will have it's titlebar hidden outside of range. There is a workaround by using the 'Move' feature, but it is not nice. Also, this behavior might occur, when changing the resolution between closing and reopening. I suggest to implement a check, whether the window is indeed inside the current screen, and if not, move it inside, and then, resize, if necessary. There should be at least an option to specify, whether you want this behavior for the 'total screen' or the current screen; monitors might have totally different dpi. Reproducible: Always Steps to Reproduce: 1. Open an application on the monitor with larger height 2. Maximize it and close it 3. Open the application on the other monitor Actual Results: Title bar is out of range Expected Results: Title bar is inside current monitor (better even whole window)
Please specify "the application" for KDE applications should restore geometry "per screen" anyway and the client may reconfigure itself to that position after mapping (ie. there're several ways to end within this position and one needs to know which in order to tackle it) Relevant code is in manage.cpp and geometry.cpp
Created attachment 101380 [details] Patch It is basically happening with every application, but might be depending on the specific screen setup. I have two monitors, where the height of monitor one is greater than height of monitor 2. In addition monitor 2 has a vertical offset and is positioned right of monitor 1. So the titlebar of an application with full height on monitor will disappear on monitor 2 if the window is just shifted horizontally. The patch resolves this issue for me. However, I don't fully understand the purpose of the heuristic that is applied at that point, so it might screw thing up.
yeah titlebar should never be outside the area. There is something fishy there.
What exactly happens on your side? Do you enter the branch including "pseudo_max &= ~MaximizeVertical;"? If yes, keepInArea should be called anyway. If not, the window should be vertically maximized. Also debug out area around "if (height() >= area.height()) pseudo_max |= MaximizeVertical;" Could be the placement area is > the screenarea (because of borked struts) And please dump "xrandr -q"
Created attachment 101567 [details] xrandr -q
Created attachment 101568 [details] gdb debug output
I attached the gdb output. So yes, I enter the branch pseudo_max &= ~MaximizeVertical;. And yes, keepInArea is being called. But as I understand, this is not what actually should be called. fsa describes the full xrandr rectangle screen area. However, if you have two completely different screen sizes as in my case, there are lots of rectangle areas, that are not visible. What is the purpose of keepInArea(fsa,...) here? What are use cases when it makes sense to span the window over the whole fsa?
> 1366x768+1920+432 ^^^^^ I suppose this to be the troublemaker. The window asks to be bigger than your screen (no hackish attempt to be maximized) and your screen geometry can support this, so you don't need/want to shrink the window. Try instead diff --git a/manage.cpp b/manage.cpp index 4198e60..3cbfb9e 100644 --- a/manage.cpp +++ b/manage.cpp @@ -433,14 +433,14 @@ bool Client::manage(xcb_window_t w, bool isMapped) // i intended a second check on cs < area.size() ("the managed client ("minus border") is smaller // than the workspace") but gtk / gimp seems to store it's size including the decoration, // thus a former maximized window wil become non-maximized - bool keepInFsArea = false; + bool keepInArea = false; if (width() < fsa.width() && (cs.width() > ss.width()+1)) { pseudo_max &= ~MaximizeHorizontal; - keepInFsArea = true; + keepInArea = true; } if (height() < fsa.height() && (cs.height() > ss.height()+1)) { pseudo_max &= ~MaximizeVertical; - keepInFsArea = true; + keepInArea = true; } if (pseudo_max != MaximizeRestore) { @@ -457,8 +457,8 @@ bool Client::manage(xcb_window_t w, bool isMapped) geom_restore.setWidth(width()); } } - if (keepInFsArea) - keepInArea(fsa, partial_keep_in_area); + if (keepInArea) + keepInArea(area, true); } }
Yes, this helps as well. Basically the same thing as my patch (in this case). But why not just replace keepInArea(fsa, partial_keep_in_area); with keepInArea(area, partial_keep_in_area); instead ?
If it's not partial, the window would be shrunk (for no reason)
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!