Export display par ssh

Support Debian
#1

Bonjour,

j’ai un petit problème lorsque j’utilise l’export display par ssh pour afficher et utiliser sur mon laptop des applis lancées sur mon pc de bureau : leur apparence.

En effet, sur les deux machines, j’utilise KDE et si sur l’un comme sur l’autre, j’ai pu sans trop de mal donner une apparence correcte aux applis GTK, ça ne fonctionne pas en export display.

En résumé, tout fonctionne correctement sauf que l’affichage des applis est “moche”.

Configuration pour les 2 machines : Debian sid à jour, noyau 3.1.0-1-amd64.

Est-ce que quelqu’un aurait une solution ?

Merci d’avance.

#2

Ce fil m’intéresse car j’ai le même problème (même si, j’avoue, j’ai jamais essayé de le résoudre). Si ça peut donner des pistes j’utilise qtcurve comme thème, aussi bien pour KDE que pour les applis GTK.

#3

Exact, j’avais oublié de préciser, Qtcurve pour moi aussi.

En soi, ce n’est pas un problème mais bon, disons que ce serait un poil plus sympa d’avoir une apparence correcte.

#4

Personne n’a de piste ?

#5

Peut être un problème d’encodage. Tu as essayé de définir l’encodage sur utf-8 ? Il y a une option pour SSH qui permet de le définir lors de la connexion, regarde dans le manuel.
Plus largement ça pourrait être un problème de locales.

Mais je pense que ça doit en fait venir du fait que lorsque tu lances Xorg sur du SSH, ça prend les paramètres de Xorg pour l’écran n°2 (= l’écran distant), or il faut sûrement dire à GTK que l’écran 2 doit utiliser tel thème.
Si ce n’est pas ça, à mon avis ça s’en approche.

#6

[quote=“Cluxter”]Peut être un problème d’encodage. Tu as essayé de définir l’encodage sur utf-8 ? Il y a une option pour SSH qui permet de le définir lors de la connexion, regarde dans le manuel.
Plus largement ça pourrait être un problème de locales.[/quote]
Je doute fortement que ça soit ça, toutes mes machines sont configurées exactement pareil (full UTF-8, locale fr_FR). En plus j’ai un peu du mal à voir comment les locales pourraient influer sur le thème… Si c’était un problème d’encodage il y aurait d’autres soucis visibles (notamment sur les chaînes de texte contenant des caractères >= 128 qui s’afficheraient mal).

[quote=“Cluxter”]Mais je pense que ça doit en fait venir du fait que lorsque tu lances Xorg sur du SSH, ça prend les paramètres de Xorg pour l’écran n°2 (= l’écran distant), or il faut sûrement dire à GTK que l’écran 2 doit utiliser tel thème.
Si ce n’est pas ça, à mon avis ça s’en approche.[/quote]
Ça par contre c’est une piste à explorer ! Maintenant que j’ai un début d’os à ronger je vais regarder de ce côté et je vous tiens au courant. :wink:

Edit : je n’avais jamais réellement fait gaffe, mais même les thèmes Qt sont affectés, pas seulement GTK :

Pour info, le thème QtCurve est strictement identique sur les deux machines (j’ai recopié le fichier de config), la différence d’apparence entre les deux applis Qt (Local / SSH) est bien due au forwarding X via SSH.
Ok c’est beaucoup moins gênant pour les applis Qt, mais ça veut bien dire que le problème n’est pas lié à un toolkit graphique particulier.

Edit 2 : bon j’ai une piste : les variables d’environnement ! Un certain nombre de ces variables (toutes celles ayant trait à l’environnement graphique) ne sont pas définies du tout dans la session SSH.
Concernant GTK j’ai réussi à avoir un affichage normal en redéfinissant à la main, dans la session SSH, les variables GTK_RC_FILES et GTK2_RC_FILES à la même valeur qu’elles ont dans la session X du PC distant.
Concernant Qt, je ne sais pas trop quelle variable est concernée, une chose est sûre ce n’est pas QT_PLUGIN_PATH (j’ai testé sans résultat).

La vraie question est : comment faire en sorte que les bonnes variables soient définies automatiquement lors de la création de la session SSH ? Je ne suis pas certain du tout que ça soit possible car SSH n’est absolument pas dépendant d’une session X… :confused:

Edit 3 : toujours en bricolant les variables à la main, j’ai réussi à récupérer mon thème Qt en définissant uniquement la variable KDE_FULL_SESSION=true dans la session SSH :dance: Pas d’effets adverses constatés.
Avant que je m’attelle à automatiser quoi que ce soit, quelqu’un a une idée de comment/où sont définies les variables GTK_RC_FILES et GTK2_RC_FILES ? Histoire de ne pas coder en dur leurs valeurs, mais de récupérer ça en fonction des préférences de l’utilisateur…

#7

Bon, j’ai fait un grep sur /etc /home et /usr, aucun endroit où GTK_RC_FILES est défini, et le seul endroit où je trouve GTK2_RC_FILES (~/.kde/env/gtk-qt-engine.rc.sh) la valeur ne correspond pas à ce que me donne le shell…
Aucune raison que ça se trouve ailleurs que dans un de ces 3 dossiers, je sais plus où chercher. :angry-banghead:

#8

Je ne sais pas pourquoi (l’heure j’imagine…) mais lorsque j’ai parlé des locales je pensais en fait surtout aux variables d’environnement car elles ne sont pas définies lorsqu’on lance un 2ème serveur Xorg et donc on a ce genre de problèmes, ça m’est arrivé l’autre jour. Et les locales font partie des choses que l’on doit définir dans les variables d’environnement.

Car si le nom du thème est mal encodé, le système peut ne pas le reconnaître et donc utiliser l’interface par défaut. La première chose à vérifier lorsqu’on a un problème d’un élément introuvable ou qui ne se charge pas, ce sont les locales. Combien de fois je me suis retrouvé avec un fichier non chargé par un logiciel justement à cause d’un mauvais encodage !

#9

Effectivement, vu comme ça ton raisonnement se tient (même si ça ne m’est jamais arrivé autant que je m’en souvienne). :wink:
Mais bon entre temps j’ai trouvé la solution, reste plus qu’à l’automatiser pour pas avoir à saisir en dur les valeurs des variables GTK*_RC_FILES.

#10

Tu n’es pas le premier à se poser la question.
des solutions
commentcamarche.net/forum/af … nt-via-ssh

#11

Le problème c’est que ces variables en question n’apparaissent que dans une session X, alors que SSH ouvre une session TTY. Bref, ça aide pas, il faut bien les redéfinir “à la main” d’une manière ou d’une autre. La question sur laquelle je bloque n’est pas comment les redéfinir, mais de récupérer les préférences de l’utilisateur pour ces deux variables GTK*_RC_FILES. :frowning:

#12

Hello,

en effet, comme syam, en indiquant le chemin des variables d’environnement lors de la session ssh, j’arrive à avoir quelque chose de correct.

Il ne reste plus qu’à voir si c’est possible d’automatiser tout ça maintenant.

Dans tous les cas, merci :wink:

#13

Bon, après avoir à nouveau fait chauffer mon disque dur à coups de grep en tous genres, impossible de trouver où/comment ces variables GTK sont définies. :108
Comme ma patience a des limites, je me suis rabattu sur cette solution, à placer par exemple dans un nouveau fichier dans /etc/profile.d/ :

[code]#!/bin/sh

SSH login: KDE/GTK themes

if [ -n “$SSH_CLIENT” ]; then
export GTK_RC_FILES="/etc/gtk/gtkrc:$HOME/.gtkrc::$HOME/.kde/share/config/gtkrc"
export GTK2_RC_FILES="/etc/gtk-2.0/gtkrc:$HOME/.gtkrc-2.0:$HOME/.gtkrc-2.0-kde:$HOME/.kde/share/config/gtkrc-2.0"
export KDE_FULL_SESSION=“true”
fi[/code]
Ça marche pour moi, les chemins commençant par $HOME sont peut-être à adapter en fonction de votre config (à vérifier par rapport aux variables d’origine lors d’un login local sous X). Mais qui irait s’amuser à déplacer ces fichiers ailleurs de toutes façons ? :mrgreen:

Enfin ! Au revoir les fenêtres moches ! :041 :dance:

#14

Parfait, c’est exactement ce que je cherchais.

Merci beaucoup :slightly_smiling: