Download it now!
Bug 64438 - Dockable panels in LibreOffice not dockable using KDE
Summary: Dockable panels in LibreOffice not dockable using KDE
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 78861 (view as bug list)
Depends on:
Blocks: KDE Panel-Docking
  Show dependency treegraph
 
Reported: 2013-05-10 17:49 UTC by S.
Modified: 2020-07-16 05:42 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. 2013-05-10 17:49:34 UTC
Hi everyone,

I just upgraded to LibreOffice 4, and I decided to start with a new profile. I also recently switched to KDE. I discovered that dockable panels in LibreOffice (such as Styles and Formatting and the Navigator) are not dockable by dragging to the side of the screen when using KDE. I tried disabling the feature of dragging windows to the edge of the screen to tile or maximize in KDE, but it still doesn't work. I assume that this is an issue caused by KWin, and it's not technically a bug with LibreOffice. But it would be good for LibreOffice to offer a button or menu to dock those toolbars if it fails due to the window manager. It appears that Unity in Ubuntu also prevents docking in LibreOffice (https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/732631)

I never noticed this bug until now because I was using an old profile in which I had already docked the panels. So I don't know if/when this bug appeared in LibreOffice at a certain version.

As a workaround, I logged into IceWM and docked the panels and then logged back into KDE to use them. But if I wanted to dock/undock the panels depending on the workflow I would be out of luck.

Thanks for looking into this!
Operating System: Linux (Other)
Version: unspecified
Comment 1 Jesus Jimenez 2013-06-07 06:12:30 UTC Comment hidden (obsolete)
Comment 2 Jesus Jimenez 2013-06-07 06:15:12 UTC
I confirm this behaviour. (And sorry about the previous comment, keyboard mistake).
Comment 3 Yury 2013-06-22 20:59:04 UTC
I cannot dock neither Navigator nor Styles for a long time (half a year? a year?) using in 3.* series on Linux. The principal WM here is WindowMaker (0.95.* series), but I tried with the blackbox, fluxbox and twm, too.

And I definitely remember the time when those panes were dockable.
Comment 4 Mirosław Zalewski 2013-08-14 17:41:43 UTC
What version of KDE SC are you using?

I can not confirm it on Debian testing, amd64. KDE SC 4.8.4 and LO 4.0.4 (from Debian repository). Just a moment ago I had successfully docked Stylist window to right side of window.
Comment 5 Jesus Jimenez 2013-08-16 06:50:25 UTC
Doesn't work with KDE SC 4.10.5 and LO 4.0.2. Perhaps this bug started in some KWin version between 4.8 and 4.10?
Comment 6 Nico Dorn 2013-09-03 09:19:32 UTC
Confirmed Docking does not work on KDE 4.10.5 with LO 4.1.1.
Comment 7 Nico Dorn 2013-09-03 09:36:47 UTC
KDE claims, it's not their bug: https://bugs.kde.org/show_bug.cgi?id=320849
Comment 8 Nico Dorn 2013-09-03 10:58:01 UTC
Further investigations: works with LO 4.1.1 on KDE 4.9.5. So, the bug seems to be triggered by the changes in KWin that took place in KDE 4.10.

A workaround for all those using KDE 4.10 (this works at least for me):
1. Exit LO
2. Open the registrymodifications.xcu from the LO config directory
4. Search the line which contains oor:name="10366"
5. Change the value after oor:name="Data":
  "V2,H,128,AL:(16,5,0/0/270/240,270;762)" = navigator not docked
  "V2,V,128,AL:(4,16,0/0/270/240,270;762)" = navigator docked to the left
  "V2,V,128,AL:(5,16,0/0/270/240,270;762)" = navigator docked to the right
Comment 9 Nico Dorn 2013-09-03 11:13:29 UTC
Sorry for the spam!

I accidentally found a much easier workaround I posted here: https://bugs.kde.org/show_bug.cgi?id=320849#c13. That makes the bug less pressing.
Comment 10 Yury 2013-09-18 07:04:25 UTC
The workaround mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=64438#c9 is very neat but, unfortunately, specific to the KDE environment. I can't make this work on WindowMaker 0.95.5.

However, workaround in https://bugs.freedesktop.org/show_bug.cgi?id=64438#c8 works. Thanks!

To make things yet more happy: what is the node number for 'Stylist'? Can't find it by myself.
Comment 11 Yury 2013-09-18 09:06:15 UTC
I found it. The registry number for the "Styles and Formatting" is 5539, and the successful recipe (for those who have similar problem) is almost the same:

1) In registrymodifications.xcu, find the XML tag which mentions windowtype 5539 (I have two such tags in my registrymodifications.xcu).

2) Select those tag in which the value subtag starts similarly to "<value>V2,H,0,AL:(16,4,"

3.1) Change H to V
3.2) Change "16,4," to "4,16,"
3.3) Save the file

4) Start LibO

On recent WindowMaker you get Stylist docked to the left and active. Now you can switch it on and off by (default) keys sequence <F11>.

Thanks, Nico Dorn.
Comment 12 Thomas Lübking 2013-10-01 23:09:14 UTC
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
Comment 13 Yury 2013-10-11 07:58:10 UTC
An amazing exposé, Thomas, thank you very much for sharing.

I won't pretend I understood this, although I might guess this means currently LO depends on some sort of feedback from WM which it won't get from modern WMs codebase. Unless, e.g., in wmaker WM operator switches on "opaque" mode of windows moving.
Comment 14 Joel Madero 2014-08-08 03:34:43 UTC
*** Bug 78861 has been marked as a duplicate of this bug. ***
Comment 15 Cor Nouws 2015-01-03 20:05:08 UTC
This has been fixed in the mean time. Don't know when and how, so close as WorksForMe.
Comment 16 Jesus Jimenez 2015-01-08 10:10:29 UTC
(In reply to Cor Nouws from comment #15)
> This has been fixed in the mean time. Don't know when and how, so close as
> WorksForMe.

I don't see it as fixed, I'm still unable to dock styles panel to the right side of the window. I'm using KUbuntu 14.10, LO 4.3.3.2.
Comment 17 Dominik Kopp 2017-08-28 19:35:20 UTC
I agree with comment #16.
It's not possible to dock a dockable window (like navigation) under KDE.

I'm still using the SHIFT+ALT+F12 workaround (disable compositor)
Plasma: 5.10.4
LO: 5.4.0.3
Comment 18 Mihkel Tõnnov 2017-08-28 20:16:20 UTC
Yep, not solved, and affects also Elements panel in Math.
Another (basically permanent) workaround is to create a window rule to block compositing for LibreOffice's utility-type windows.

Mageia 5, KDE 4.14.30, LibO installed from TDF-provided RPMs.
Comment 19 Cor Nouws 2017-08-29 07:02:54 UTC
OK, removing Unity from summary - that just works.
Comment 20 QA Administrators 2018-12-14 03:56:07 UTC Comment hidden (obsolete)
Comment 21 Buovjaga 2019-01-01 18:35:21 UTC
Still not working with the new KDE5 backend.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 2c7b0030b40de00e8c9ab997bdfe83631861968a
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: kde5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 1 January 2019
Comment 22 kontakt 2020-04-30 10:30:05 UTC
Bug still exists, docking does not work for me either.

Running Manjaro (Arch) with  KDE Plasma 5.18.4.
Comment 23 Mihkel Tõnnov 2020-04-30 12:17:40 UTC
(In reply to Mihkel Tõnnov from comment #18)
> Yep, not solved, and affects also Elements panel in Math.
> Another (basically permanent) workaround is to create a window rule to block
> compositing for LibreOffice's utility-type windows.
> 
> Mageia 5, KDE 4.14.30, LibO installed from TDF-provided RPMs.

This workaround no longer works (for me?) on Arch with KDE Plasma 5.18.4 / Frameworks 5.69.
Comment 24 Michael Weghorn 2020-07-14 05:56:28 UTC
*** Bug 134704 has been marked as a duplicate of this bug. ***