[desktop] background shifted with panel

[IgnorantGuru]

Received elsewhere:

I've noticed a small bug in SpaceFM desktop related to panels. If desktop handler is launched after the panel, then it shifts position and does not cover area behind the panel. It affects background placement: SpaceFM does not stretch background image under the panel inside own window, but it fills root window correctly.

I'm using semi-transparent tint2, screenshot attached. You can notice that image edge is doubled under the panel, because SpaceFM window is shifted. Icons offset is double-shifted. The correct screenshot was taken when spacefm launched before the panel.

SpaceFM should ensure that desktop window always covers entire screen.

Screenshots desktop_with_panel_correct.png desktop_with_panel_shifted.png

[IgnorantGuru]

I think I see the shift you mean when using spacefm gtk3, but not with gtk2. The difference is likely somewhere near here, perhaps due to a lack of parent_relative in the gtk3 equivalent of gtk2's gdk_window_set_back_pixmap. Will ask BwackNinja to take a look at this.

[IgnorantGuru]

Also, this report indicates this may affect gtk2 also? (Or is that no longer the case with the current version?)

[IgnorantGuru]

From original reporter:

I'm building standard debian package from master and next, therefore it is a gtk2 build.

[IgnorantGuru]

The functions used to get the working area, which is used for the desktop window size, are here. In f59b0b6 in the temporary 'workarea' branch, I have changed it so it uses the full screen size rather than the working area detection code (which was taken from the Gaim Guifications plugin by Gary Kramlich in the legacy PCManFM code, and modified by PCMan).

Testing with lxpanel, with this change the desktop window does go beneath the panel, but in the lxpanel case, it seems to show the root window beneath the panel, rather than the desktop window. Thus there is still a discontinuity in the wallpaper appearance. But this may not be the case with true transparency.

You can test that change by using the BUILD NEXT instructions in README, substituting branch name 'workarea' for 'next' in those instructions.

My concerns about making this change: 1) Why was the working area code used for this instead of the screen size? Are there some setups where using the entire screen size will be a problem? eg issue #40

2) With this change, icons are drawn in the desktop window without consideration for the size or location of panels, etc. This may mean additional margins are needed, or perhaps SpaceFM could draw icons in the working area as defined by Kramlich's code, but use the full screen size for the overall window size.

Does the 'workarea' branch work the way you want?

[IgnorantGuru]

It turns out the desktop window is indeed the full screen size, and the Kramlich working area only affected icon layout. The shift appears to be caused by some component placing the window at 0,12 rather than 0,0 (I don't know where the 12 came from as my panel height at the top of the screen is 25).

In 82119e0 I explicitly move the desktop window to 0,0, which seems to correct the issue, at least as seen in lxpanel without true transparency. And some additional debug info was added temporarily to stdout on window placement and size.

I also added a call to update the wallpaper when the root window _NET_WORKAREA atom changes. This should cause the wallpaper to resize when the screen is resized while spacefm is running.

These changes are now merged into next ('workarea' branch is deleted). Please test.

[IgnorantGuru]

Received elsewhere:

Desktop is no longer shifted, icons behave correctly with and without panel. But SpaceFM window is still not being resized on resolution change.

$ spacefm --desktop
on_size_request  0x9e2e000  w,h=1366, 768
on_size_allocate  0x9e2e000  x,y=0, 0    w,h=1366, 768
on_size_request  0x9e2e000  w,h=1366, 768
on_size_allocate  0x9e2e000  x,y=0, 0    w,h=1366, 768
on_configure_event 0x9e2e000  x,y=33, 0    w,h=1366, 768  file_listed = 
FALSE
on_configure_event 0x9e2e000  x,y=0, 0    w,h=1366, 768  file_listed = FALSE
on_configure_event 0x9e2e000  x,y=0, 0    w,h=1366, 768  file_listed = FALSE
# switched to big screen, (but SpaceFM window is still small):
working area is resized   x,y=0, 0   w,h=1920, 1200
working area is resized   x,y=33, 0   w,h=1887, 1200
working area is resized   x,y=33, 0   w,h=1887, 1200
# killed and restarted panel:
working area is resized   x,y=0, 0   w,h=1920, 1200
working area is resized   x,y=33, 0   w,h=1887, 1200

[IgnorantGuru]

Received elsewhere:

It seems to detect change correctly, but uses old data for window resize.

on_size_request 0x8813000 w,h=1920, 1200 ...

switching to small screen

working area is resized x,y=0, 0 w,h=1366, 768 screen size w,h=1920, 1200

That means the working area was resized, but gdk is still reporting the screen size as 1920x1200. So apparently whatever you're using to resize is only changing the working area.

Previously you requested "SpaceFM should ensure that desktop window always covers entire screen". Yet in this case you seem to want the desktop window resized to the working area. I honestly don't know if this is a good idea or not, but I suppose we can try it. Normally the working area size doesn't change so it shouldn't impact most users.

However, the wallpaper on the root window is sized to the screen, not the working area, so this will likely cause another shift.

You can test this change in next (f2e894f). Also will now report both the wa and screen size on startup on_configure_event.

This seems be related to issue #40 in some ways. I don't know that a simple desktop manager such as SpaceFM will handle these working area dynamics well without significant redesign. I'm concerned that even if this change works for you, it may break other setups, but we can see.

[Vladimir-csp]

Well, finaly I am here...

That means the working area was resized, but gdk is still reporting the screen size as 1920x1200. So apparently whatever you're using to resize is only changing the working area.

I use xrandr. Basically: xrandr --output LVDS1 --off --output HDMI1 --auto --dpi 96 xrandr --output HDMI1 --off --output LVDS1 --auto --dpi 96 That's it. I also made wmctrl -d output to show screen size and working area. Maybe wa change comes first, and screen size check is triggered too soon?

[Vladimir-csp]

Same thing happens when just resolution changes. You can test it by changing resolution with xrandr, no need for another display.

[IgnorantGuru]

Okay thanks for signing up for github.

I don't know if xandr changes the actual screen size or just messes with working areas -would be good to know.

I also made wmctrl -d output to show screen size and working area.

It also shows the screen size not changing?

Maybe wa change comes first, and screen size check is triggered too soon?

You could try killing spacefm and restarting it, and see what it sets the desktop window to (initial size will equal screen size). Maybe detection of screen size change is needed rather than just wa.

At any rate, does f2e894f resize the desktop window as needed? And was there a wallpaper shift beneath the panel?

[Vladimir-csp]

I don't know if xandr changes the actual screen size or just messes with working areas -would be good to know.

xrandr has nothing to do with WA, it changes screens geometry. WA is a WM's thing. (somebody correct me if I'm wrong).

It also shows the screen size not changing?

wmctrl always shows everything correctly. These screenshots were taken after I switched from 1366x768 to 1920x1200.

Freshly started spacefm always detects screen size correctly... For desktop window size and position - the only thing that matters is screen size. WA is only relevant in context of icon placement margins.

[IgnorantGuru]

In 6c25f4a I added a detection of gdk screen size change. Not sure if that will report the new or old size, but it should tell us if the size is changing as far as gdk knows.

So does the latest next work as you expect in terms of resizing the desktop window, etc, when you resize your screen with xrandr? Even though the resize is based on the WA, it equals the screen size change in this case, so it should tell us if the method is working.

[Vladimir-csp]

Here is the sequence:

1. reduce resolution with xrandr
2. run wmctrl -d
3. run spacefm --desktop
4. increase resolution with xrandr
5. run wmctrl -d The result is on the screenshot.

[IgnorantGuru]

Here is the sequence:

Thanks but if I need to modify my displays and software setup to test this it will go back on a TODO list. The reason I'm spending this time on it is because you're testing for me, and it would be nice to accommodate. But it's not a high priority item - most users don't change the screen size dynamically, and SpaceFM is intended as a simple DM. For more complex setups I recommend a more robust DM.

I think we're almost there but you've stopped answering my questions. With the latest next, I'd like to see the terminal output as you change screen size with xrandr - no screenshot required. And is the desktop window resizing as expected?

If the gdk screen size is detected, and next is resizing the desktop okay, then I can base the resize on the screen size change event and it should be finished.

[Vladimir-csp]

All answers are on the screenshot: It is of latest next. Terminal output of spacefm is on the right. Resolution was changed from 1280x960 to 1920x1200 while spacefm was running. And you can see that desktop window is still 1280x960, while screenshot (and screen) size is 1920x1200.

here is the same output in text:

$ spacefm --desktop
added desktop window 0x8f22000 to screen 0 on display 0x8e9f0b0 (:0)
on_size_request  0x8f22000  w,h=1280, 960
on_size_allocate  0x8f22000  x,y=0, 0    w,h=1280, 960
on_size_request  0x8f22000  w,h=1280, 960
on_size_allocate  0x8f22000  x,y=0, 0    w,h=1280, 960
on_configure_event 0x8f22000  x,y=33, 0    w,h=1280, 960  file_listed = FALSE
    working area is   x,y=33, 0   w,h=1247, 960
on_configure_event 0x8f22000  x,y=0, 0    w,h=1280, 960  file_listed = FALSE
    working area is   x,y=33, 0   w,h=1247, 960
on_configure_event 0x8f22000  x,y=0, 0    w,h=1280, 960  file_listed = FALSE
    working area is   x,y=33, 0   w,h=1247, 960
working area is resized   x,y=0, 0   w,h=1920, 1200
    screen size   w,h=1280, 960
working area is resized   x,y=33, 0   w,h=1887, 1200
    screen size   w,h=1280, 960
working area is resized   x,y=33, 0   w,h=1887, 1200
    screen size   w,h=1280, 960
on_configure_event 0x8f22000  x,y=0, 0    w,h=1280, 960  file_listed = TRUE
    working area is   x,y=33, 0   w,h=1887, 1200
    get_working_area
on_configure_event 0x8f22000  x,y=0, 0    w,h=1280, 960  file_listed = TRUE
    working area is   x,y=33, 0   w,h=1887, 1200
    get_working_area
on_configure_event 0x8f22000  x,y=0, 0    w,h=1280, 960  file_listed = TRUE
    working area is   x,y=33, 0   w,h=1887, 1200
    get_working_area
on_size_request  0x8f22000  w,h=1280, 960
on_size_allocate  0x8f22000  x,y=0, 0    w,h=1280, 960
MISS 0x8f628d8  dist = 56,222771

[Vladimir-csp]

Oh, now I see that spacefm output has correct numbers for screen and WA, but the window does not resize.

[IgnorantGuru]

Okay, thanks for all the testing Vladimir! Now you know what a pain development is. ;) Nothing is ever simple. I thought this would be more trivial, but I'll need to create a test setup myself to find out what's going on.

fyi the latest terminal output you're showing doesn't include "screen size changed ...", which indicates the gdk event for screen size change is not happening (or you're not running the latest next). And apparently merely resizing the desktop window isn't sufficient.

I'm closing this issue (actually topic was panel shift, but OT was my fault), and have opened a new request on the resizing in issue #300 - please subscribe to that issue and add any further comments on it there (you and others). We made a lot of progress here for when I do have a chance to dig into it. Also, be advised I will be removing some of the code just added in next, but you can always build from the older commits via github if you want to test further.

Also, if the panel shift isn't corrected for anyone, you can add a comment below even though this issue is closed.