Re: WM_NAME vs. _NET_WM_NAME

Thomas Lübking <[email protected]> Mon, 27 Oct 2014 12:25:25 +0100
Newsgroups gmane.comp.gnome.wm-spec
Message-ID <CAAPqV4R3N0S-QettpsxqygSCp=DcqnUV5VDMFrOZh9ws-0PC0g@mail.gmail.com>
--===============5623146208958517382==
Content-Type: multipart/alternative; boundary=001a11c23d0479d9f8050665c98a

--001a11c23d0479d9f8050665c98a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It's a netwm spec bug:

_NET_WM_NAME

_NET_WM_NAME, UTF8_STRING

The Client SHOULD set this to the title of the window in UTF-8 encoding. If
set, the Window Manager should use this in preference to WM_NAME.

------

"should"...

So any netwm compliant WM "should" prefer _NET_WM_NAME. Qt read that as "we
won't support pre-netwm stuff anymore, so we can dittch it", but that's
"wrong" - a perfectly netwm compliant wm can entirely ignore _NET_WM_NAME m=
(

hlwm *should* please prefer _NET_WM_NAME, but Qt has to set WM_NAME if
interested in a caption - at least they can not point the spec as reason
(they can however deny support for WMs deviating from the specs
"suggestions")


Sorry for gmail webclient,

Thomas

Am Montag, 27. Oktober 2014 schrieb Florian Bruhin :

> * Martin Gr=C3=A4=C3=9Flin <[email protected] <javascript:;>> [2014-10-2=
7 10:26:14
> +0100]:
> > > > > It seems the Qt toolkit only sets _NET_WM_NAME and doesn't set
> WM_NAME
> > > > > at all. Now that raises some questions:
> > > > >
> > > > > - Should a client also set WM_NAME when setting _NET_WM_NAME? Sur=
e,
> > > > >
> > > > >   it's a good idea for backwards-compatiblity, but is it warrante=
d
> to
> > > > >   open a bug against Qt? (I'd say yes, but I'd like to hear other
> > > > >   opinions).
> > > >
> > > > From my reading of the relevant section in ICCCM (4.1.2.1) there is
> no
> > > > indication that a client is supposed to set it. Given that it's
> certainly
> > > > not a bug on Qt's side. If a window manager has problems with it,
> it's
> > > > more because the window manager doesn't support EWMH.
> > >
> > > Okay. I'll still open a bug in Qt then since it seems to raise
> > > problems in the wild - then it's up to them to decide whether it's
> > > worth to fix it or not ;)
> >
> > Fair enough, though I think it's not the task of a toolkit to be
> bug-to-bug
> > compatible with each window manager ;-)
>
> Sure, but since it lead to problems in two applications already
> (KeePass and herbstluftwm), and everything else (tm) seems to set
> both, it still (IMHO) is Qt's job to do it the way it causes the least
> friction everywhere else. Of course it'd be ideal if everything else
> would support _NET_WM_NAME (and I'll open a bugreport against KeePass
> as well), but that's simply not the case.
>
> But as said, that's left to the Qt people to decide then ;)
>
> > > > Shameless plug: as you are using Qt 5, consider using
> KF5::WindowSystem
> > > > which is a nice Qt 5 (only, no further KDE dependencies) library
> > > > implementing EWMH, supporting fallback to ICCCM if needed. It's the
> > > > library powering KWin and Plasma (e.g. taskmanager) and also used i=
n
> > > > LXQt.
> > >
> > > Probably not an option with PyQt, and also that's not really a
> > > dependency I want to have just to set a window title :D
> >
> > ah that be more for the case of reading the window title.
>
> That part is in KeePass (a password manager which can autofill fields
> in a browser it finds via the title), I just happened to get the bug
> report because it works everywhere else :P
>
> Thanks again for your insights!
>
> Florian
>
> --
> http://www.the-compiler.org | [email protected] <javascript:;>
> (Mail/XMPP)
>              GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>

--001a11c23d0479d9f8050665c98a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It&#39;s a netwm spec bug:<div><br></div><div><div class=3D"titlepage" styl=
e=3D"font-family:&#39;Droid Sans&#39;;font-size:medium"><h3 class=3D"title"=
>_NET_WM_NAME</h3></div><pre class=3D"programlisting" style>_NET_WM_NAME, U=
TF8_STRING
</pre><p style=3D"font-family:&#39;Droid Sans&#39;;font-size:medium">The Cl=
ient SHOULD set this to the title of the window in UTF-8 encoding. If set, =
the Window Manager should use this in preference to WM_NAME.</p><p style=3D=
"font-family:&#39;Droid Sans&#39;;font-size:medium">------</p><p style=3D"f=
ont-family:&#39;Droid Sans&#39;;font-size:medium">&quot;should&quot;...</p>=
<p style=3D"font-family:&#39;Droid Sans&#39;;font-size:medium">So any netwm=
 compliant WM &quot;should&quot; prefer _NET_WM_NAME. Qt read that as &quot=
;we won&#39;t support pre-netwm stuff anymore, so we can dittch it&quot;, b=
ut that&#39;s &quot;wrong&quot; - a perfectly netwm compliant wm can entire=
ly ignore _NET_WM_NAME m(</p><p style=3D"font-family:&#39;Droid Sans&#39;;f=
ont-size:medium">hlwm *should* please prefer _NET_WM_NAME, but Qt has to se=
t WM_NAME if interested in a caption - at least they can not point the spec=
 as reason (they can however deny support for WMs deviating from the specs =
&quot;suggestions&quot;)</p><p style=3D"font-family:&#39;Droid Sans&#39;;fo=
nt-size:medium"><br></p><p style=3D"font-family:&#39;Droid Sans&#39;;font-s=
ize:medium">Sorry for gmail webclient,</p><p style=3D"font-family:&#39;Droi=
d Sans&#39;;font-size:medium">Thomas</p><br>Am Montag, 27. Oktober 2014 sch=
rieb Florian Bruhin :<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Martin Gr=C3=A4=
=C3=9Flin &lt;<a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#39;,=
 &#39;[email protected]&#39;)">[email protected]</a>&gt; [2014-10-27 10:2=
6:14 +0100]:<br>
&gt; &gt; &gt; &gt; It seems the Qt toolkit only sets _NET_WM_NAME and does=
n&#39;t set WM_NAME<br>
&gt; &gt; &gt; &gt; at all. Now that raises some questions:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; - Should a client also set WM_NAME when setting _NET_WM=
_NAME? Sure,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0it&#39;s a good idea for backwards-compatib=
lity, but is it warranted to<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0open a bug against Qt? (I&#39;d say yes, bu=
t I&#39;d like to hear other<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0opinions).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; From my reading of the relevant section in ICCCM (4.1.2.1) t=
here is no<br>
&gt; &gt; &gt; indication that a client is supposed to set it. Given that i=
t&#39;s certainly<br>
&gt; &gt; &gt; not a bug on Qt&#39;s side. If a window manager has problems=
 with it, it&#39;s<br>
&gt; &gt; &gt; more because the window manager doesn&#39;t support EWMH.<br=
>
&gt; &gt;<br>
&gt; &gt; Okay. I&#39;ll still open a bug in Qt then since it seems to rais=
e<br>
&gt; &gt; problems in the wild - then it&#39;s up to them to decide whether=
 it&#39;s<br>
&gt; &gt; worth to fix it or not ;)<br>
&gt;<br>
&gt; Fair enough, though I think it&#39;s not the task of a toolkit to be b=
ug-to-bug<br>
&gt; compatible with each window manager ;-)<br>
<br>
Sure, but since it lead to problems in two applications already<br>
(KeePass and herbstluftwm), and everything else (tm) seems to set<br>
both, it still (IMHO) is Qt&#39;s job to do it the way it causes the least<=
br>
friction everywhere else. Of course it&#39;d be ideal if everything else<br=
>
would support _NET_WM_NAME (and I&#39;ll open a bugreport against KeePass<b=
r>
as well), but that&#39;s simply not the case.<br>
<br>
But as said, that&#39;s left to the Qt people to decide then ;)<br>
<br>
&gt; &gt; &gt; Shameless plug: as you are using Qt 5, consider using KF5::W=
indowSystem<br>
&gt; &gt; &gt; which is a nice Qt 5 (only, no further KDE dependencies) lib=
rary<br>
&gt; &gt; &gt; implementing EWMH, supporting fallback to ICCCM if needed. I=
t&#39;s the<br>
&gt; &gt; &gt; library powering KWin and Plasma (e.g. taskmanager) and also=
 used in<br>
&gt; &gt; &gt; LXQt.<br>
&gt; &gt;<br>
&gt; &gt; Probably not an option with PyQt, and also that&#39;s not really =
a<br>
&gt; &gt; dependency I want to have just to set a window title :D<br>
&gt;<br>
&gt; ah that be more for the case of reading the window title.<br>
<br>
That part is in KeePass (a password manager which can autofill fields<br>
in a browser it finds via the title), I just happened to get the bug<br>
report because it works everywhere else :P<br>
<br>
Thanks again for your insights!<br>
<br>
Florian<br>
<br>
--<br>
<a href=3D"http://www.the-compiler.org" target=3D"_blank">http://www.the-co=
mpiler.org</a> | <a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#3=
9;, &#39;[email protected]&#39;)">[email protected]</a> (Mail/XMPP)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPG 0xFD55A072 | <a href=3D=
"http://the-compiler.org/pubkey.asc" target=3D"_blank">http://the-compiler.=
org/pubkey.asc</a><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I love long mails! | <a href=3D"http://em=
ail.is-not-s.ms/" target=3D"_blank">http://email.is-not-s.ms/</a><br>
</blockquote></div>

--001a11c23d0479d9f8050665c98a--

--===============5623146208958517382==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
wm-spec-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/wm-spec-list

--===============5623146208958517382==--