Bonjour bonjour !
Dans mon ~/.icewm/winoptions j’ai rajouté
[code]tint2.ignoreQuickSwitch: 1
tint2.ignoreWinList: 1
tint2.ignoreTaskBar: 1
conky.ignoreQuickSwitch: 1
conky.ignoreWinList: 1
conky.ignoreTaskBar: 1
[/code]
Ce qui est supposé, d’après la doc, ne pas afficher conky et tint2 dans le QuickSwitch (Alt+Tab) ni dans la liste des fenêtres. Or ça n’agit pas : ils apparaissent toujours.
Quelqu’un a déjà eu à faire à ça ?
[quote=“seb-ksl”]Bonjour bonjour !
Dans mon ~/.icewm/winoptions j’ai rajouté
[code]tint2.ignoreQuickSwitch: 1
tint2.ignoreWinList: 1
tint2.ignoreTaskBar: 1
conky.ignoreQuickSwitch: 1
conky.ignoreWinList: 1
conky.ignoreTaskBar: 1
[/code]
Ce qui est supposé, d’après la doc, ne pas afficher conky et tint2 dans le QuickSwitch (Alt+Tab) ni dans la liste des fenêtres. Or ça n’agit pas : ils apparaissent toujours.
Quelqu’un a déjà eu à faire à ça ?[/quote]
Bonjour,
et avec ignoreQuickSwitch=1
Héhé, déjà tenté 
Bon, j’ai avancé un peu.
Déjà, pour Conky il fallait bien écrire “Conky” et non “conky”. Pour ceux qui en douteraient encore, Linux est sensible à la casse
Par contre pour tint2, toujours rien à faire. Je pense que le problème vient de l’absence de WM_CLASS. Quand je fais un xprop sur tint2, il me renvoie :
seb@seb-desktop:~$ xprop
_ICEWM_TRAY(CARDINAL) = 0
_WIN_WORKSPACE(CARDINAL) = 0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_WIN_STATE(CARDINAL) = 1, 63
_WIN_LAYER(CARDINAL) = 2
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
WM_HINTS(WM_HINTS):
Client accepts input or input focus: False
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: -1078806024, -1220046860
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_BELOW
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 22, 0, 0, 0, 0, 0, 340, 1339, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 22, 0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK
_NET_WM_NAME(UTF8_STRING) = 0x74, 0x69, 0x6e, 0x74, 0x32
WM_NAME(STRING) = "tint2"
D’après la doc, il faut mentionner le WM_CLASS dans le winoptions, mais peut-on en assigner un à tint2 ? J’ai cru comprendre que les utilisateurs de tiling-WM avaient souvent à jouer avec ces WM_CLASS, vous avez peut-être des pistes ?
Bon, un petit UP en forme de début de réponse : tint2 se lance effectivement sans WM_CLASS, ce qui le rend “ingérable” pour IceWM qui ne reconnaît que WM_CLASS.
Du coup j’ai tenté de forcer le WM_CLASS de tint2 par un xprop -name tint2 -f WM_CLASS 8s -set WM_CLASS tint2 dans mon ~/.xinitrc, mais le timing est mauvais : IceWM se lance plus rapidement que tint2 et donc ne prend pas la modification en compte. Ceci dit ça fonctionne à la mano, si je lance tint2 puis xprop puis que je restart IceWM c’est bon, mais pas automatique pour deux sous.
J’ai vu aussi qu’il y avait un patch pour fixer le WM_CLASS, mais avant d’en arriver à recompiler, existe-t-il un autre moyen auquel je n’aurais pas pensé pour arranger ça ?
[quote=“seb-ksl”]Bon, un petit UP en forme de début de réponse : tint2 se lance effectivement sans WM_CLASS, ce qui le rend “ingérable” pour IceWM qui ne reconnaît que WM_CLASS.
Du coup j’ai tenté de forcer le WM_CLASS de tint2 par un xprop -name tint2 -f WM_CLASS 8s -set WM_CLASS tint2 dans mon ~/.xinitrc, mais le timing est mauvais : IceWM se lance plus rapidement que tint2 et donc ne prend pas la modification en compte. Ceci dit ça fonctionne à la mano, si je lance tint2 puis xprop puis que je restart IceWM c’est bon, mais pas automatique pour deux sous.
J’ai vu aussi qu’il y avait un patch pour fixer le WM_CLASS, mais avant d’en arriver à recompiler, existe-t-il un autre moyen auquel je n’aurais pas pensé pour arranger ça ?[/quote]Mettre un sleep dans ton .xinitrc après la ligne de xprop ?
C’est possible que deux secondes soient plus qu’il n’est nécessaire, à toi d’ajuster.
Merci pour ta persévérance 
J’avais déjà un peu tenté le sleep, j’ai retenté à différents endroits et avec/sans &, mais rien à faire… Je crois qu’en fait tint2 attend qu’IceWM soit lancé pour vraiment se lancer aussi. Du coup le xprop doit arriver avant même que tint2 soit lancé ou je sais pas…
[quote=“seb-ksl”]j’ai tenté de forcer le WM_CLASS de tint2 par un xprop -name tint2 -f WM_CLASS 8s -set WM_CLASS tint2 dans mon ~/.xinitrc, mais le timing est mauvais : IceWM se lance plus rapidement que tint2 et donc ne prend pas la modification en compte. Ceci dit ça fonctionne à la mano, si je lance tint2 puis xprop puis que je restart IceWM c’est bon, mais pas automatique pour deux sous.
J’ai vu aussi qu’il y avait un patch pour fixer le WM_CLASS, mais avant d’en arriver à recompiler, existe-t-il un autre moyen auquel je n’aurais pas pensé pour arranger ça ?[/quote]Je ne vois de solution plus propre que la recompilation qui elle, fixe les choses une bonne fois pour toute.
La solution moins propre serait dans ton .xinitrc, de lancer tint2, lui donner les propriétés correctes, lancer un mini script qui n’aurait d’autre utilité que de lancer IceWM une première fois puis de le tuer, et enfin lancer IceWM pour de bon avec tint2 bien paramétré.
Je sais que c’est pas très joli comme proposition, mais si tu veux éviter la recompil, faudra peut-être en passer par là,
jusqu’à que quelqu’un d’avisé voie le topic et propose une “vraie” solution.
J’avais déjà pensé au script aussi, mais ça devient vraiment crado. Donc s’il n’y a pas d’option magique pour assigner un WM_CLASS à un processus donné, je finirai par recompiler.
Merci pour l’implication en tout cas
Bon, la recompilation ne fonctionne pas. Étant donné que c’est un package de testing et que je suis sous stable, ça plante au moment du fakeroot qui me renvoie qu’il y a des dépendances non-satisfaites.
Par contre, plus bizarre, si j’en crois cette page le problème du WM_CLASS devrait être réglé depuis la version 0.6 de tint2. Quelqu’un qui l’utilise pourrait-il lancer un xprop et copier ici le résultat après avoir cliqué sur tint2 ?
Les dépendances manquantes ne sont pas forcément au décalage de version, mais juste au fait que tu compiles,
il doit sûrement te manquer les libs qui se terminent en “-dev”
J’ai regardé vite fait et il te faut tout ces paquets là :
libcairo2-dev, libpango1.0-dev, libglib2.0-dev, libimlib2-dev, libxinerama-dev, libxrandr-dev
Bon, j’ai retenté la compil’ et rien n’y fait. L’erreur qu’il me renvoie me fait penser qu’il veut que je passe en testing pour recompiler, ce que je ne ferai pas :
# fakeroot dpkg-buildpackage -b -uc
dpkg-buildpackage : définir CFLAGS à la valeur par défaut : -g -O2
dpkg-buildpackage : définir CPPFLAGS à la valeur par défaut :
dpkg-buildpackage : définir LDFLAGS à la valeur par défaut :
dpkg-buildpackage : définir FFLAGS à la valeur par défaut : -g -O2
dpkg-buildpackage : définir CXXFLAGS à la valeur par défaut : -g -O2
dpkg-buildpackage: paquet source tint2
dpkg-buildpackage: version source 0.7.1-1
dpkg-buildpackage: source changé par Daniel Moerner <dmoerner@gmail.com>
dpkg-buildpackage: architecture hôte i386
dpkg-checkbuilddeps : dépendances de construction non trouvées : debhelper (>= 7.0.50) libcairo2-dev libpango1.0-dev libglib2.0-dev libimlib2-dev libxinerama-dev libxrandr-dev
dpkg-buildpackage: avertissement: Dépendances de construction et conflits non satisfaits ; échec.
dpkg-buildpackage: avertissement: (Utilisez l'option -d pour forcer.)
Je lance un appel dans Pause café pour voir si les utilisateurs de tint2 ont tous ce problème de WM_CLASS alors qu’il est supposé réglé depuis la 0.6.
[quote=“seb-ksl”]Bon, j’ai retenté la compil’ et rien n’y fait. L’erreur qu’il me renvoie me fait penser qu’il veut que je passe en testing pour recompiler, ce que je ne ferai pas :
dpkg-checkbuilddeps : dépendances de construction non trouvées : debhelper (>= 7.0.50) libcairo2-dev libpango1.0-dev libglib2.0-dev libimlib2-dev libxinerama-dev libxrandr-dev[/quote]Ce que je comprends de la ligne ci-dessus est que ta version de debhelper est trop basse mais que les autres paquets :
ibcairo2-dev libpango1.0-dev libglib2.0-dev libimlib2-dev libxinerama-dev libxrandr-dev ne sont même pas installés, je me trompe ?
Si il s’agit juste de debhelper, le système ne se trouverait pas spécialement boulversé par une version un peu plus élévée.
Le problème c’est que je suis à peu près sûr que quand j’aurais installé les libs il me dira aussi qu’elles sont trop anciennes… Je vais tenter pour voir.
Ouais non, c’est le boxon dans les dépendances rien que pour installer les libs. Je laisse tomber la compil.
Pour ceux que ça intéresserait, la solution est simplement de passer à la version SID de tint2 qui, elle, possède effectivement un WM_CLASS bien renseigné.