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