Proposed change to desktop-entry-spec: make StartupWMClass a "string(s)" field

Jasper St. Pierre jstpierre at mecheye.net
Tue Jan 27 11:10:25 PST 2015


Hi Andy,

StartupWMClass usage should be considered legacy. In order to compute a
mapping from window class to .desktop file, we need to read *all* files
from disk, which is super expensive to do first thing on boot.

I wouldn't be too happy modifying it so that we have to do *more* work to
make it work. I would rather work on a replacement so that we don't have to
do as much work to find a .desktop file from a window.

Adding a new X window property like _NET_WM_DESKTOP_ID would be more up my
alley, but I know Ryan isn't too happy with it, and is instead working on a
better proposal. CCing him to hear his current thoughts.


On Tue, Jan 27, 2015 at 1:01 PM, Andy <AndydeCleyre at gmail.com> wrote:

> Hi,
>
> I'm just following up with some more use cases. The KDE System Settings
> can be launched as a monolithic item, or alternatively each module can be
> launched independently. The full application window's class is
> "systemsettings" while the components' are "kcmshell4" -- both of these
> should be grouped and matched with the System Settings .desktop file, so it
> would be appropriate to set both window classes in the System Settings
> .desktop file.
>
> In looking for a solution to this StartupWMClass limitation, I came across
> folks asking the same questions two years ago:
> http://askubuntu.com/questions/248826/set-multiple-values-for-startupwmclass-to-group-under-same-launcher-in-unity
>
> From that post:
>
> '''
> I have a program (Android Virtual Device Manager) that launches
> 'sub-programs' (namely emulators or virtual devices) from within itself
> (also can be launched from else where). I want any instances of EITHER of
> these programs to be grouped under the same Unity icon.
>
> I have created a .desktop file to try and accomplish this but don't
> exactly know how to go about it. . . .
> I am assuming that I somehow need to set two values for StartupWMClass but
> have not been able to do it correctly (or know if it is a valid operation).
> I have tried, colon separated like environment variables, comma separated,
> quotes, etc and I cannot find any hints in the official documentation
> <http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html>.
>
> . . .
>
> Another, more pedantic, but probably more identifiable example is with
> Matlab. I am running 2013a and the splash screen that initially shows and
> the program have completely different WM_CLASS values. This means, when I
> click my launcher with StartupWMClass=com-mathworks-util-PostVMInit in it,
> the splash screen comes up with a different (default Unknown) Unity icon,
> while the rest comes up grouped under my launcher. . . .
>
> If I could specify something along the lines of:
>
> StartupWMClass=com-mathworks-util-PostVMInit&&MATLAB
>
> That would work perfectly (as both work separately) but I have no idea of
> the syntax, if it even exists. I just know nothing I have tried has worked
> thus far.
>
> Any help or a definitive answer either way would be great as I believe
> this is a pretty fundamental element of a well functioning desktop.
> '''
>
> Someone responded 4 months later with:
>
> '''
> Same problem for me with Starcraft II launched throw playonlinux. There is
> first a application launcher:
>
> (WM_CLASS(STRING) = "Blizzard Launcher.exe", "Wine")
>
> and then the game itself:
>
> (WM_CLASS(STRING) = "SC2.exe", "Wine")
> '''
>
> So there are clearly cases where this would help, and the limitation has
> been a known inconvenience for at least 2 years so far. Does anyone have a
> reason not to go forward allowing multiple values for StartupWMClass?
>
> Thanks for reading,
> Andy
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150127/744c0660/attachment.html>


More information about the xdg mailing list