<#secure method=pgpmime mode=sign>
On 14 mar 2003, ploum@mitose.net verbalised:
> C'est tout simplement du à la définition d'un window manager ! Il
Oui.
[...]
> Ce problème est aussi sur les multi-bureaux de windows et à priori de
> n'importe que Window manger.
>
> Le seul moyen pour éviter cela serait que chaque commande prévienne
> le window manager qu'elle va lancer une application graphique ou que
> chaque processus soit assigné à son desktop de départ.
Oui
> C'est à mon avis une belle folie de tenter de coder ça, et ça n'en
> vaut à mon avis pas la peine !
Absolument pas ! Par exemple moi j'utilise Ion[1], et il gère ça de
manière très "triviale". Bon d'accord ça ne correspond pas tout à fait
à ce que l'initiateur de ce thread voulait faire mais bon :) En fait
_tous_ les windows manager dialoguent avec Xwindow par l'intermédiaire
d'atomes que X met à disposition. C'est là qu'en fait il suffit
d'agir. Pour "cabler" le lancement d'une appli quelconque afin de la
mettre dans un bureau Y, il suffit d'en connaître un minimum sur
l'appli en question. Xwindow permet par exemple de connaître la classe
d'un client par l'atome WM_CLASS. Il suffit donc de manipuler cet atom
pour dire à un WM que chaque client répondant à cet attribut doit se
lancer à tel endroit.
,----[ Exemple de Xprop ]
| _ION_FRAME_ID(INTEGER) = 4106
| WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW
| WM_STATE(WM_STATE):
| window state: Normal
| icon window: 0x0
| WM_LOCALE_NAME(STRING) = "C"
| WM_CLASS(STRING) = "aterm", "XTerm"
| WM_HINTS(WM_HINTS):
| Client accepts input or input focus: True
| Initial state is Normal State.
| window id # of group leader: 0xa00002
| WM_NORMAL_HINTS(WM_SIZE_HINTS):
| program specified minimum size: 28 by 18
| program specified resize increment: 7 by 14
| program specified base size: 21 by 4
| window gravity: NorthWest
| WM_CLIENT_MACHINE(STRING) = "fxgs"
| WM_COMMAND(STRING) = { "aterm" }
| WM_ICON_NAME(STRING) = "zedek@fxgs <xprop> /mnt/usbkey/emacs"
| WM_NAME(STRING) = "zedek@fxgs <xprop> /mnt/usbkey/emacs"
`----
Toujours dans Ion, il suffit de mettre dans un fichier de conf qu'un
client C, doit se placer dans une target T et voila le tour est joué.
C'est bien pratique par exemple pour les gens qui utilisent des applis
comme Gimp, xmms et autres du style. Ca permet par exemple d'avoir des
frames dédiées à chaque appli.
Voici par exemple, une bidouille pour avoir une frame dédiée à XMMS:
,----
| winprop "xmms.XMMS_Player" {
| transient_mode on
| target "xmms"
| }
| winprop "xmms.XMMS_Playlist" {
| transient_mode off
| target "xmms-playlist"
| }
| winprop "xmms.XMMS_Preferences" {
| transient_mode off
| target "xmms-equalizer"
| }
| winprop "xmms.XMMS_Equalizer" {
| transient_mode off
| target "xmms-equalizer"
| }
`----
Chaque fenêtre de l'appli va dans sa propre cible. On se base donc sur
le WM_CLASS de chque fenêtre de xmms (winprop). A noter que cet
exemple ne marche plus sur la version de dev (quelques petites choses à
modifier mais rien de bien méchant en fait). A noter aussi que rien
n'empêche d'éparpiller les target sur plusieurs frame (bureau pour les
wm conventionnels).
Voila j'espère que j'ai pas été trop c... :)
zeDek
Footnotes:
[1] http://modeemi.cs.tut.fi/~tuomov/ion/
--
"Sie werden lachen, ich kann überhaupt nicht lesen."
Revisionist Manfred Koch erlaeutert die Probleme der
Ewiggestrigen in dsp*
Attachment:
pgpCSm1d3Df0K.pgp
Description: PGP signature