GNOME Bugzilla – Bug 649315
can't get proper WM_CLASS association for LibreOffice
Last modified: 2011-09-28 18:09:36 UTC
gnome-shell-3.0.1-1.fc15.x86_64 libreoffice-core-3.3.2.2-6.fc15.x86_64 <notting> is there a plan to 'fix' the libreoffice icons? <cosimoc> notting, fix as in? <notting> cosimoc: they're being scaled badly at least in the task switcher <cosimoc> hrm, they look good here <owen> notting: is assoication working? notting: what d you see for the app icon? <cosimoc> notting, but if they look fine in Applications and not in alt-tab icons are not the issue usually <owen> notting: do you see the text you'd expect, or something weirdly capitalized with dashes? <cosimoc> it's the application that does not the right WM class <notting> owen: what looks to be a 32x32 (or 48x48, whatever) version of the correct icon, scaled up <owen> notting: i"M actually asking about the text notting: up by Activities <notting> owen: 'libreoffice-calc' <owen> notting: yeah, that's what I expected notting: and does /usr/share/applications/libreoffice-calc.desktop exist? <owen> (and do you have appications under Applications in the overview?) <notting> that desktop exists and i have 'LibreOffice Calc' in applications -> office <owen> notting: hmm, I'm puzzled notting: what is xprop | grep WM_CLASS ? <owen> notting: how did you get to this document? I'm wondering if there is some code path where LO isn't correctly setting the right WM_CLASS <notting> WM_CLASS(STRING) = "VCLSalFrame.DocumentWindow", "libreoffice-calc" WM_ICON_NAME(STRING) = "configtool.ods - LibreOffice Calc" owen: "ooffice <blah>" ran from the terminal, of course <owen> notting: the WM_CLASS looks fine really notting: what does the Windows tab sow? <owen> walters: my current guess is that libreofice changes WM_CLASS after mapping the window and we don't handle that correctly and are racy <notting> wmclass: libreoffice-calc, <untracked> <walters> owen: that looks to be the case indeed <walters> i'm not sure i'd call that our bug though <owen> walters: well, consiering the weird container nature of openoffice <walters> hmm <owen> walters: it may be heroic of them to get the WM_CLASS set correctly *at all* <walters> is this something where like it decides which app it is after it's already opened the document? <owen> walters: I'm guessing so walters: we can check with caolon of course, but if it's not too much work to handle it, we possible should <walters> notting: file a bug, i'll take a look <owen> notting: does it work better if you run libreoffice-calc <document> ? notting: and/or is it sometimes-work-sometimes-not ? <walters> owen: nope <notting> can't make it work, even running as 'oocalc' or /usr/lib64/libreoffice/program/scalc, even
Ideally, LibreOffice would set the correct WM_CLASS before even mapping a window. It would be nice to get a base "base" application on startup too. But if we want this to work, we need to monitor the WM_CLASS property and adapt to changes.
Note that if I open documents of multiple types, they're grouped under the icon/class of whatever the first one opened was. i.e., I open in succession a odt, odp, and ods file, I get three windows categorized under 'libreoffice-writer'.
Created attachment 187212 [details] [review] window: Add wm-class property and notify it when changed.
Created attachment 187213 [details] [review] shell-window-tracker: Work better at picking up changes in WM_CLASS This should help detect applications for windows that set their WM_CLASS after mapping.
Oh crap, sorry Jasper - I didn't see you'd already worked on this. Your mutter patch looks fine, but I think my gnome-shell one is better. In my testing we actually need to recalculate the focus-app.
Created attachment 188532 [details] [review] Track changes to WM_CLASS LibreOffice changes applications dynamically; we should support this.
Review of attachment 187212 [details] [review]: Looks fine.
Review of attachment 187212 [details] [review]: We're using Colin's patch in bug 651014
Attachment 188532 [details] pushed as d51e79d - Track changes to WM_CLASS
*** Bug 651014 has been marked as a duplicate of this bug. ***