### TRANSFER from Xfce Bugzilla - Bug 10669 - Comments 8 .. 47 : ### https://bugzilla.xfce.org/show_bug.cgi?id=10669#c8 ### as a separate bug. In an extended setup: . - two (different HW) graphics adapters, . - four (different 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) xfce panel fails to set _NET_WM_STRUT_PARTIAL on all but screen 2 ("upper right"): $ grep _NET_WM_STRUT_PARTIAL *xprop-panel* Upper-Right_xprop-panel_maximized: _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 31, 0, 0, 0, 0, 0, 0, 1919, 0, 0 Upper-Right_xprop-panel_not-maximized: _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 31, 0, 0, 0, 0, 0, 0, 1919, 0, 0 $ In order to avoid duplicity, please c.f. the information already provided in Bug 10669 and it's attachments. Thanks.
(In reply to Manfred.Knick from comment #0) > on all but screen 2 ("upper right"): In between, it applies to *all* four screens: "xprop | grep -i strut" delivers empty result on every panel. $ equery list xfce4-panel [IP-] [ ] xfce-base/xfce4-panel-4.12.0-r1:0 Unfortunately, I am not aware what might have caused the difference. I had my system completely re-built ( --emptytree ) with gcc-5.3.0 , but doubt that to be an explanation.
I just cross-checked with the current git repositories ( via layman ) ( https://cgit.gentoo.org/proj/xfce.git/ ) to no better avail.
Cross-Reference: . . . https://bugs.gentoo.org/show_bug.cgi?id=568880
Created attachment 6563 ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml A minimalist panel config exposing the described behaviour
Downloading the source code of xfce4-panel-4.12.0, I could not identify any spot in ./panel/* where any current value gets attributed to . . . snap_position , especially not in ./panel/panel-window.c . ==> In consequence of the default value SNAP_POSITION_NONE being set in panel_window_init and missing the correct SNAP_POSITION_xy being set afterwards, STRUTS_EDGE_TOP can not be evaluated for the panel; thus no struts region gets reserved at all. ### In ./migrate/migrate-46.c, line 103 ff, I found code like . . . *snap_position = SNAP_POSITION_NC but could not identify this being called from anywhere. To me, this looks like a forgotten stalled pizza in deep freeze :) ### Minor: . - I guess, "StrutsEgde" was intended as "StrutsEdge". . - Some enums are intended to not have any name by purpose? Thanks.
In panel_window_motion_notify_event I found window->snap_position = panel_window_snap_position (window); but does this function get called if the panels keep fix and unchanged from start to end?
Created attachment 6565 excerpt of panel DEBUG messages when starting xfce Starting XFCE$ with DEBUG messages enabled for panel: "PANEL_DEBUG=1 startx /usr/bin/startxfce4 -- -layout Four" What I could not understand at once: Why is the whole screen assigned as "working-area" : "h=1440", not only the configured 30 pixels at the top of the screen?
"PANEL_DEBUG=struts startx /usr/bin/startxfce4 -- -layout Four" gave no additional (struts) info lines.
panel-window.c : g_print ("### panel_window_set_property PROP_POSITION: \n"); g_print ("### snap;x;y : %s ### \n", val_string); ==> ### panel_window_set_property PROP_POSITION: ### snap;x;y : p=0;x=0;y=0 ### <--- ! p=0 ! proves that window->snap_position becomes CLAMP'ed to 0 == SNAP_POSITION_NONE in all four cases. In consequence, g_print ("### panel_window_screen_struts_edge : \n"); g_print ("### window->snap_position : %d ### \n", window->snap_position); ==> ### panel_window_screen_struts_edge : ### window->snap_position : 0 ### will return STRUTS_EDGE_NONE panel_window_motion_notify_event is _not_ called, thus /* update the snapping position */ window->snap_position = panel_window_snap_position (window); does _not_ get executed. Another test: With the panel dialogue, change to "vertical" and back to "horizontal": ### panel_window_screen_struts_edge : ### window->snap_position : 0 ### ### panel_window_screen_struts_edge : ### window->snap_position : 0 ### Finally: g_print ("### panel_window_screen_layout_changed : \n"); ==> ### panel_window_screen_layout_changed : and g_print ("### panel_window_snap_position : \n"); ==> ( no output ) prove that the function panel_window_snap_position <--- !!! does _never_ get executed at all. <--- !!!
PROPOSAL: In xfce4-panel-4.12.0/panel/panel-window.c , in function static StrutsEgde panel_window_screen_struts_edge (PanelWindow *window) , add the call window->snap_position = panel_window_snap_position (window); right before switch (window->snap_position) RESULT: ### call panel_window_snap_position : ### panel_window_snap_position : ### window->snap_position : 6 ### RESULT: $ xprop | grep STRUT _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 31, 0, 0, 0, 0, 0, 0, 2559, 0, 0 Now, maximizing an application window, this stays restricted below the panel. Switching to "vertival" or "horizontal" displays the expected maximizing and re-sizing behaviour. Thanks.
The supplement has to be placed around ~ line 1546 : static StrutsEgde panel_window_screen_struts_edge (PanelWindow *window) { panel_return_val_if_fail (PANEL_IS_WINDOW (window), STRUTS_EDGE_NONE); /* no struts when autohide is active or they are disabled by the user */ if (window->autohide_state != AUTOHIDE_DISABLED || window->struts_disabled) return STRUTS_EDGE_NONE; /* first, let's make sure we are working upon <--- currently updated snap_position: */ <--- window->snap_position = panel_window_snap_position (window); <--- <--- /* return the screen edge on which the window is * visually snapped and where the struts are set */ switch (window->snap_position) { case SNAP_POSITION_NONE: return STRUTS_EDGE_NONE; ...
AFAICS, this bug is completely independent of "Zaphod mode"; I assume it should expose itself also under Xinerama conditions et al. ; anybody who can confim this, please? Thus removing this from the title of this bug. Please NOTE: STRUTS settings apply to an X _Screen_ which might compose of multiple monitors in XrandR / Xinerama setups which Olivier pointed out in the original bug: https://bugzilla.xfce.org/show_bug.cgi?id=10669#c40 .
Comment10 and Comment11
# diff panel-window.c /home/manfred/TEMP/xfce4-panel-4.12.0/panel/panel-window.c 1546,1549d1545 < /* first, let's make sure we are working upon < * currently updated snap_position: */ < window->snap_position = panel_window_snap_position (window); <
SORRY - now in 'unified' format for the patch: # diff -u /home/manfred/TEMP/xfce4-panel-4.12.0/panel/panel-window.c panel-window.c --- /home/manfred/TEMP/xfce4-panel-4.12.0/panel/panel-window.c 2015-02-28 15:52:27.000000000 +0100 +++ panel-window.c 2015-12-22 16:35:44.073877284 +0100 @@ -1543,6 +1543,10 @@ || window->struts_disabled) return STRUTS_EDGE_NONE; + /* first, let's make sure we are working upon + * currently updated snap_position: */ + window->snap_position = panel_window_snap_position (window); + /* return the screen edge on which the window is * visually snapped and where the struts are set */ switch (window->snap_position)
Created attachment 6566 /etc/portage/patches/xfce-base/xfce4-panel-4.12.0-r1/4.12.0-01-panel.patch
RE-OPENING for visibility as porposed in https://bugs.gentoo.org/show_bug.cgi?id=568880#c10 < cite || previously asked via private mail > Hi, Nick, unfamiliar with DE in general and XFCE procedures especially, I am not sure that closing as "WORKSFORME" already now was correct. Should it be kept open until integrated into your XFCE panel source tree? Are you going to review and take this to your tree so it does not get lost for the next release version? Thanks for clarification. Kind regards from Munich, Germany Manfred
Hi guys, I am reporting a hopefully related issue: 3 monitors side-by-side, 1 logical screen (nVidia, on a laptop with 2 displayports, left monitor is internal screen). 1 panel, on the left edge in the MIDDLE screen. Maximising the window should not cover / go under the panel. It has been previously reported that this cannot work as its not on the edge of the combined screen, but this advice is WRONG. I can correctly set up _NET_WM_STRUT_PARTIAL using this command for my particular setup: xprop -f _NET_WM_STRUT_PARTIAL 32c -set _NET_WM_STRUT_PARTIAL '1986, 1920, 0, 0, 0, 1079, 0, 0, 0, 0, 0, 0' (and then click on the panel) The windows then correct maximise on ALL of the monitors. I looked at the xfce4-panel code, and hacked it like so (psuedo-patch here): static void panel_window_screen_struts_set (PanelWindow *window) .... line 1628 .... else if (window->struts_edge == STRUTS_EDGE_RIGHT) { /* the window is snapped on the right screen edge */ struts[STRUT_RIGHT] = gdk_screen_get_width (window->screen) - alloc->x; struts[STRUT_RIGHT_START_Y] = alloc->y; struts[STRUT_RIGHT_END_Y] = alloc->y + alloc->height - 1; } + else + { + struts[STRUT_LEFT] = 1986; + struts[STRUT_RIGHT] = 1920; + struts[STRUT_LEFT_END_Y] = alloc->y + alloc->height - 1; + } It didn't work as well as I hoped, because the panel doesn't seem to correctly set the STRUT when shifting from horiz to deskbar/vertical. What needs to be done to fix these annoying bugs? cheers Paul
(In reply to harris.pc from comment #18) > I am reporting a hopefully related issue: > 3 monitors side-by-side, What exactly is your X setup? [ Xinerama | NVidia TwinView | Zaphod ] etc. ...
I am not actually sure, since I didn't have to do the usual days of fiddling with xorg.conf like I used to do. I have nVidia, but I don't think TwinView is enabled (no mention in conf files or anywhere else). xrandr / xfce-display does all the screen configuration... no Xinerama or TwinView is mentioned in xorg.log, and until now I hadn't heard about Zaphod mode... how would I determine the answer?
(In reply to harris.pc from comment #20) > since I didn't have to do the usual days of fiddling with xorg.conf > xrandr / xfce-display does all the screen configuration... ... then with a probability of 99% your distro (?) creates a xinerama setup > and until now I hadn't heard about Zaphod mode... ... then with a probability of 99,9999% this bug is _not_ about your setup. Please re-read Comment 0 and the information in the referenced Bug 10669. Above all, understand the difference between . . . one big (X11) screen, composted with 3 monitors (Xinerama / xrandr) and . . . three seperate (X11) screens, one monitor each (Zaphod mode). AFAIK, the latter can only be achieved manually by a hand-crafted X setup and will not be generated by any of the current distro standard setups; esp. not via "xrandr / xfce-display" .
Ok, so I should post this as a new bug, or try and find an existing bug to comment on. Any bug# suggestions? Thanks, Paul
-- 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/xfce4-panel/-/issues/138. 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