LibreOffice consists of several different applications, such as Writer, Impress and Calc. In a grouped task manager (such as the KDE Icon Tasks) they are distinguished from each other. Clicking on one of them in the task bar correctly displays an exposé of all the documents of that particular application. However, after choosing one of the documents, using the keyboard shortcut for "walk thourgh windows of current application" (Alt+` for me) produces strange and inconsistent results. .docx files are detected as separate from .odt, .doc and other file-types in Writer. If the active window is a .docx document, Alt+` would only switch between other .docx documents and not detect .odt or .doc documents. If on an .odt file, Alt+` would toggle between documents of all formats, except docx. This includes .doc and even .odp presentation files from Impress. This is very inconsistent and confusing. The way Icon Tasks groups the windows seems the most logical and perhaps should be adopted. Reproducible: Always Steps to Reproduce: 1. Open several documents in LibreOffice, including .docx, .odt and .odp. 2. Try and toggle between them with "walk thourgh windows of current application" keyboard shortcut Actual Results: There are two groups of toggling: -.docx files -All other files (.odt, .odp, etc.) Expected Results: Toggle based on particular application groups (same as task manager groups): -Writer documents (.doc, .odt, .docx) -Presentation documents (.ppt,.odp) Alternatively, just toggle between all LibreOffice windows. Tested with LibreOffice 4.2.4.2 and KDE 4.13.1.
can you please attach the output of "xprop" on either window (docx, od*) - $ xprop > docx.props The cursor turns into a '+', just click the window - the file docx.props will then containt the required infos for that window (make sure the window title does not include private data)
Created attachment 86988 [details] xprop output on odp file
Created attachment 86989 [details] xprop output on odt file
Created attachment 86990 [details] xprop output on docx file
hmmm.. they've same - class - pid - leader - virtual desktop - activity - state (normal) ==> they should seriously be in the same clientgroup. The only difference i spot is that docx is maximized and the others are not. Does that make a difference on your side? Is this a multisscreen setup?
It acts the same way whether maximized or not. I have a single screen.
can't say why, but indeed happens. will test tomorrow. need sleep.
Libreoffice alters the WM_CLASS for .odt (but not .docx) from "libreoffice 4.2" to "libreoffice-writer" after being mapped. Technically this is a libreoffice bug (icccm violation) 4.1.2.5. WM_CLASS Property The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information. This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically. --- http://tronche.com/gui/x/icccm/sec-4.html @Martin reading the 2nd paragraph as instruction would make diff --git a/kwin/events.cpp b/kwin/events.cpp index 5c9afcf..d992a0a 100644 --- a/kwin/events.cpp +++ b/kwin/events.cpp @@ -717,6 +717,11 @@ void Client::propertyNotifyEvent(XPropertyEvent* e) getWMHints(); getIcons(); // because KWin::icon() uses WMHints as fallback break; + case XA_WM_CLASS: + qWarning() << "Client ICCCM violation: WM_CLASS altered outside withdrawn state" << this; + getResourceClass(); + setupWindowRules(false); + break; default: if (e->atom == atoms->wm_protocols) getWindowProtocols(); violate icccm as well. otoh, there's also the skype condition.... so we could pot. read it as a warning to clients ("may" meaning rather "maybe")
> so we could pot. read it as a warning to clients ("may" meaning rather > "maybe") I read it as a warning to clients. If it were forbidden for the WM to read afterwards it would end up as SHOULD or MUST. I think that's already done in kwin/5 since c63e3533f4fa3888635980be24d391f9cbfe893d
except for re-applying the rules, yes. different matter, though.
Based on comment #8 I filed this bug with LibreOffice: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=79634 This seems to be pretty technical and a bit over my head, am I representing the issue correctly there?
icccm typo, but in general: yes.