Re: WM_NAME vs. _NET_WM_NAME



On Monday 27 October 2014 07:03:20 Florian Bruhin wrote:
(Cc'ed the hlwm mailinglist because of [2])

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 
toolkits and window managers this list is probably the best place to ask.


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

I assume that's Qt 5, right?


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? 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 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.

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.

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


- 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 and would 
say that's a hebstluftwm bug. For comparison KWin handles the situation with 
Qt 5 windows correctly.


- 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 
communication between window managers and clients. I'd say it's a good idea to 
always first test the EMWH hint and only interpret the ICCCM hint if not 
present. Like with the last question: Plasma (libtaskmanager) handles the 
situation correctly for Qt 5 windows.

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 in LXQt.

Cheers
Martin Gräßlin

Attachment: signature.asc
Description: This is a digitally signed message part.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]