Re: WM_NAME vs. _NET_WM_NAME

--===============8267182568994626019==
Content-Type: multipart/signed; boundary="nextPart54418603.CUzKQlOMIl"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart54418603.CUzKQlOMIl
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Monday 27 October 2014 07:03:20 Florian Bruhin wrote:
> (Cc'ed the hlwm mailinglist because of [2])
>=20
> First of all, I hope this is also the right place to ask questions,
> rather than developemnt of the wm-spec -- if not, I'd be glad if
> someone directed me to the right place.

yeah I think for general question regarding the co-interoperability of=20=

toolkits and window managers this list is probably the best place to as=
k.

>=20
> While developing a Qt application, I noticed some bugs regarding to
> window title handling [1][2][3].

I assume that's Qt 5, right?

>=20
> It seems the Qt toolkit only sets _NET_WM_NAME and doesn't set WM_NAM=
E
> at all. Now that raises some questions:
>=20
> - Should a client also set WM_NAME when setting _NET_WM_NAME? Sure,
>   it's a good idea for backwards-compatiblity, but is it warranted to=

>   open a bug against Qt? (I'd say yes, but I'd like to hear other
>   opinions).

From=20my reading of the relevant section in ICCCM (4.1.2.1) there is no=20=

indication that a client is supposed to set it. Given that it's certain=
ly not=20
a bug on Qt's side. If a window manager has problems with it, it's more=
=20
because the window manager doesn't support EWMH.

Qt 5's XCB backend doesn't support many "deprecated" features where the=
re is a=20
EWMH replacement. For example it also doesn't support setting a window =
icon=20
through the WM_HINTS (ICCCM section 4.1.2.4) property. Given that I=20
interpreted this as a design decision to not support the "deprecated" h=
ints in=20
the new implementation.

At the same time knowing the Qt development I am sure they would accept=
=20
patches if it improves the interoperability.

>=20
> - Should a window manager which implements EWMH act correctly when a
>   client sets _NET_WM_NAME but not WM_NAME? (see [2])

I do not really understand this question. I looked at the bug report an=
d would=20
say that's a hebstluftwm bug. For comparison KWin handles the situation=
 with=20
Qt 5 windows correctly.

>=20
> - Should a client reading other client's titles respect _NET_WM_NAME
>   (see [3] - it probably *should* but doesn't *have to*, right?)

other clients are a little bit outside the spec as it's mostly about=20=

communication between window managers and clients. I'd say it's a good =
idea to=20
always first test the EMWH hint and only interpret the ICCCM hint if no=
t=20
present. Like with the last question: Plasma (libtaskmanager) handles t=
he=20
situation correctly for Qt 5 windows.

Shameless plug: as you are using Qt 5, consider using KF5::WindowSystem=
 which=20
is a nice Qt 5 (only, no further KDE dependencies) library implementing=
 EWMH,=20
supporting fallback to ICCCM if needed. It's the library powering KWin =
and=20
Plasma (e.g. taskmanager) and also used in LXQt.

Cheers
Martin Gr=C3=A4=C3=9Flin
--nextPart54418603.CUzKQlOMIl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlRN+1sACgkQqVXwidMiVrqD4ACgmy5wY0DwbanJ+I3IjzBdJDw5
rrUAnjRY66wYuYz50ps1/6V58jBhLRkU
=nzvd
-----END PGP SIGNATURE-----

--nextPart54418603.CUzKQlOMIl--


--===============8267182568994626019==
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

--===============8267182568994626019==--