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)
Enter your zip code here
I confirm this behaviour. (And sorry about the previous comment, keyboard mistake).
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.
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.
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?
Confirmed Docking does not work on KDE 4.10.5 with LO 4.1.1.
KDE claims, it's not their bug: https://bugs.kde.org/show_bug.cgi?id=320849
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
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.
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.
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.
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 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".
 http://standards.freedesktop.org/wm-spec/wm-spec-latest.html, available since v1.1
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
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.
*** Bug 78861 has been marked as a duplicate of this bug. ***
This has been fixed in the mean time. Don't know when and how, so close as WorksForMe.
(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
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 188.8.131.52.
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)
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.
OK, removing Unity from summary - that just works.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still not working with the new KDE5 backend.
Arch Linux 64-bit
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
Built on 1 January 2019
Bug still exists, docking does not work for me either.
Running Manjaro (Arch) with KDE Plasma 5.18.4.
(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.
*** Bug 134704 has been marked as a duplicate of this bug. ***
Bug still exists, but closing all documents and restarting LO fixes this.