Re: Re: WM_NAME vs. _NET_WM_NAME

--===============2535530420657302348==
Content-Type: multipart/signed; boundary="nextPart4929845.DNRXXejKye"; micalg="pgp-sha1"; protocol="application/pgp-signature"


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

On Monday 27 October 2014 09:22:15 Florian Bruhin wrote:
> * Martin Gr=C3=A4=C3=9Flin <[email protected]> [2014-10-27 08:59:17 =
+0100]:
> > > While developing a Qt application, I noticed some bugs regarding =
to
> > > window title handling [1][2][3].
> >=20
> > I assume that's Qt 5, right?
>=20
> Indeed, it works fine with Qt 4.
>=20
> > > It seems the Qt toolkit only sets _NET_WM_NAME and doesn't set WM=
_NAME
> > > at all. Now that raises some questions:
> > >=20
> > > - Should a client also set WM_NAME when setting _NET_WM_NAME? Sur=
e,
> > >=20
> > >   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).
> >=20
> > 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 cer=
tainly
> > not a bug on Qt's side. If a window manager has problems with it, i=
t's
> > more because the window manager doesn't support EWMH.
>=20
> 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=
=2Dbug=20
compatible with each window manager ;-)

>=20
> > Qt 5's XCB backend doesn't support many "deprecated" features where=
 there
> > is a EWMH replacement. For example it also doesn't support setting =
a
> > window icon through the WM_HINTS (ICCCM section 4.1.2.4) property. =
Given
> > that I interpreted this as a design decision to not support the
> > "deprecated" hints in the new implementation.
>=20
> Do you mean the backend as in a part of Qt, or xcb itself?

The backend in Qt (qtbase/src/plugins/platforms/xcb).

>=20
> > At the same time knowing the Qt development I am sure they would ac=
cept
> > patches if it improves the interoperability.
>=20
> I unfortunately don't feel comfortable enough with C++ to work on Qt
> (I'm using PyQt).
>=20
> > > - Should a window manager which implements EWMH act correctly whe=
n a
> > >=20
> > >   client sets _NET_WM_NAME but not WM_NAME? (see [2])
> >=20
> > I do not really understand this question. I looked at the bug repor=
t and
> > would say that's a hebstluftwm bug. For comparison KWin handles the=

> > situation with Qt 5 windows correctly.
>=20
> Okay. The question basically "is it the WM's fault, or Qt's fault" ;)=


Then the answer is: WMs fault.

>=20
> > Shameless plug: as you are using Qt 5, consider using KF5::WindowSy=
stem
> > 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.
>=20
> 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.

Cheers
Martin
--nextPart4929845.DNRXXejKye
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

iEYEABECAAYFAlROD7wACgkQqVXwidMiVrrfWACeNQGlxiC7foiHrC/+cZh6RwDF
9zsAoIdgQt+DFIt+o2ADjA53H/kIuvmJ
=+qr+
-----END PGP SIGNATURE-----

--nextPart4929845.DNRXXejKye--


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

--===============2535530420657302348==--