From me at the-compiler.org  Wed Oct  1 22:01:19 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 1 Oct 2014 22:01:19 +0200
Subject: Fwd: Herbsluftwm Debian Package
Message-ID: <20141001200119.GW30684@lupin>

Forwarding this here.

Too lazy to translate it (sorry!) and probably the involved people can
speak German.

----- Forwarded message from simon <komsat at kalidasa.klamath.ch> -----

Date: Wed, 01 Oct 2014 21:20:47 +0200
From: simon <komsat at kalidasa.klamath.ch>

Hi,

Random Verbesserungsvorschlag f?r Herbstuft:
* Debian-Paket braucht ein Dependency auf xorg (bzw. ein passendes
"xorg-kompatibel-Metapaket")
* In das Tutorial schreiben, dass xorg installiert sein muss

Hab grad auf einem neuen Laptop Debian aufgesetzt und herbstluft
installiert. Nat?rlich habe ich die Dependencies nicht genau angeschaut
und nur gesehen, dass irgendwelches x11-Library-Zeugs dabei ist. Beim
Starten von herbstluftwm kommt dann jeweils die Meldung "cannot open
display" ohne weitere Info.

Nach 30' hab ich jetzt herausgefunden, dass das Paket xorg noch gefehlt hat.

Gruss Simon

----- End forwarded message -----

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141001/e622f7d8/attachment.sig>

From edu at thorsten-wissmann.de  Tue Oct  7 11:54:50 2014
From: edu at thorsten-wissmann.de (Thorsten =?iso-8859-1?Q?Wi=DFmann?=)
Date: Tue, 7 Oct 2014 11:54:50 +0200
Subject: Bringing herbstluftwm to Github?
In-Reply-To: <20140930202601.GD30684@lupin>
References: <20140930202601.GD30684@lupin>
Message-ID: <20141007095450.GA17880@hoth>

Hi,

On Tue, Sep 30, 2014 at 10:26:01PM +0200, Florian Bruhin wrote:
> some probably controversal proposal from me: What about creating an
> "official" herbstluftwm project on github? Pushing code could be
> managed via git hooks, so Thorsten could still push to the FAU repo
> which then gets auto pushed to github.

Would be an idea. I just tried it and you can find it on

https://github.com/herbstluftwm/herbstluftwm

> Rationale:
> 
> Some search engines like duckduckgo display github repos on top in
> some box. There are now some unoffical repos[1] floating around and
> all this might be confusing for people - actually I remember people
> linking some github repo and asking if that's the right one.

Good (and sad?) argument.

> The issue tracker and pull requests could be disabled, but I'd even
> vouch for enabling them. Why?
> 
> - Issue trackers is how people expect to be able to report issues
>   nowadays. I remember people asking where to report stuff.

So that would solve the problem of an bugtracker?

> - If someone wants to contribute, they can easily look at the issue
>   list instead of digging through the mailinglist and checking what's
>   not done yet by hand.

Right.

> - Many people already have an account on Github, so it's very painless
>   for them to create issues and contribute.

OK, but IMO good bugtrackers do not require an account. But important
is: it is no pain for us (me, you?) to maintain a bugtracker.

> - Many issues are forgotten after some time, or not in BUGS at all, or
>   in BUGS but fixed, or in my personal collected wishlist but not in
>   BUGS, so not easily visible for anyone.

Yes, (not) maintaining the BUGS file is horrible.

> - It's much easier to add comments and more information to long-living
>   issues this way, and have everything at one place.

I thought, the "long-living" argument says: "do everything in the git
and on the ML which is archived".

> - My personal opinion aside (I actually see why you prefer patches per
>   email for single commits now) - pull requests are how people
>   instictively try to contribute to projects. Just lately I've seen
>   someone say "why can't we contribute to Python? There's no Github
>   repo!" in #python.

But the remaining question is: what to do with pull requests that are
unmergable (because of code quality)? Say to them they should fix it and
send the pull-request with the rebased commits again?

> I believe the aim should be to make contributing as easy and native
> for people as possible, even if that means some more work for the
> maintainer. After all the time "gained" by a contribution is much
> bigger than the one lost by using a different git workflow.
> 
> We can still say patches to the ML are the prefered way of
> contributing, but I believe it'd attract more people to report their
> issues, and probably also more people to contribute. And if someone
> doesn't want to learn about git-format-patch/git-send-email, etc., I
> think this shouldn't be the thing holding them back from contributing.

Well if someone does not want to learn "git format-patch origin/master"
then maybe I don't want to teach him how to use git-rebase to fix the
broken commits in his pull request.

In my opinion we can just try it and say the preferred way is the ML.
And if I get annoyed by some issue I'll complain here to find the
concrete solution for issue.

Note that all the arguments in your mail also imply: "Create a
herbstluftwm facebook page & group" (everyone has an account, easier
than sending mails, get known by more people to make them contribute to
the project...) [Facebook = Internet within the Internet, Github =
Git-Network+ML within the Internet]

Cheers,
Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141007/3f635f1a/attachment.sig>

From me at the-compiler.org  Tue Oct  7 13:24:33 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 7 Oct 2014 13:24:33 +0200
Subject: Bringing herbstluftwm to Github?
In-Reply-To: <20141007095450.GA17880@hoth>
References: <20140930202601.GD30684@lupin>
 <20141007095450.GA17880@hoth>
Message-ID: <20141007112433.GA30684@lupin>

* Thorsten Wi?mann <edu at thorsten-wissmann.de> [2014-10-07 11:54:50 +0200]:
> Hi,
> 
> On Tue, Sep 30, 2014 at 10:26:01PM +0200, Florian Bruhin wrote:
> > some probably controversal proposal from me: What about creating an
> > "official" herbstluftwm project on github? Pushing code could be
> > managed via git hooks, so Thorsten could still push to the FAU repo
> > which then gets auto pushed to github.
> 
> Would be an idea. I just tried it and you can find it on
> 
> https://github.com/herbstluftwm/herbstluftwm

Thanks! :)

> > The issue tracker and pull requests could be disabled, but I'd even
> > vouch for enabling them. Why?
> > 
> > - Issue trackers is how people expect to be able to report issues
> >   nowadays. I remember people asking where to report stuff.
> 
> So that would solve the problem of an bugtracker?

Indeed - there's only one issue I can see: If Github for some reason
dies (or goes pay-only) we lose the issue list. But I don't expect
that to happen soon, and it could be backed up via the API (working on
that, for qutebrowser as well).

> > - Many people already have an account on Github, so it's very painless
> >   for them to create issues and contribute.
> 
> OK, but IMO good bugtrackers do not require an account. But important
> is: it is no pain for us (me, you?) to maintain a bugtracker.

That's true - but also yields spam problems. Okay, maybe with a check
and/or captcha that could be solved.

Either way, I'd say people can still report bugs via the
mailinglist/IRC and we'll either fix it right away or open an issue in
the tracker so it doesn't get forgotten - do you agree? That's
currently the workflow I have with qutebrowser, and I think it's
working pretty well.

> > - It's much easier to add comments and more information to long-living
> >   issues this way, and have everything at one place.
> 
> I thought, the "long-living" argument says: "do everything in the git
> and on the ML which is archived".

I think we're talking about two different things here - one is
"the data won't ever get lost" and the other is "it's easy to find
information on an issue which is a year old but I know is still
there" or "I want to see what issues there still are".

For #1, backing up via the API (as said above) is the paranoid
solution, thinking "github is too big to fail" is the pragmatic one.

For #2, a bug tracker definitely makes that easier.

> > - My personal opinion aside (I actually see why you prefer patches per
> >   email for single commits now) - pull requests are how people
> >   instictively try to contribute to projects. Just lately I've seen
> >   someone say "why can't we contribute to Python? There's no Github
> >   repo!" in #python.
> 
> But the remaining question is: what to do with pull requests that are
> unmergable (because of code quality)? Say to them they should fix it and
> send the pull-request with the rebased commits again?

With the github pull requests (tm), a pull request is just a pointer.
This means the pull request is just
"merge The-Compiler/herbstluftwm/frame_objects into
herbstluftwm/herbstluftwm/master". Until you hit the merge-button (or
fetch/merge in the commandline), I can still push new commits to my
own branch.

An example:

https://github.com/The-Compiler/qutebrowser/pull/1

The contributor (claudehohl) did some commits and opened the request.
I then did some comments, claudehohl pushed some other commits until I
decided it's okay and merged it.

I'm not sure what happens when claudehohl would've rebased his branch,
but I guess this would've worked the same way.

> > I believe the aim should be to make contributing as easy and native
> > for people as possible, even if that means some more work for the
> > maintainer. After all the time "gained" by a contribution is much
> > bigger than the one lost by using a different git workflow.
> > 
> > We can still say patches to the ML are the prefered way of
> > contributing, but I believe it'd attract more people to report their
> > issues, and probably also more people to contribute. And if someone
> > doesn't want to learn about git-format-patch/git-send-email, etc., I
> > think this shouldn't be the thing holding them back from contributing.
> 
> Well if someone does not want to learn "git format-patch origin/master"
> then maybe I don't want to teach him how to use git-rebase to fix the
> broken commits in his pull request.

You got a point there.

> In my opinion we can just try it and say the preferred way is the ML.
> And if I get annoyed by some issue I'll complain here to find the
> concrete solution for issue.

That sounds good.

> Note that all the arguments in your mail also imply: "Create a
> herbstluftwm facebook page & group" (everyone has an account, easier
> than sending mails, get known by more people to make them contribute to
> the project...) [Facebook = Internet within the Internet, Github =
> Git-Network+ML within the Internet]

Almost. I don't want to start a rant against facebook, but:

- With Github you still own your data and it's easy to get it out (or
  in case of the repo, you have your own copy either way).

- Facebook is not what people use for collaborating on geeky
  projects usually :P

- I even dare to say more hlwm users have a Github account than a
  Facebook one - just another intended audience :D

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141007/d9dc8ce4/attachment.sig>

From removed  Fri Oct 24 21:40:59 2014
From: removed (removed)
Date: Fri, 24 Oct 2014 23:40:59 +0400
Subject: removed
Message-ID: <4742F4A7AC785A89555019A1B53C1F67@cirurbo>

removed


From me at the-compiler.org  Mon Oct 27 07:03:20 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 27 Oct 2014 07:03:20 +0100
Subject: WM_NAME vs. _NET_WM_NAME
Message-ID: <20141027060320.GF306@lupin>

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

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

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

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

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

Thanks,

Florian

[1] https://github.com/The-Compiler/qutebrowser/issues/198
[2] https://github.com/herbstluftwm/herbstluftwm/issues/35
[3] https://github.com/The-Compiler/qutebrowser/issues/216

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/f056ff51/attachment.sig>

From mgraesslin at kde.org  Mon Oct 27 08:59:17 2014
From: mgraesslin at kde.org (Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=)
Date: Mon, 27 Oct 2014 08:59:17 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <20141027060320.GF306@lupin>
References: <20141027060320.GF306@lupin>
Message-ID: <2292677.2a2vOHUgMP@martin-desktop>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/b3390b5f/attachment.asc>

From me at the-compiler.org  Mon Oct 27 09:22:15 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 27 Oct 2014 09:22:15 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <2292677.2a2vOHUgMP@martin-desktop>
References: <20141027060320.GF306@lupin>
 <2292677.2a2vOHUgMP@martin-desktop>
Message-ID: <20141027082215.GA4524@lupin>

* Martin Gr??lin <mgraesslin at kde.org> [2014-10-27 08:59:17 +0100]:
> > While developing a Qt application, I noticed some bugs regarding to
> > window title handling [1][2][3].
> 
> I assume that's Qt 5, right?

Indeed, it works fine with Qt 4.

> > 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 ;)

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

Do you mean the backend as in a part of Qt, or xcb itself?

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

I unfortunately don't feel comfortable enough with C++ to work on Qt
(I'm using PyQt).

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

Okay. The question basically "is it the WM's fault, or Qt's fault" ;)

> 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

Thanks,

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/5c5933f7/attachment.sig>

From mgraesslin at kde.org  Mon Oct 27 10:26:14 2014
From: mgraesslin at kde.org (Martin =?ISO-8859-1?Q?Gr=E4=DFlin?=)
Date: Mon, 27 Oct 2014 10:26:14 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <20141027082215.GA4524@lupin>
References: <20141027060320.GF306@lupin> <2292677.2a2vOHUgMP@martin-desktop>
 <20141027082215.GA4524@lupin>
Message-ID: <1661471.3nf5tjJDzp@martin-desktop>

On Monday 27 October 2014 09:22:15 Florian Bruhin wrote:
> * Martin Gr??lin <mgraesslin at kde.org> [2014-10-27 08:59:17 +0100]:
> > > While developing a Qt application, I noticed some bugs regarding to
> > > window title handling [1][2][3].
> > 
> > I assume that's Qt 5, right?
> 
> Indeed, it works fine with Qt 4.
> 
> > > 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 ;-)

> 
> > 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.
> 
> Do you mean the backend as in a part of Qt, or xcb itself?

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

> 
> > At the same time knowing the Qt development I am sure they would accept
> > patches if it improves the interoperability.
> 
> I unfortunately don't feel comfortable enough with C++ to work on Qt
> (I'm using PyQt).
> 
> > > - 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.
> 
> Okay. The question basically "is it the WM's fault, or Qt's fault" ;)

Then the answer is: WMs fault.

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

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/007b0a5b/attachment.asc>

From me at the-compiler.org  Mon Oct 27 10:40:58 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 27 Oct 2014 10:40:58 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <1661471.3nf5tjJDzp@martin-desktop>
References: <20141027060320.GF306@lupin> <2292677.2a2vOHUgMP@martin-desktop>
 <20141027082215.GA4524@lupin> <1661471.3nf5tjJDzp@martin-desktop>
Message-ID: <20141027094058.GB4524@lupin>

* Martin Gr??lin <mgraesslin at kde.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-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/4f77c3d8/attachment.sig>

From thomas.luebking at gmail.com  Mon Oct 27 12:25:25 2014
From: thomas.luebking at gmail.com (=?UTF-8?Q?Thomas_L=C3=BCbking?=)
Date: Mon, 27 Oct 2014 12:25:25 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <20141027094058.GB4524@lupin>
References: <20141027060320.GF306@lupin> <2292677.2a2vOHUgMP@martin-desktop>
 <20141027082215.GA4524@lupin> <1661471.3nf5tjJDzp@martin-desktop>
 <20141027094058.GB4524@lupin>
Message-ID: <CAAPqV4R3N0S-QettpsxqygSCp=DcqnUV5VDMFrOZh9ws-0PC0g@mail.gmail.com>

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.org <javascript:;>> [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-compiler.org <javascript:;>
> (Mail/XMPP)
>              GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/d140acaa/attachment.htm>

From jstpierre at mecheye.net  Mon Oct 27 17:19:39 2014
From: jstpierre at mecheye.net (Jasper St. Pierre)
Date: Mon, 27 Oct 2014 09:19:39 -0700
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <CAAPqV4R3N0S-QettpsxqygSCp=DcqnUV5VDMFrOZh9ws-0PC0g@mail.gmail.com>
References: <20141027060320.GF306@lupin> <2292677.2a2vOHUgMP@martin-desktop>
 <20141027082215.GA4524@lupin> <1661471.3nf5tjJDzp@martin-desktop>
 <20141027094058.GB4524@lupin>
 <CAAPqV4R3N0S-QettpsxqygSCp=DcqnUV5VDMFrOZh9ws-0PC0g@mail.gmail.com>
Message-ID: <CAA0H+QReLq4Y6c60Q8bDstJRq=y=6Jux+ZOFRsFLojt_ep+iJg@mail.gmail.com>

The rationale for having both is unclear, but for reference, WM_NAME is of
ICCCM encoding (meaning it's one of six thousand possible encodings,
specified by the TYPE atom), while _NET_WM_NAME is guaranteed to be UTF8,
which is just a lot simpler. So, consider WM_NAME deprecated, and
_NET_WM_NAME the replacement.

We might just want to fix the wm spec as Thomas suggests, rewording it to
"If set, the Window Manager MUST use this in preference to WM_NAME"

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/c7b94c7a/attachment.htm>

From rhialto at falu.nl  Mon Oct 27 18:07:45 2014
From: rhialto at falu.nl (Rhialto)
Date: Mon, 27 Oct 2014 18:07:45 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <2292677.2a2vOHUgMP@martin-desktop>
References: <20141027060320.GF306@lupin>
 <2292677.2a2vOHUgMP@martin-desktop>
Message-ID: <20141027170744.GT1402@falu.nl>

On Mon 27 Oct 2014 at 08:59:17 +0100, Martin Gr??lin wrote:
> 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.

Does it check first if the relevant EWMH feature is supposed to be
supported by the window manager? If not, that is a bug (in Qt), in my
opinion.

In my mind there can be two ways an application goes about it:

- blindly use EWMH features, but then it should set related ICCCM
  properties as well, for interoperability.

- check for EWMH features, and use them if supported. Otherwise, use
  ICCCM features instead.

After all, there are plenty of window managers which don't support EWMH,
or don't support it in all respects.

Since window managers can be changed at any time, I think that the
first approach is somewhat safer -- an application has to do a lot of
work to detect that the window manager suddenly does not support
_NET_WM_NAME any more, and compensate for that.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/c1997324/attachment.sig>

From me at the-compiler.org  Mon Oct 27 18:59:47 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 27 Oct 2014 18:59:47 +0100
Subject: WM_NAME vs. _NET_WM_NAME
In-Reply-To: <20141027170744.GT1402@falu.nl>
References: <20141027060320.GF306@lupin> <2292677.2a2vOHUgMP@martin-desktop>
 <20141027170744.GT1402@falu.nl>
Message-ID: <20141027175947.GE4524@lupin>

* Rhialto <rhialto at falu.nl> [2014-10-27 18:07:45 +0100]:
> On Mon 27 Oct 2014 at 08:59:17 +0100, Martin Gr??lin wrote:
> > 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.
> 
> Does it check first if the relevant EWMH feature is supposed to be
> supported by the window manager? If not, that is a bug (in Qt), in my
> opinion.

Looking at the code[1] it does not.

I opened a bug[2] against Qt and it's priority was set to "Important",
which sounds to me like they agree ;)

(The reporter of the original qutebrowser bug also opened a bug
against KeePassX[3])

Thanks again to everyone for your thoughts!

Florian

[1] http://paste.the-compiler.org/view/f3e02a7a
[2] https://bugreports.qt-project.org/browse/QTBUG-42209
[3] https://www.keepassx.org/dev/issues/236

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/3bc8ca7e/attachment.sig>

From me at the-compiler.org  Mon Oct 27 19:32:29 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 27 Oct 2014 19:32:29 +0100
Subject: [PATCH] Update titles correctly for clients without WM_NAME.
Message-ID: <20141027183229.GF4524@lupin>

See the attached patch.

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-titles-correctly-for-clients-without-WM_NAME.patch
Type: text/x-diff
Size: 2112 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/acc43364/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/acc43364/attachment.sig>

From edu at thorsten-wissmann.de  Mon Oct 27 20:30:35 2014
From: edu at thorsten-wissmann.de (Thorsten =?iso-8859-1?Q?Wi=DFmann?=)
Date: Mon, 27 Oct 2014 20:30:35 +0100
Subject: [PATCH] Update titles correctly for clients without WM_NAME.
In-Reply-To: <20141027183229.GF4524@lupin>
References: <20141027183229.GF4524@lupin>
Message-ID: <20141027193035.GA14108@hoth>

Hi Florian,

> This fixes updating of titles for clients which only have _NET_WM_NAME
> set, but not WM_NAME, e.g. everything using Qt5.

I trust you if you tested it to work with Qt5 :-)

130138f Update titles correctly for clients without WM_NAME.

Regards,
Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/0cefe206/attachment.sig>

From me at the-compiler.org  Mon Oct 27 20:37:30 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 27 Oct 2014 20:37:30 +0100
Subject: [PATCH] Update titles correctly for clients without WM_NAME.
In-Reply-To: <20141027193035.GA14108@hoth>
References: <20141027183229.GF4524@lupin>
 <20141027193035.GA14108@hoth>
Message-ID: <20141027193730.GG4524@lupin>

Hi,

* Thorsten Wi?mann <edu at thorsten-wissmann.de> [2014-10-27 20:30:35 +0100]:
> Hi Florian,
> 
> > This fixes updating of titles for clients which only have _NET_WM_NAME
> > set, but not WM_NAME, e.g. everything using Qt5.
> 
> I trust you if you tested it to work with Qt5 :-)

Right, forgot to mention that - tested using otter-browser, titles get
updated properly after that commit.

> 130138f Update titles correctly for clients without WM_NAME.

Thanks!

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141027/5120aeb1/attachment.sig>