| Summary: | please misread icccm and generously update WM_CLASS for not withdrawn windows | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Shimi Chen <shimi.chen> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | Flags: | thomas.luebking:
Decision-Required+
|
| Priority: | NOR | ||
| Version First Reported In: | 4.11.9 | ||
| Target Milestone: | 5 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 5.0 | |
| Sentry Crash Report: | |||
| Attachments: |
xprop output on odp file
xprop output on odt file xprop output on docx file |
||
|
Description
Shimi Chen
2014-06-03 09:01:44 UTC
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. |