Comment 25 for bug 886667

This issue seems to be a nux issue.

I don't know what the Nux BaseWindow is for, but it's the one that interfers with EWMH struts and causes this issue.

There are two functions:
- BaseWindow::BaseWindow(...)
- FloatingWindow::FloatingWindow(...)

that both set the geometry using
- SetGeometry(Geometry(100, 100, 320, 200));

when struts is enabled causing corruption of the struts.

In this case the sum of the two y-coordinates 100+200=300 forms the top margin height for the strut and is sporadically detected by Nautilus using that value (300) to calculate the size of the workarea to be used to draw the desktop icons. That's why my earlier proposed workaround patch in Nautilus. Furthermore, the slower the computer is the more frequent this issue seems to be.

I tested the geometry for the launcher to fit my screen resolution 1366x768, a panel heigth 24px and a launcher width incl padding of 17px, ie 32+17=49 by patching Nux BaseWindow.cpp:
- SetGeometry(Geometry(0, 24, 49, 744));

and the issue (this bug) is gone.

Conclusion:
This functions (BaseWindow, FloatingWindow,..) should not be active at login or if so, in any case never address the root window for the screen but always be prefixed by a window pointer.

Other concerns I have
------------------------------
The handling of the EWMH struts is improper meaning it does not cover all four struts but only one of them at a given time, ie either the panel or the launcher strut. Thus being violated!
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2578550

The Gnome session startup design rule is violated!
http://live.gnome.org/SessionManagement/NewGnomeSession

Here is says that the "Desktop" (phase 4 incl startup of Nautilus) must not be started until EWMH struts is complete. As both the "WindowManager" and "Panel" components for Unity is Compiz, Unity/Compiz has to handle that internally so the "Desktop" phase is not started up too early as happens now. A timer is not good enough, especially not for slow computers.