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

Re: WM_NAME vs. _NET_WM_NAME



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äßlin <mgraesslin _at_ kde _dot_ org> [2014-10-27 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? 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.
> >
> > 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 in
> > > 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 | me _at_ the _minus_ compiler _dot_ org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/