xdotool appears to still account for menu when menu is not attached to window about xdotool HOT 2 CLOSED

I don't think xdotool is even aware. Relative movements are trickier these days with so many 'desktop extents' windows in use (like top-level toolbars)

Here's what happens, I think:

• xdotool asks the window for it's position, gets the real screen coordinate
• xdotool adds zero (per your request) to the Y value
• xdotool sends a movewindow request
• window manager intercepts, sees Y value, knows that there's a top-level bar, and replaces Y with Y+N where N is the height of the toolbar
• The window moves down by N pixels despite your request to stay in the same place.

You shoudl see the same behavior with absolute window movement:

pork(~) % xdotool windowmove $WINDOWID 0 0
pork(~) % xwininfo -id $WINDOWID | grep 'Absolute upper'                                           
  Absolute upper-left X:  1
  Absolute upper-left Y:  64

There are ways to query the 'desktop extents' but I haven't added support for it yet in xdotool.

from xdotool.

After I posted that I went browsing through the source (procrastination) and came to roughly the same conclusion.I'll experiment some more, but it seems like one solution would be to figure out the "WM root" and use it as the root instead of the underlying root. Can see how that would be tricky unless open desktop has some standard for it. Meanwhile my hack is to just put a steady -22 offset. From what you are describing it must be the panel height not the menu per se (which is, of course, the same height).

from xdotool.