Définissez plusieurs valeurs pour StartupWMClass (à regrouper sous le même lanceur dans Unity)


20

Ceci est un exemple spécifique d'un problème générique pour lequel je n'ai pas encore trouvé de solution.

J'ai un programme (Android Virtual Device Manager) qui lance des sous-programmes (à savoir des émulateurs ou des périphériques virtuels) à partir de lui-même (peut également être lancé ailleurs). Je souhaite que toutes les instances de l'un ou l'autre de ces programmes soient regroupées sous la même icône Unity.

J'ai créé un .desktopfichier pour essayer d'accomplir cela, mais je ne sais pas exactement comment m'y prendre . Le fichier de bureau est le suivant:

#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Name=Android Virtual Device
Icon=/home/ben/.icons/android.svg
Exec=/home/ben/usr/bin/android avd
StartupWMClass=Android Virtual Device Manager

D'après ce que je comprends, StartupWMClassc'est ce que je dois définir pour y parvenir correctement. J'ai obtenu les deux noms de classe ('Android Virtual Device Manager' et 'emulator64-arm') à l'aide xprop WM_CLASSdes fenêtres représentatives. Les deux fonctionnent individuellement (l'icône du lanceur est correctement attachée au programme, quelle que soit la façon dont il est lancé), mais je ne peux pas le faire fonctionner pour les deux.

Je suppose que j'ai en quelque sorte besoin de définir deux valeurs pour StartupWMClassmais je n'ai pas pu le faire correctement (ou savoir si c'est une opération valide). J'ai essayé, séparé par deux points comme les variables d'environnement, séparé par des virgules, des guillemets, etc. et je ne trouve aucun indice dans la documentation officielle .

Aucune suggestion?

ÉDITER:

Un autre exemple, plus pédant, mais probablement plus identifiable est avec Matlab. Je lance 2013a et l'écran de démarrage qui s'affiche initialement et le programme ont des WM_CLASSvaleurs complètement différentes . Cela signifie que lorsque je clique sur mon lanceur avec StartupWMClass=com-mathworks-util-PostVMInit, l'écran de démarrage affiche une Unityicône différente (par défaut inconnue) , tandis que le reste apparaît groupé sous mon lanceur.

En utilisant xprop WMCLASSet en cliquant d'abord sur l'écran de démarrage, puis en répétant avec une Matlabsession active , j'obtiens la sortie de terminal suivante:

ben@ben-OptiPlex-9010:~$ xprop WM_CLASS
WM_CLASS(STRING) = "MATLAB", "MATLAB"
ben@ben-OptiPlex-9010:~$ xprop WM_CLASS
WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "com-mathworks-util-PostVMInit"

Si je pouvais préciser quelque chose comme:

StartupWMClass=com-mathworks-util-PostVMInit&&MATLAB

Cela fonctionnerait parfaitement (car les deux fonctionnent séparément) mais je n'ai aucune idée de la syntaxe, si elle existe. Je sais juste que rien de ce que j'ai essayé n'a fonctionné jusqu'à présent.

Toute aide ou réponse définitive dans les deux cas serait formidable car je pense que c'est un élément assez fondamental d'un bureau qui fonctionne bien.


1
Pourriez-vous obtenir des conseils des tiroirs ?

1
J'ai regardé les vidéos de Drawersce lien et à partir de ce qu'elles montrent, il regroupe simplement les liens, lorsque vous cliquez sur un sous-élément, il est toujours créé avec sa propre icône dans le Unitylanceur, ce que j'essaie d'arrêter
BT

Réponses:


8

Même problème pour moi avec Starcraft II a lancé le lancer playonlinux. Il y a d'abord un lanceur d'applications:

  • (WM_CLASS(STRING) = "Blizzard Launcher.exe", "Wine") puis le jeu lui-même:

  • (WM_CLASS(STRING) = "SC2.exe", "Wine")

Je suppose que wine définit la classe avec l'exécutable binaire.

J'ai jeté un œil au code bamf (bamf_matcher.c, méthode insert_desktop_file_class_into_table ()):

  • Il existe une carte qui fait l'association entre un fichier de bureau et une et une seule classe,
  • La clé StartupWMClass est lue avec g_key_file_get_string () qui n'est pas conçu pour renvoyer une liste de chaînes,
  • g_key_file_get_string_list () pourrait le faire mais les développeurs de bamf n'ont pas conçu le framework pour pouvoir associer plusieurs classes à un seul fichier de bureau.

Dans mon cas, je triche en créant 2 fichiers de bureau avec les mêmes clés mais StartupWMClass. Ce n'est pas parfait car j'ai toujours 2 icônes Uniy dans le lanceur mais l'important est que je sais pourquoi :-).


Cela semble très prometteur, j'ai posé une question pour essayer d'obtenir leur confirmation, mais toujours pas de réponse pour le moment ...
BT

1
Ce n'est pas tout à fait une réponse. La réponse est "vous ne pouvez pas" car la spécification du fichier de bureau fait de cette valeur une chaîne unique et non une liste de chaînes (c'est pourquoi bamfdaemon utilise get_string () et non get_string_list () pour cette valeur).
dobey le

1

Je sais que cette question est vraiment ancienne, mais après avoir traversé le même problème, je pense que j'ai finalement créé une solution de contournement pour cela, et j'ai décidé de partager avec toute personne ayant ce problème:

Comme nous ne pouvons pas définir plusieurs WMClasses pour un seul fichier .desktop, pourquoi ne pas définir toutes les fenêtres sur un seul WMClass?

Nous pouvons faire quelque chose comme ça (Évidemment, remplacez Window 1, Window 2et potatoesavec vos noms de fenêtres et WMClass souhaité):

xprop -name "Window 1" -f WM_CLASS 8s -set WM_CLASS "potatoes"

xprop -name "Window 2" -f WM_CLASS 8s -set WM_CLASS "potatoes"

Et sur le fichier .desktop, nous pouvons le faire: StartupWMClass=potatoes

Tadam! Toutes les fenêtres sont maintenant regroupées.
Mais bon, faisons-nous cela manuellement à chaque ouverture du programme? Bien sûr que non.

Nous pouvons simplement créer un script bash qui le fait automatiquement toutes les demi-secondes:

while true
do
    xprop -name "Window 1" -f WM_CLASS 8s -set WM_CLASS "potatoes"
    xprop -name "Window 2" -f WM_CLASS 8s -set WM_CLASS "potatoes"
    sleep 0.5
done

Et enfin, définissez le .sh que nous avons créé pour qu'il s'exécute à chaque démarrage du système d'exploitation: Capture d'écran

J'espère que ma réponse sera utile à tous ceux qui parcourent cette question.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.