LibreOffice dockable panels can't be docked under kwin. When you try to perform the dock, by dragging them to the edge of the (maximized) window, kwin interprets it as if the user wants to maximize the panel window, and does so. No docking inside LibreOffice is possible. I don't know who is to blame for this wrong behaviour, if kwin or LibreOffice. A bug is already filled for the latter at: https://bugs.freedesktop.org/show_bug.cgi?id=64438 Reproducible: Always Steps to Reproduce: 1. Open LibreOffice and maximize it 2. Push F11 to show format and styles panel. 3. Try to dock this panel to the right side of the window, by dragging it to the edge. Actual Results: The panel will be vertically maximized and placed to the right of the screen, as if it's regular window. Expected Results: The panel should be docked inside LibreOffice window.
That's a problem in LibreOffice. There is no window type for "I'm a dock window and want to be handled differently when moved". I don't know what LibreOffice is trying to do there (I'm not using it) but that sounds like they try plying window manager. That's their fault if it doesn't work and that doesn't sound future proof. Such approaches cannot work with Wayland.
You'll get similar problems when allowing to drag windows across virtual desktops (and have one adjacent on that edge) - it's simply a usage conflict (the input edge covers the LO window which would however likely only react when entering the covered region) Can you please attach the output of "xprop > lodock.props" and "xwininfo > lodock.info" for such LO "dock"? (The cursor turns into a cross and if you then click the window, it will print a lot of text into those two files)
Created attachment 80375 [details] xprop info
Created attachment 80376 [details] xwininfo info
That's twice the xwinifo output ;-) It's a managed window, but the props are more important.
Created attachment 80422 [details] xprop output
Created attachment 80423 [details] xprop output
Sorry, my fault. Now it seems I've uploaded the attachment twice, but at least they're both uploaded... :-P
Interesting, how is it dragged into the mainwindow? It's decorated, so you'll likely drag it by the titlebar, but we won't (with compositing) generate a configure event for every move but only when releasing it - so the window will have to poll it's position? But if it polled it's position, it would be unaffected by the screen borders. Can you run "kcmshell4 kwinscreenedges" and alter the settings: - deactivate the quick tiling (aero snap stuff) - instead enable desktop switching * only when moving windows * always in "kcmshell4 desktop" ensure there's more than one window column, so that for "always" touching the left or right screen edge will actually take you to the next desktop
That's weird, if I disable quick tiling the toolbar window is no longer maximized when dragged to the border, but it's neither docked by LibreOffice to its main window. Hence, I thought it was all resolved and it definitely was an issue with LibreOffice, but I've started a Gnome session and it works ok there. Fortunately, dockings performed under Gnome are remembered when user's back in KDE, so this issue is manageable. So, it seems like, as Martin says, LibreOffice is managing its windows in some weird way. Let's see if they acknowledge the issue (there's a bug already filled there) in upcoming versions.
(In reply to comment #10) > That's weird, if I disable quick tiling the toolbar window is no longer > maximized when dragged to the border, but it's neither docked by LibreOffice > to its main window. Hence, I thought it was all resolved and it definitely > was an issue with LibreOffice Yesno, the screen edge will still be covered by some invisible input interceptor *esp* when you've multiple desktops and allow crossing them by getting to mouse to the screen edge, but also by any other assigned action. Alternatively an autohiding panel will use a similar invisible input window, turning back to my question: how do you move that "dock" window? By drigging it at the titlebar as any ordinary window? And last but not least: compositing KWin does no longer tell the X11 server about every pixel you move as that's pretty expensive and rather superfluous (except when the window takes that to trigger some action) LO will have to use a more robust way to detect the embedding approach, to know which it's important to understand how you interact with that window in the first place (eg. have a look at QDockWidget for a robus and working implementation)
Yes, I move the window by dragging the titlebar. When it's not docked, it's shown as a regular window (minimize, maximize, close buttons, even system menu). When the window is moved to left/right edge, it disappears, and gets docked inside LO main window.
@Jesús: I just found a workaround: 1. Move the navigator/styles window to the edge of the LO main window 2. Resize the navigator/styles window with the mouse (grab it at the title bar) => the drop area will appear when the mouse is at the right position See also attachment.
Created attachment 82129 [details] workaround
Ok, given the workaround, I guess there's also no problem when you suspend compositing? (Shift+Alt+F12 - the shortcut toggles compositing)
No, suspending compositing is not enough to bring back the old behaviour. Nonetheless, the workaround still works.
You're right Nico, it works this way. It's quite tricky, though, but it's definitely easier than using xfce or something like that just to dock the window. (In reply to comment #13) > @Jesús: I just found a workaround: > > 1. Move the navigator/styles window to the edge of the LO main window > 2. Resize the navigator/styles window with the mouse (grab it at the title > bar) > => the drop area will appear when the mouse is at the right position > > See also attachment.
Installed LO 4.1.1 The window is (still) of utility type and there're two basic issues here: a) With compositing active, kwin doesn't XMoveResize the window while moved and LO will *never* offer you to dock the window when moving it to the edge - simply because LO doesn't notice the window is moved there. b) Without compositing, but quick tiling enabled, i get both - quick tiling as well as docking the utility offered/hinted (latter first). Releasing the move causes docking to take precedence here (ie. the window is docked and since that means it's gone, it's naturally not quick tiled) LO seems to take the window geometry as trigger to check the mouse position. (a) *could* likely be dealt by periodically actually performing an XMoveResize (despite compositing) but given that (b) * is confusing but apparently no actual (functional) problem * "only" affects maximized LO windows i would not say we should just block quick tiling for utility windows. (placing them in the corners may be desired) @Martin Ultimately and regarding the similar issues with windowmaker (and perhaps other compositing WMs not causing XMoveResize's) LO should offer the internal drag functionality (as present for the docked window) also for the undocked window. Until then, should we perform like every 50th move event directly?
> @Martin > Ultimately and regarding the similar issues with windowmaker (and perhaps > other compositing WMs not causing XMoveResize's) LO should offer the > internal drag functionality (as present for the docked window) also for the > undocked window. Until then, should we perform like every 50th move event > directly? I don't think we should penalize all applications for the sake of LO's behavior. Also the behavior cannot work in a Wayland world. The implementation in LO is just broken because they work on assumptions which were already outdated when introduced. <completely offtopic funfact>I just uninstalled LO to get enough free disk space to run an update</funfact>