Re: Proposal: add a _NET_WM_DESKTOP_FILE

On Wednesday, November 11, 2015 9:36:48 AM CET Allison Ryan Lortie wrote:
hi Martin,

We were just talking about this on IRC today and I independently
proposed something very similar.  At that point, someone pointed me to
this thread.

awesome! :-)

I support this idea as being generally useful.  For some time, GTK has
been setting the _GTK_APPLICATION_ID property and gnome-shell has been
looking for a desktop file with this name.

I'd make two modifications to your proposal.

First, I'd rename the key to "XDG_APPLICATION_ID" to reflect that
alignment with xdg specs, namely the desktop file spec and the fact that
the string here identifies the application in all ways.

then I propose to go for:

Reason: all atoms of the EWMH spec have the _NET prefix and all window 
specific hints are in the _NET_WM name space.

Second, I'd add a requirement that the application owns the D-Bus
session bus name specified in the property.  According to the desktop
file specification, the bus name of the application and the desktop file
name should already be the same string.  This equivalence means that the
application really has only one identifier by which it is called, which
is why I think we should just call this the "application ID".

This sounds like an arbitrary restriction to me. What if the application 
doesn't use DBus or doesn't register a session bus name? Do we really want to 
enforce that? Interestingly it would break exactly the use case which 
triggered me into writing this today.

I'm fine with pointing out that if it registers a DBus session bus name it 
should (must?) be the same. But please no requirement on DBus in a window 
management spec.

As a minor nit, I guess I also think it's slightly odd that we use UTF-8
here for something that can only ever be ASCII, but that's a pretty
minor point.

That's just because X11 doesn't specify a default encoding. NETWM introduced 
the UTF-8 atom which at least tells one what the encoding is. If we use the 
"normal" string atom, we end up with "could be anything". So even if not 
needed: utf-8 is better, in this case :-)


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]