Created attachment 5347 ~/.config/xfce4 Note: This has been originally reported in Red Hat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1051571 Description of problem: In certain (normal) multi-monitor setup, Maximize window feature fails to work properly on one of monitors. Specifically, the maximized window is partially covered with top (non-hiding) panel. Version-Release number of selected component (if applicable): xfwm4-4.10.1-2.fc20.x86_64 How reproducible: Always. Steps to Reproduce: 0. Have * two monitors, in my case LVDS1 (laptop's built-in monitor) and a NEC MultiSync E213W connected as HDMI3 * Fedora workstation with Xfce4 as default * arandr installed (to change the monitor layout) 1. Log in to new user; choose the default panel layout 2. Create a new panel (panel3) and set it to 100% width 3. Dock the panel3 to top border of the HDMI3 4. Start arandr and change monitor superposition so that tha "small" LVDS1 is under the "big" HDMI3. In my case this moves the Xfce panels to the HDMI3. As a side effect this hides the panel3, apparently under the panel1. 5. Open panel settings, choose panel3 and change output to LVDS1. 6. Now open a window, say Thunar, move it to LVDS1 and maximize it Actual results: Window is partially hidden by the panel3 (depends on panel and decorations size). Expected results: Window should maximize with respect to any non-hiding panels and not be covered. This should apply to all monitors, no matter how they are arranged by *randr. Additional info: When I open the arandr again and switch the monitors so that the LVDS1 is on top, the problem happens on the HDMI3-bound panel. So it seems to affect: * panel bound with monitor that is on the bottom * or a docked panel that neighbors with another monitor. This also affects "Maximize vertically". I haven't tested the horizontal version of the whole issue (layout side by side, panel docked "between"...).
Created attachment 5348 ARandr screen-shot (not from the same test as the other attachment)
You have a top panel placed on a lower monitor? This is normal, struts would cause the upper monitor to be unusable because by definitions struts are relative to the logical screen size (ie the whole screen embedding all your monitors). You cannot place panels in between monitors, it's not supported.
In other words, you must keep your edge panels close the logical screen edges, depending on your layout.
I have similar problem. When I dock a notebook and use xrandr to activate only the external display; everything is OK. When I undock the notebook and activate only the builtin LVDS panel, all maximized windows are overlapped by xfce4-panel. See http://phatina.fedorapeople.org/xfwm4_overlapped.png Xfwm behaves the same, when I use xrandr or xfce4-display-settings.
(In reply to Peter Hatina from comment #4) > I have similar problem. I doubt this is the same problem. > When I dock a notebook and use xrandr to activate > only the external display; everything is OK. When I undock the notebook and > activate only the builtin LVDS panel, all maximized windows are overlapped > by xfce4-panel. > > See http://phatina.fedorapeople.org/xfwm4_overlapped.png > > Xfwm behaves the same, when I use xrandr or xfce4-display-settings. I fail to see an obvious problem with the screenshot.
There is an input text box in HexChat (at bottom) - you can't see it, because it is overlapped by xfce4-panel.
(In reply to Peter Hatina from comment #6) > There is an input text box in HexChat (at bottom) - you can't see it, > because it is overlapped by xfce4-panel. Well, your problem is unrelated to this issue here as described in comment 0 so please open a separate bug and post the output of "xrandr -q" there, let's not confuse everything. As always, please make sure to specify the actual versions in the report, as reported by "xfwm4 --version" and "xfce4-panel --version". See also bug 11058 and bug 11059 if your problem is not a dupe.
(In reply to Olivier Fourdan from comment #2) (In reply to Olivier Fourdan from comment #3) Hi, Oliver, perhaps I can supply quite an extended setup to clarify the situation: . - two (HW) graphics adapters, . - four (HW) Monitors, . - four independent separate X11 screens (no TwinView, no Xinerama) . - layout: 2 x 2 (two "upper", two "lower") . - layout: Screen 1 | Screen 2 . - layout: Screen 0 | Screen 3 . - on each: panel (at top) . - in each: workspace switcher with 20 ws in 2 rows (2 x 10) :: The situation I observe is _non-uniform_ . I) First, let's look at behaviour of some of XFCE_4.12 own's applications: o) xfce4-terminal, o) xfce4 file manager thunar: A) on "upper right" monitor: . Maximize_Window behaves as expected, . only uses work-space _without_ panel-space, . does not "slip under the panel's hood", . no matter if started in "upper" or "lower" workspace row. B) on "upper left" monitor and B) on "lower" monitors: . Maximize_Window results in a full-screen window, . top of it being hidden below panel at top; . thus the window buttons become unusable. . This behavior is unaffected no matter . if started in "upper" or "lower" workspace row. Can be restored to previous size by right-klicking its entry in the task bar in the panel. This behavior is unaffected by changing the workspace to linear (1 row only). This behavior is unaffected by changing . -> xfce settings -> window management -> "Advanced" tab -> border settings. II) Second, let's check these findings against other applications: o) kde-apps (konsole, kate, dolphin, okular, k3b, kaffeine), o) xsane preview window, o) KVM Virtual MAchine Manager, o) RawTherapee, o) LibreOffice, o) Mozilla Firefox, Thunderbird: :: All suffer from the same problem / discrepancy described under (A) <-> (B). #################### (In reply to Peter Hatina from comment #6) (In reply to Olivier Fourdan from comment #7) I'm not so sure that it's defenitely unrelated. The difference in his case: all of this happens at the bottom of the respective monitor / screen / window because his panel is at the bottom. @ Peter: . . . Could you please be so kind to supply a similar survey? #################### Some info to begin with (more to follow as attachments): $ uname -a Linux sid 4.1.11-gentoo #1 SMP Tue Oct 27 10:24:57 CET 2015 x86_64 Intel(R) Xeon(R) CPU E3-1276 v3 @ 3.60GHz GenuineIntel GNU/Linux [IP-] [ ] dev-util/xfce4-dev-tools-4.12.0:0 [IP-] [ ] x11-terms/xfce4-terminal-0.6.3:0 [IP-] [ ] xfce-base/xfce4-appfinder-4.12.0-r1:0 [IP-] [ ] xfce-base/xfce4-meta-4.12:0 [IP-] [ ] xfce-base/xfce4-panel-4.12.0-r1:0 [IP-] [ ] xfce-base/xfce4-session-4.12.1:0 [IP-] [ ] xfce-base/xfce4-settings-4.12.0-r1:0 [IP-] [ ] xfce-base/thunar-1.6.10-r1:0 [IP-] [ ] kde-apps/konsole-4.14.3-r1:4/4.14 <----- +++++ !!!!! HTH! Thanks. Kind regards Manfred
Created attachment 6494 my /etc/X11/xorg.conf.d/ directory (tar -xvf)
Created attachment 6495 my $HOME/.config/xfce4 (tar -xvf)
Created attachment 6496 output of "emerge --info xfce4-meta"
$ xfwm4 --version This is xfwm4 version 4.12.3 (revision 7fdcb53) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.28, using GTK+-2.24.28. Build configuration and supported features: - Startup notification support: No - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Embedded compositor: Yes - KDE systray proxy (deprecated): No $ xfce4-panel --version xfce4-panel 4.12.0 (Xfce 4.12) Copyright (c) 2004-2011 Die Xfce-Entwicklungsmannschaft. Alle Rechte vorbehalten. Fehler bitte an <http://bugzilla.xfce.org/> melden.
(In reply to Manfred.Knick from comment #8) > [IP-] [ ] kde-apps/konsole-4.14.3-r1:4/4.14 <----- +++++ !!!!! Please _dis-regard_ the special marking (no highlighting intended any more). (It's a left-over from a first draft and rendered obsolete by my later findings).
(In reply to Olivier Fourdan from comment #2) > You have a top panel placed on a lower monitor? In the current "Panel Settings" dialogue, I did not find any parameter in order to configure that the panel should place itself "at the bottom" instead of "at the top". Any hint ? Thanks.
Created attachment 6497 output of "emerge --info xfce4-meta" re-delivery as ".txt" (no binary at all) so you should be able to open it in your browser directly.
What would be useful is: - Output of "xprop -root" - Output of "xprop" taken on the panel which covers the window. Please capture the output of the commands above and put that as attachment to this bugzilla. BTW, you know xfce4-panel has an option to *not* set struts ("Panel preferences" -> "Don't reserve space on border"), please make sure this is not enabled.
(In reply to Olivier Fourdan from comment #16) > What would be useful is: > BTW, you know xfce4-panel has an option to *not* set struts ("Panel > preferences" -> "Don't reserve space on border"), please make sure this is > not enabled. Checked on all four screens: "not enabled "
Created attachment 6498 Upper-Left_xprop-root_not-maximized
Created attachment 6499 Upper-Left_xprop-panel_not-maximized
Created attachment 6500 Upper-Left_xprop-root_maximized
Created attachment 6501 Upper-Left_xprop-panel_maximized
attachment 6499 shows no _NET_WM_STRUT_PARTIAL being set, means it reserve no area for itself. No wonder it overlaps with maximized window. This is bug in the panel, not the window manager.
Created attachment 6502 Upper-Right_xprop-root_not-maximized
Created attachment 6503 Upper-Right_xprop-panel_not-maximized
Created attachment 6504 Upper-Right_xprop-root_maximized
Created attachment 6505 Upper-Right_xprop-panel_maximized
(In reply to Olivier Fourdan from comment #16) > What would be useful is: > > - Output of "xprop -root" > - Output of "xprop" taken on the panel which covers the window. Sure - you are welcome: $ ls -1 Upper-* ( re-sorted ) Upper-Left_xprop-root_not-maximized Upper-Left_xprop-panel_not-maximized Upper-Left_xprop-root_maximized Upper-Left_xprop-panel_maximized Upper-Right_xprop-root_not-maximized Upper-Right_xprop-panel_not-maximized Upper-Right_xprop-root_maximized Upper-Right_xprop-panel_maximized The problematic case is "Upper-Left_xprop-*_maximized". Anything else I can help with?
(In reply to Manfred.Knick from comment #19) > Created attachment 6499 > Upper-Left_xprop-panel_not-maximized Same with attachment 6499 , no struts specified by the panel. Please either file a new bug against the panel or move this bug to xfce4-panel if you reckon it's the same as the original issue.
The maximized versions don't differ from their non-maximized counterparts at all: $ diff Upper-Left_xprop-root_not-maximized Upper-Left_xprop-root_maximized $ diff Upper-Left_xprop-panel_not-maximized Upper-Left_xprop-panel_maximized $ diff Upper-Right_xprop-root_not-maximized Upper-Right_xprop-root_maximized $ diff Upper-Right_xprop-panel_not-maximized Upper-Right_xprop-panel_maximized $
(In reply to Manfred.Knick from comment #29) > The maximized versions don't differ from their non-maximized counterparts at > all: > > $ diff Upper-Left_xprop-root_not-maximized Upper-Left_xprop-root_maximized > $ diff Upper-Left_xprop-panel_not-maximized Upper-Left_xprop-panel_maximized > $ diff Upper-Right_xprop-root_not-maximized Upper-Right_xprop-root_maximized > $ diff Upper-Right_xprop-panel_not-maximized > Upper-Right_xprop-panel_maximized > $ Not sure what you're trying to say here, struts don't change when the window is maximized, but the panel should set its struts and it doesn't and that'd a bug in the panel.
Created attachment 6506 Upper-Left_xprop-xfce-terminal_not-maximized
Created attachment 6507 Upper-Left_xprop-xfce-terminal_maximized
Created attachment 6508 Upper-Right_xprop-xfce-terminal_not-maximized
Created attachment 6509 Upper-Right_xprop-xfce-terminal_maximized
But these pairs differ: $ diff Upper-Left_xprop-xfce-terminal_not-maximized Upper-Left_xprop-xfce-terminal_maximized $ diff Upper-Right_xprop-xfce-terminal_not-maximized Upper-Right_xprop-xfce-terminal_maximized
@ Olivier: "Version: 4.10.1" "Target Milestone: Xfce 4.6" "Status: NEW" You surely noticed that my version is 4.12 already.
(In reply to Olivier Fourdan from comment #30) > (In reply to Manfred.Knick from comment #29) > Not sure what you're trying to say here ... Sorry - missed your answer during my investigation - obsolete.
(In reply to Olivier Fourdan from comment #22) (In reply to Olivier Fourdan from comment #28) > or move this bug to xfce4-panel Could you please be so kind? (As a simple new user, I don't see having any permissions to do so.) > if you reckon it's the same as the original issue. Yes, I do so.
I don't know xfce interna at all. But the following observation strikes me: The only case in which Maximizing works as expected is when . - there is no more "X administered space" to the right _*and*_ . - there is no more "X administered space" above. But for the decision to keep the maximized window smaller than the whole screen, only the latter is relevant. A "wild guess" - to be tested: I presume if the panels would be configured vertically to the left, the "upper left" would work and the "upper right" would fail.
(In reply to Manfred.Knick from comment #39) > I don't know xfce interna at all. > But the following observation strikes me: Sorry that doesn't make any sense to me. Struts are a pretty simple mechanism, but if not specified there is no way t can work, simple as that. Struts and partial struts apply to the overall screen size in xinerama/xrandr setup, meaning that it just cannot work with some xrandr layouts, it's just a limitation of the standard and not a bug in xfce. You mentioned in comment 8 that you are running with 4 separate *screens* aka "Zaphod" mode, so you have one root window per screen and therefore that limitation with struts doesn't apply in your case. But precisely because you are using zaphod mode and not xrandr/xinerama, it means that your issue is a different one from what was initially reported 7 months ago. You are basically hijacking an old bug with a different setup that vaguely resemble yours but by nature it cannot be the same issue. The numerous xprops you attached show that the panel does not set the struts or partial struts, there is no point in looking any further, this is not a bug in xfwm4.
(In reply to Olivier Fourdan from comment #40) > it's just a limitation of the standard and not a bug in xfce. > that limitation with struts doesn't apply in your case. > by nature it cannot be the same issue. > the panel does not set the struts > or partial struts, there is no point in looking any further, > this is not a bug in xfwm4 Thanks, agreed / understood / agreed - no dissent that this bug is to be searched for in "panel" at all. A) Question: Please excuse me being new to the XFCE community and it's bugzilla.xfce.org. (In reply to Olivier Fourdan from comment #22) > This is bug in the panel, not the window manager. I'm using xfce-base/xfce4-panel-4.12 as part of Gentoo's current XFCE_4 suite (xfce-base/xfce4-meta). Beg your pardon for asking where exactly you do request this bug to be reported (or how) - do xfce4 panel bugs not belong into bugzilla.xfce.org ? B) <-> Observation: This was intended for further digging at the bug in _panel_ , not in _xfwm_. The point is: . - why does the panel set the struts or partial struts correctly . - - for exactly "upper right", but . - fail to set the struts or partial struts correctly . - - for all of "upper left", "lower left" and "lower right" separate *screens* ? Thanks.
(In reply to Manfred.Knick from comment #41) > where exactly you do request this bug to be reported (or how) - > do xfce4 panel bugs not belong into bugzilla.xfce.org ? You are confusing bugzilla and the components - Yes, of course, this is a bug in xfce as a whole and should be reported in bugzilla.xfce.org but there are a lot of different components in xfce, all I am saying is you need to file your bug in the right component. https://bugzilla.xfce.org/describecomponents.cgi This particular bug here is reported against xfwm4 (see product == xfwm4) whereas the issue lies in another product (product == xfce4-panel). > The point is: > . - why does the panel set the struts or partial struts correctly > . - - for exactly "upper right", > but > . - fail to set the struts or partial struts correctly > . - - for all of "upper left", "lower left" and "lower right" > separate *screens* ? This is a question for the xfce4-panels devs. A hint, though, does the panel on screen 0 (ie the one placed on the lower left monitor according to your description in comment 8) have the struts set appropriately?
Created attachment 6510 Lower-Left_xprop-panel_taken-from_xfce-terminal_not-maximized
Created attachment 6511 Lower-Left_xprop-panel_taken-from_xfce-terminal_maximized
Created attachment 6512 Lower-Right_xprop-panel_taken-from_xfce-terminal_not-maximized
Created attachment 6513 Lower-Right_xprop-panel_taken-from_xfce-terminal_maximized
(In reply to Olivier Fourdan from comment #42) > ... does the panel on screen 0 ... have the struts set appropriately? Nope - nor does "Lower right" = screen 3: $ grep _NET_WM_STRUT_PARTIAL Lower* $
### Cross-Reference: ### Xfce Bugzilla – Bug 12281 : ### [multiple separate X screens] xfce4-panel fails to correctly set _NET_WM_STRUT_PARTIAL ### https://bugzilla.xfce.org/show_bug.cgi?id=12281 Further discussion concerning the case described in comments 8 .. 47 should be continued over there. Thanks.
(In reply to Olivier Fourdan from comment #22) > ... no _NET_WM_STRUT_PARTIAL being set, means it > reserve no area for itself. > No wonder it overlaps with maximized window. > > This is bug in the panel, not the window manager. You were absolutely right: Not detecting the panel snap_position at all resulted into STRUTS_EDGE_NONE; thus no struts region got reserved. Patch supplied to separated BUG 12281. Thanks again for setting me 'on track' ! Kind regards Manfred
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/141. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev