Re: Proposal: add a _NET_WM_DESKTOP_FILE

--===============0271960670880911776==
Content-Type: multipart/signed; boundary="nextPart1875076.ZalqdP1d5L"; micalg="pgp-sha1"; protocol="application/pgp-signature"

--nextPart1875076.ZalqdP1d5L
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Wednesday, November 11, 2015 11:25:15 PM CET you wrote:
> Is there a use case where the WM_CLASS would be different from the
> desktop file name in practice?
> 
> I'm not aware of any applications which weren't able to adapt to the
> new WM_CLASS matching rules once told about them -- we should just
> document it.

Erm, sorry. You cannot change the meaning and expect legacy applications will 
adopt to it. That just doesn't work.

And yes I tried and the first application I checked has a mismatch between 
desktop file name and WM_CLASS. I picked xterm.

Oh and there are also windows belonging to applications which don't have a 
desktop file at all. I can think of hundreds of test applications which just 
don't install on the system in any meaningful way. What's their WM_CLASS 
supposed to be?

Sorry, I think that's just wish-full thinking to be able to update ICCCM 
section 4.1.2.5 and everybody adopting to it.

Cheers
Martin

> 
> On Wed, Nov 11, 2015 at 11:22 PM, Martin Graesslin <[email protected]> 
wrote:
> > On Wednesday, November 11, 2015 11:21:44 AM CET Allison Ryan Lortie wrote:
> >> I understand that this doesn't correspond exactly to your original
> >> intention with this addition,
> > 
> > no it's worse: it makes the part which I wanted to fix impossible. Which
> > would mean that:
> > a) I scratch what I wanted to fix
> > b) willfully break the spec
> > c) add a KDE specific additional property to get what I wanted in the
> > first
> > place
> > 
> >> but I think your original intent is
> >> unrealisable: you will either have many apps that provide nothing at
> >> all,
> > 
> > which is fine! This is an optional flag. It's not a requirement. The
> > proposal (after Thomas update) will say that the window MUST NOT specify
> > the desktop file if it doesn't know it. If it cannot be matched to a
> > desktop file: that's fine.
> > 
> >> or you will have some apps that provide something other than the
> >> desktop file name.
> > 
> > This would be a clear violation of the spec. Adding a requirement to add
> > DBus to it, will not fix windows ignoring the spec and passing in wrong
> > data.> 
> >> This is the same problem as the previous attempt to solve this problem:
> >> there was a proposal at some point that the wmclass should be equal to
> >> the name of the desktop file.  For many apps this was true, but coverage
> >> was never 100%.
> > 
> > Right, because you cannot change the meaning of an existing property and
> > then assume that it will work. Because of that I propose a new additional
> > protocol applications can opt-in to when they can provide the
> > information.
> > 
> > Cheers
> > Martin
> > _______________________________________________
> > wm-spec-list mailing list
> > [email protected]
> > https://mail.gnome.org/mailman/listinfo/wm-spec-list

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

iEYEABECAAYFAlZEQuYACgkQqVXwidMiVrql+wCgikekz2cn8n/TLEuronHPoh0w
AicAnjNqtK1N+j7C0UiK85BrsAn2zcur
=RMQ1
-----END PGP SIGNATURE-----

--nextPart1875076.ZalqdP1d5L--


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

--===============0271960670880911776==--