Bug 320849 - Libreoffice dockable panels aren't dockable
Summary: Libreoffice dockable panels aren't dockable
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: 4.10.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-07 06:27 UTC by Jesús Jiménez
Modified: 2014-02-05 12:19 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
xprop info (714 bytes, text/plain)
2013-06-07 12:41 UTC, Jesús Jiménez
Details
xwininfo info (714 bytes, text/plain)
2013-06-07 12:42 UTC, Jesús Jiménez
Details
xprop output (1.50 KB, text/plain)
2013-06-10 11:14 UTC, Jesús Jiménez
Details
xprop output (1.50 KB, text/plain)
2013-06-10 11:15 UTC, Jesús Jiménez
Details
workaround (33.94 KB, image/png)
2013-09-03 11:11 UTC, Nico Dorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesús Jiménez 2013-06-07 06:27:47 UTC
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.
Comment 1 Martin Flöser 2013-06-07 12:32:52 UTC
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.
Comment 2 Thomas Lübking 2013-06-07 12:35:38 UTC
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)
Comment 3 Jesús Jiménez 2013-06-07 12:41:39 UTC
Created attachment 80375 [details]
xprop info
Comment 4 Jesús Jiménez 2013-06-07 12:42:12 UTC
Created attachment 80376 [details]
xwininfo info
Comment 5 Thomas Lübking 2013-06-07 12:51:48 UTC
That's twice the xwinifo output ;-)

It's a managed window, but the props are more important.
Comment 6 Jesús Jiménez 2013-06-10 11:14:44 UTC
Created attachment 80422 [details]
xprop output
Comment 7 Jesús Jiménez 2013-06-10 11:15:53 UTC
Created attachment 80423 [details]
xprop output
Comment 8 Jesús Jiménez 2013-06-10 11:18:40 UTC
Sorry, my fault. Now it seems I've uploaded the attachment twice, but at least they're both uploaded... :-P
Comment 9 Thomas Lübking 2013-06-10 13:46:45 UTC
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
Comment 10 Jesús Jiménez 2013-06-11 09:54:45 UTC
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.
Comment 11 Thomas Lübking 2013-06-11 11:07:19 UTC
(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)
Comment 12 Jesús Jiménez 2013-06-11 11:42:53 UTC
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.
Comment 13 Nico Dorn 2013-09-03 11:10:21 UTC
@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.
Comment 14 Nico Dorn 2013-09-03 11:11:10 UTC
Created attachment 82129 [details]
workaround
Comment 15 Thomas Lübking 2013-09-03 20:20:04 UTC
Ok, given the workaround, I guess there's also no problem when you suspend compositing? (Shift+Alt+F12 - the shortcut toggles compositing)
Comment 16 Nico Dorn 2013-09-03 22:28:06 UTC
No, suspending compositing is not enough to bring back the old behaviour. Nonetheless, the workaround still works.
Comment 17 Jesús Jiménez 2013-10-01 08:55:39 UTC
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.
Comment 18 Thomas Lübking 2013-10-01 17:32:49 UTC
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?
Comment 19 Martin Flöser 2013-10-01 19:21:08 UTC
> @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>