Using panel from xubuntu staging 4.11.2~git20141207.d121c00-0ubuntu1~15.04 With panel at the bottom, maximising a window hides the panel. Rolling up to the title bar - panel stays hidden - would expect panel to show when window rolled up.
@Olivier: Is it possible that clientShade in xfwm4's client.c doesn't update the window's size for a shaded window? This is how the panel tries to determine whether the currently active window overlaps: http://git.xfce.org/xfce/xfce4-panel/tree/panel/panel-window.c#n2170
(In reply to Simon Steinbeiss from comment #1) > @Olivier: Is it possible that clientShade in xfwm4's client.c doesn't update > the window's size for a shaded window? > > This is how the panel tries to determine whether the currently active window > overlaps: > http://git.xfce.org/xfce/xfce4-panel/tree/panel/panel-window.c#n2170 Client window size does not change on shading, that's on purpose.
@Olivier: Thanks for clarifying! I guess there is no "clean" fix for this then. I could add a check for whether the window is shaded and in that case estimate/calculate the size of the shaded window and check whether it's overlapping... @Andrzejr: Any better ideas?
You cannot use the geometry of the client to determine whether it's shaded/iconified. Playing with xwininfo gives some hints: Normal, mapped state: xwininfo: Window id: 0x4e0000a "xclock" Absolute upper-left X: 415 Absolute upper-left Y: 218 Relative upper-left X: 3 Relative upper-left Y: 29 Width: 164 Height: 164 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +415+218 -1725+218 -1725-642 +415-642 -geometry 164x164+412+189 Shaded: xwininfo: Window id: 0x4e0000a "xclock" Absolute upper-left X: 415 Absolute upper-left Y: 218 Relative upper-left X: 3 Relative upper-left Y: 29 Width: 164 Height: 164 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsUnMapped Override Redirect State: no Corners: +415+218 -1725+218 -1725-642 +415-642 -geometry 164x164+412+189 Iconified: xwininfo: Window id: 0x4e0000a "xclock" Absolute upper-left X: 415 Absolute upper-left Y: 218 Relative upper-left X: 3 Relative upper-left Y: 29 Width: 164 Height: 164 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsUnMapped Override Redirect State: no Corners: +415+218 -1725+218 -1725-642 +415-642 -geometry 164x164+412+189 *but* you can use NET_WM_STATE which gives a pretty accurate idea of the current status of the window: Normal: $ xprop -id 0x4e0000a _NET_WM_STATE _NET_WM_STATE(ATOM) = Shaded: $ xprop -id 0x4e0000a _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_SHADED Iconified: $ xprop -id 0x4e0000a _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Shaded and iconified: $ xprop -id 0x4e0000a _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_SHADED, _NET_WM_STATE_HIDDEN etc.
I was actually thinking of using the NET_WM_STATE to check for shaded, but the part I wasn't/am still not sure about is how to get the size of the shaded window, i.e. of the decoration. I guess 90% of the time when you shade a window, you actually want the panel to show up. Then again, in some cases, you might accidentally trigger shade and then having a panel obstruct access to the window might suck (although alt-tab would bring it back). Any thoughts on that?
On further consideration, I reckon best is to use NET_FRAME_EXTENTS along with NET_WM_STATE. NET_FRAME_EXTENTS[1] won't give you the actual size/position of the frame, but it will allow you to compute it based on the client size/position and state. [1] http://standards.freedesktop.org/wm-spec/wm-spec-1.5.html#idm140200472552416
Created attachment 5816 Patch that takes into account shaded windows Ok guys, I've tried my best and the attached patch is the best I could come up with. The panel now additionally listens to window-states changing to take into account shaded windows (libwnck does all the heavy lifting there). In case a window is shaded, its window-height is calculated based on what the _NET_FRAME_EXTENTS return. Argument 2 and 3 are top and bottom, combined that gives you the height of the frame. The width remains the same, so only the height is overwritten. The patch works for me, but it needs review of someone more familiar with X than me (Olivier pleeease?). The general logic should hopefully be sound.
(In reply to Simon Steinbeiss from comment #7) > Created attachment 5816 > Patch that takes into account shaded windows > > [...] > The patch works for me, but it needs review of someone more familiar with X > than me (Olivier pleeease?). The general logic should hopefully be sound. + if (XGetWindowProperty (display, wnck_window_get_xid (active_window), + XInternAtom(display, "_NET_FRAME_EXTENTS", True), + 0, 4, FALSE, AnyPropertyType, + &real_type, &real_format, &items_read, &items_left, + (unsigned char **) &data) == Success && (items_read)) => make sure that (items_read >= 4) rather than just non-zero. Other than that, looks fine.
Created attachment 5819 Updated patch that takes into account shaded windows Thanks for your review, Olivier! I have updated the patch as requested and also added a comment to the window-shading part so that it'll hopefully be clearer to others reading it later.
@Andrzejr: On a related note, I realised that there is an unused and misspelled constant in panel-window.c. In case you wanna remove that part when pushing my patch (I didn't include it because I guess it makes sense as a separate commit), it's line 61: "#define DEFAULT_ATUOHIDE_SIZE (3)"
If I repetitively drag a shaded window on/off the panel I can cause it to crash: libpager-Message: Setting the pager rows returned false. Maybe the setting is not applied. Maximum number of clients reached Program received signal SIGSEGV, Segmentation fault. 0x00007ffff69bed1a in XInternAtom () from /usr/lib/x86_64-linux-gnu/libX11.so.6 (gdb) bt #0 0x00007ffff69bed1a in XInternAtom () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #1 0x0000000000429cdc in panel_window_active_window_geometry_changed (active_window=0x824460, window=0x6bc100) at panel-window.c:2192
@Andrzej: As I can't reproduce the segfault, could you attach a full backtrace please?
Created attachment 5830 Backtrace log Full backtrace attached. First line is a message printed to the console just before the crash.
As Peter pointed out on IRC, the patch contains an XOpenDisplay that is never closed, so that's the leak that likely caused your segfault. The other issue is that the patch won't work if users pass a "--display" parameter, because it always assumes it's 0.
Created attachment 5850 Updated (less leaky) patch that takes into account shaded windows The updated patch (only replaced XOpenDisplay with the corresponding gdk call) takes both problems, the segfault caused by the leak and the --display option, into account.
Pushed the patch. Thank you. One issue I've noticed is that window coordinates in the shaded mode are calculated incorrectly. When panel is at the bottom of the screen, I have to slide the whole shaded window behind it in order to make the panel disappear. I have also noticed an unrelated issue with shaded windows and tiling with xfwm: https://bugzilla.xfce.org/show_bug.cgi?id=11433
Created attachment 5852 Simplified version of previous patch for shaded windows Thanks for noticing the error in the height calculation (the coordinates were fine, the height wasn't). I have massively simplified the patch now by using (already cached, hence faster) libwnck calls instead of X calls.
Simon, Do you need further testing for this patch, or do you need someone to push an already tested patch for you? Thanks.
No, just another bug that was fixed with the bugreport remaining in limbo ;) Fixed in master: http://git.xfce.org/xfce/xfce4-panel/commit/?id=1cfbcde589ebd4f59296202296d9e9e42252b8c1