! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfce4-panel 4.12.0 fails to correctly set _NET_WM_STRUT_PARTIAL
Status:
RESOLVED: MOVED
Product:
Xfce4-panel

Comments

Description Manfred.Knick 2015-10-28 17:09:08 CET
### 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.
Comment 1 Manfred.Knick 2015-12-20 14:16:39 CET
(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.
Comment 2 Manfred.Knick 2015-12-20 16:23:15 CET
I just cross-checked with the current git repositories 
( via layman ) ( https://cgit.gentoo.org/proj/xfce.git/ )
to no better avail.
Comment 3 Manfred.Knick 2015-12-20 16:44:14 CET
Cross-Reference:

. . . https://bugs.gentoo.org/show_bug.cgi?id=568880
Comment 4 Manfred.Knick 2015-12-21 11:49:43 CET
Created attachment 6563 
~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml

A minimalist panel config exposing the described behaviour
Comment 5 Manfred.Knick 2015-12-21 15:53:31 CET
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.
Comment 6 Manfred.Knick 2015-12-21 16:27:25 CET
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?
Comment 7 Manfred.Knick 2015-12-22 10:38:17 CET
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?
Comment 8 Manfred.Knick 2015-12-22 10:53:15 CET
"PANEL_DEBUG=struts startx /usr/bin/startxfce4 -- -layout Four"

gave no additional (struts) info lines.
Comment 9 Manfred.Knick 2015-12-22 15:41:55 CET
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.         <--- !!!
Comment 10 Manfred.Knick 2015-12-22 15:55:58 CET
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.
Comment 11 Manfred.Knick 2015-12-22 16:07:34 CET
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;

  ...
Comment 12 Manfred.Knick 2015-12-22 16:13:55 CET
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 .
Comment 13 Manfred.Knick 2015-12-22 16:15:49 CET
Comment10 and Comment11
Comment 14 Manfred.Knick 2015-12-22 16:39:47 CET
# 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);
<
Comment 15 Manfred.Knick 2015-12-22 16:48:15 CET
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)
Comment 16 Manfred.Knick 2015-12-22 17:10:32 CET
Created attachment 6566 
/etc/portage/patches/xfce-base/xfce4-panel-4.12.0-r1/4.12.0-01-panel.patch
Comment 17 Manfred.Knick 2016-01-02 11:13:44 CET
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
Comment 18 harris.pc 2016-02-04 08:17:56 CET
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
Comment 19 Manfred.Knick 2016-02-04 11:32:34 CET
(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. ...
Comment 20 harris.pc 2016-02-04 13:02:15 CET
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?
Comment 21 Manfred.Knick 2016-02-05 14:10:23 CET
(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" .
Comment 22 harris.pc 2016-02-06 03:53:23 CET
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
Comment 23 Git Bot editbugs 2020-05-28 01:58:22 CEST
-- 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

Bug #12281

Reported by:
Manfred.Knick
Reported on: 2015-10-28
Last modified on: 2020-05-28

People

Assignee:
Nick Schermer
CC List:
1 user

Version

Version:
4.12.0

Attachments

Additional information