GNOME.org
 

Re: Proposal: add a _NET_WM_DESKTOP_FILE

On Wed, 11 Nov 2015 11:20:35 -0800 "Jasper St. Pierre" <jstpierre mecheye net>
said:


Given that most applications already have the WM_CLASS trick
correctly, why can't we just say that users should try to match
WM_CLASS to their desktop file correctly? I don't see a reason to add
a new field when WM_CLASS already does what we want.


this is what we've been doing for years. use _NET_STARTUP_ID as a definitive
(we launched this and thus we know the desktop file that was associated with
that launch - so just use that desktop file and ignore all else" or fall back
to _NET_WM_PID (track child pid from launch of desktop file) and if that
doesn't work - guess-o-rama based on WM_CLASS. it works really well 99% of the
time in regular desktop usage.

i see this property as yet another bit of info to add into the guessing
pipeline above. likely throw it in after the startup id matcheroo or the
pid match (as i'd prefer to use that first for the cases that people make custom
desktop files with different icons that launch the SAME binaries but with
different options, and using what the process provides is less accurate here)


The DBus goal is a nice goal for GTK+, but the reason most
applications won't rename is because lots of things have the .desktop
file stored somewhere (several programs switched over and then
switched back as their notification settings broke, users lost those
favorites in their shortcuts).

We've bought some time with
https://git.gnome.org/browse/gnome-shell/tree/js/ui/appFavorites.js#n9
but it just isn't a good idea.

That's why we realistically have the two IDs problem, and we need a
solution to that problem. We've already proposed an AliasFor=, but we
just need to write up a spec and implement it.

On Wed, Nov 11, 2015 at 8:21 AM, Allison Ryan Lortie <desrt desrt ca> wrote:

hi,

On Wed, Nov 11, 2015, at 10:21, Martin Graesslin wrote:

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:
_NET_WM_XDG_APPLICATION_ID

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


Sure.  This could be possible.  It may also make sense to treat this as
part of the desktop file spec and not the net-wm spec.  I was originally
going to draft this as a patch to that spec (where I am already
co-author).


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.


I think this is fine in theory, but practice gets a bit more hairy.

My main goal here is to replace the _GTK_APPLICATION_ID property with
something that is written down in a spec and generally useful to
everyone.  Our primary use for this property in gnome-shell is for D-Bus
communication, but it is also used for desktop file matching, in the
case where the desktop file name and D-Bus name are the same.

The desktop file spec already mentions that you should name your desktop
files according to the D-Bus style "org.foo.bar" and that you should own
the same bus name (if you take a name at all).

It is a somewhat common case, unfortunately, that these two things do
not match.  In that case, we fall back to other mechanisms for trying to
match the desktop file name, like wmclass.

It's true that we will never actually attempt to contact the application
on D-Bus using the given app ID unless some other properties are set
(providing the D-Bus path to communicate with, for example).  This
provides a nice way to provide an application ID even though the
application is not on D-Bus.

No matter what you do, you're going to run into a fairly large problem
with this proposal, however: who sets the property, and how do they know
which value to set it to?  Probably you don't want each individual
application setting an X property on each window it creates.  Do you
provide a toolkit API to help with that?  How does it look?

In our case (Gtk) we already have the application ID because we use this
to claim the D-Bus name.  It is only natural for us to assume that this
is equal to the desktop file ID, because this is what the desktop entry
spec recommends.  If you don't have this information, you're going to
need to provide an equivalent toolkit API for the app to use, and not
everyone will use it.

So from Gtk's standpoint the answer will be "we will set this to the
D-Bus name of the application, which hopefully corresponds to its
desktop file name, but might not".  The addition to the spec should be
worded in such a way that this is valid.

I understand that this doesn't correspond exactly to your original
intention with this addition, but I think your original intent is
unrealisable: you will either have many apps that provide nothing at
all, or you will have some apps that provide something other than the
desktop file name.

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


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


When dealing with names of files on a POSIX filesystem, "could be
anything" is actually the correct encoding. :)

Cheers
_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
https://mail.gnome.org/mailman/listinfo/wm-spec-list




-- 
  Jasper
_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
https://mail.gnome.org/mailman/listinfo/wm-spec-list




-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]