libreoffice

[sg3des]

1) State rules floating,tiled etc given with bspc rule -a libreoffice-writer state=tiled not work properly. If this not specify libreoffice starts in floating state(should be tiled!), if specified rule, only first window of libre starts how tiled state, next windows floating... 2) On resize\move multiple libreoffice windows on multimonitor it jump from second monitor to first! with trying to return it, i got crash of xorg.

dmesg:

bspwm[568]: segfault at 40 ip 0000000000407d29 sp 00007fff963fa798 error 4 in bspwm[400000+27000]

journal:

systemd-coredump[12779]: Process 568 (bspwm) of user 1000 dumped core.

                                               Stack trace of thread 568:
                                               #0  0x0000000000407d29 n/a (bspwm)
                                               #1  0x000000000041e3de n/a (bspwm)
                                               #2  0x000000000040be2e n/a (bspwm)
                                               #3  0x000000000040f7ee n/a (bspwm)
                                               #4  0x0000000000404190 n/a (bspwm)
                                               #5  0x00007f9f9a57643a __libc_start_main (libc.so.6)
                                               #6  0x000000000040448a n/a (bspwm)

bspwm version: 0.9.2-49-gfff172e system: 4.11.3-1-ARCH x86_64 GNU/Linux

[noctuid]

Why is libreoffice floated in the first place? This started happening for me a while back for a lot of applications (e.g. emacs and zathura as well). Edit: Seems like the reason is the same as #551.

bspc rule -a libreoffice state=tiled and previously bspc rule -a '*:libreoffice-writer' state=tiled always work for me. However, I can't get libreoffice impress to ever be tiled even with the first rule or bspc rule -a '*:libreoffice-impress' state=tiled.

[ninrod]

I don't even have this libreoffice-writer command available. only libreoffice. I find it strange that people mention these libreoffice-* commands.

[noctuid]

libreoffice-writer is not the command name, but it's under WM_CLASS in the output ofxprop. Bspwm uses class/instance names for rules.

[danielnachun]

I was having the exact same problem and some i3 users on reddit found a solution that worked for me in bspwm.

A recent update to LibreOffice 5 seems to cause WM_CLASS to start as Soffice and then change to libreoffice-writer (or calc, impress, etc.) after the window has already been created. This is very confusing because when you try to use xprop to get WM_CLASS, you'll see the libreoffice-* value even though that isn't the value when the application starts. So I had to use the rule bspc rule -a Soffice state=tiled to get LibreOffice windows to tile automatically.

Since this appears to be a relatively new behavior, I suspect that users running LibreOffice 4 or even older versions of LibreOffice 5 don't have this issue, making it difficult to reproduce. I don't know of an easy way to monitor a property like WM_CLASS to check for behavior like this, but I also haven't seen any other application change its window class after starting. It may even be a bug with LibreOffice that will eventually be fixed.

[msteen]

@mistachie777 I do not seem to have that version of LibreOffice 5 yet so I cannot test it for you, but should you not be able to do something like check for the class Soffice, or whatever its instance name is, in your external rules and then monitor the WM_CLASS property via xprop -id <window_id> -spy WM_CLASS?

[danielnachun]

That was a good suggestion to use the external rules to capture the windows class as soon as the window appears. I actually realized that the second argument to the external rules command is the window class, so adding echo $2 >> /tmp/wm_class the external rules allows me to log the window class as bspwm sees it. If I monitor this file with tail -f and open any document in LibreOffice, I can see that the class is indeed Soffice, but if I use xprop WM_CLASS on the same window after it has appeared, it is changed to libreoffice-writer or the other appropriate application.

However, if LibreOffice is launched without any document specified, it starts with the correct libreoffice-* class that does not change. So it seems the change in window class only happens if LibreOffice is launched a certain way (albeit one that is commonly used). It's hard to know if this is a bug in LibreOffice that will eventually be fixed, or just some quirk of how the program works. It's also not clear why LibreOffice is sending WM hints telling bspwm to float its windows.

There is also another issue (https://github.com/baskerville/bspwm/issues/671) that sounds like it's caused by the same problem, so we may also want to reference this solution over there.

[icf20]

@mistachie777 bspc rule -a libreoffice state=tiled works only if u launch the app from rofi or terminal

to test make libreoffice --calc and then libreoffice --calc some_file_that_you_have.ods

[dannycolin]

@baskerville Wouldn't it be possible (to add support) to detect _NET_WM_WINDOW_TYPE. That way we could have a bspc config to force tiling every _NET_WM_WINDOW_TYPE_NORMAL.

[baskerville]

@dannycolin You can already do that in the external rules command: [ "$(xwinfo -t $1)" = "normal" ] && echo "state=tiled".

[danielnachun]

I think I've identified the root cause of this problem and it actually has to do with the splash screen for LibreOffice. I added echo $(xwinfo -c $1) $(xwinfo -t $1) >> /tmp/wm_type to my external rules and then monitored that temp file using tail -f as described before. When I open a document directly with LibreOffice, I can see that a window with class Soffice and type splash is created first, then another window of class Soffice and type normal is created. This is puzzling because I had disabled the splash screen in /etc/libreoffice/sofficerc. But I guess that all that does is replace the splash screen with a blank window.

It appears that the splash screen correctly sends hints for it to be floated (even if it's 'disabled') but then the subsequent window doesn't send hints that would cause it to be tiled. Re-enabling the splash screen doesn't make a difference.

The external rule suggested by @baskerville fixes the problem. It is also a better solution than using bspc rule -a Soffice state=tiled which tiles all LibreOffice windows, including dialogs which most people would probably want to float.

I also suspect that the reason this changed suddenly in LibreOffice 5, and persists in LibreOffice 6, is because the quickstarter was deprecated in LibreOffice 5.4 and removed in LibreOffice 6: https://wiki.documentfoundation.org/ReleaseNotes/5.4#General_2. I believe that running the quickstarter stopped the creation of a splash window since the program was already running. And perhaps the splash screen behavior was different even without using the quickstarter.

[dannycolin]

@baskerville thanks.

Sidenote

For anyone new to bspwm like me, do not confuse xwinfo with xwininfo :).