https://bugs.freedesktop.org/show_bug.cgi?id=64438

--- Comment #12 from Thomas Lübking <[email protected]> ---
Dealing only with the "doesn't work at all" part (disregarding "does not work
with maximized windows if there's an input window on the screen edge" - I
cannot reproduce this)



What LibreOffice apparently does:
---------------------------------
Intercept ConfigureNotify events to determine the current position of the
utility window and (likely) take that as trigger to check the cursor postion
(as the trigger seems more related to that than to the actual geometry)


Why this is problematic:
-------------------------
For a compositing windowmanager, there's no need to cause ConfigureNotify
events while moving a window - it's simply not required to actually call
XMoveWindow and cause the resulting roundtrips to visually reflect the position
change.


Why this is a LibreOffice problem:
----------------------------------
One could claim this to be a deviation of the particular
Windowmanager/Compositor but it is actually not.

Windowmanagers used to grab the server and draw a nice outline when moving a
window in order to avoid exposure events on sublying windows. (KWin removed
that option only about a year ago or so and got bug reports claiming it back -
for some "legacy" windowmanagers it's the only available mode and it's also at
least near to what LibreOffice does when undocking the window)
Only with backing stores in the servers and more capable systems, users more or
less reasonably demanded the -optional- overhead of oapque moves/resizes.

So, while indeed often seen by default on desktop environments, it has never
been a generally expectable behavior.


How to solve:
-------------
Next to explicit dock buttons, eg. QDockWidget or the Gimp docks all operate on
internal drag triggers, ie. hide the titlebar or ignore it for this (having
tabs instead)
If announced as supported by the WM, _NET_WM_MOVERESIZE[1] should be the
preferred way to do this, but whether operating by "traditional" drag & drop,
client side implemented window movement or mentioned client message to the WM
(and subsequent cursor polling) is up to the client.
There's however -so far- no protocol in place to let the client know that the
window is now being moved by the user - let alone "where".


[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html, available
since v1.1


@Yuri:
WindowMaker has an option for opaque moves/resizes. Enabling opaque movements
should allow you to dock the LO utility windows, trie with LO 4.1.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to