Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

gparted moche sur xfce

Christophe C

Ce n'est pas très important, mais gparted est particulièrement moche sur ma xfce (Xub 17.04). En fait son thème de fenêtre semble ne pas respecter le thème général que j'ai choisis pour mes mes fenêtres xfce (macbuntu). En fait il n'applique que très peu de thèmes xfce. La plupart le laissent indifférent 🙂 => ils ne changent pas son apparence. Quelques un (mais peu) le font : greybird, par exemple.

Les themes testés s'appliquent par contre très bien aux autres fenêtre de programmes sous xfce. Gparted est donc l'exception. Y a t'il un truc pour améliorer son intégration aux thèmes xfce ?

abelthorne

Généralement, ce genre de chose arrive quand le thème utilisé ne propose pas de version qui correspond au toolkit utilisé par un logiciel. Par exemple, logiciel en Gtk3 alors que le thème ne propose qu'une version Gtk2. Une autre possibilité, c'est qu'il te manque un moteur de thème dont dépend celui que tu utilises, ce qui peut être assez fréquent pour les thèmes installés manuellement.

Il vient d'où, ton thème Macbuntu ?

Christophe C

je ne sais plus. Un téléchargement quelconque.

Mais comme indiqué, les 3/4 des thèmes xfce que j'ai n'ont pas d'impact sur gparted, quand ils marchent très bien avec tout le reste. Ce n'est pas que macbuntu.

Sinon, j'ai bien les moteurs gtk2 et gtk3 d'installés. Bon, ce n'est pas très grave.

abelthorne

J'ai oublié un autre cas de figure : les thèmes installés au niveau utilisateur (dans ~/.local/share/themes) ne sont pas accessible par root, et donc les applis lancées en admin telles que GParted ne les trouveront pas et se retrouveront sans thème. Ça serait aussi le cas avec Synaptic, par exemple. Est-ce que par hasard ça correspondrait à ton problème ?

Christophe C

Aaaaah, oui, tu a raison, j'avais oublié ce piti gag. C'est vrai que gparted est une appli root, et que la grande majorité de mes thème sont dans le compte utilisateur.

Greybird est en compte système par contre, et lui il marche.

Je teste, mais c'est sûrement cela. Merci !

Christophe C

Voui, c'est bien cela. Re-merci !
Je modifie la doc.

abelthorne

Je ne sais pas si c'est très pertinent de le mentionner dans la doc (sur GParted, du moins), c'est un problème spécifique aux thèmes en général. D'autant que la façon normale d'installer des thèmes est via des paquets .deb (au niveau système), comme n'importe quel autre logiciel.

nam1962

Intéressant ! Merci 🙂

Christophe C

J'ai mis un passage très bref.

Oui, cela concerne tous les programmes en root, mais combien de programme en root l'utilisateur "normal" utilise t'il ? zéro. Et l'utilisateur (un peu) avancé : un seul, je pense : gparted. Un sudo thunar (ou nautilus) peut-être, mais très rarement.

Ca mérite bien 3 petites lignes.

Roschan

GParted, Grub Customizer, Synaptic, ...

Et je me rend compte qu'il n'y a pas de pages "thèmes" générale dans la doc, juste des sous-parties dans les articles traitant de DE spécifiques :/

[supprimé]

Merci pour l'info ça peu toujours servir . Je notes pour retrouver le post 🙂

Christophe C

Ah oui, synaptic. Damned, ça doit faire 5 ans que je n'y ait plus touché. Ça existe encore ? 😛

Mais tu as raison, gparted n'est pas le seul.

Bon, j'ai copié les thèmes (via un sudo thunar) que j'utilise de ~/.themes vers /usr/share/themes, et tout marche comme je le voulais.
Ça je ne l'ai pas mis dans la doc, ce n'est pas le genre de manip à encourager pour celui qui ne comprend pas ce qu'il fait.

abelthorne

Christophe C a écritAh oui, synaptic. Damned, ça doit faire 5 ans que je n'y ait plus touché. Ça existe encore ? 😛

Non seulement ça existe encore, mais c'est aussi probablement le meilleur gestionnaire de paquets qu'on ait sur Ubuntu.

nam1962

@christophe C : et avec

sudo cp -avr ~/.themes/.  /usr/share/themes/

choops

Christophe C a écritBon, j'ai copié les thèmes (via un sudo thunar) que j'utilise de ~/.themes vers /usr/share/themes, et tout marche comme je le voulais.
Ça je ne l'ai pas mis dans la doc, ce n'est pas le genre de manip à encourager pour celui qui ne comprend pas ce qu'il fait.

En fait, ça tient simplement du fait que un sudo te place dans l'environnement "root". Du coup, oui, tes thèmes placés dans /home/$USER/.themes/ ne s'appliquent pas aux applis lancées avec sudo. Donc soit tu les places dans /usr/share/themes/ comme tu l'as fait, soit tu continues à les mettre dans ton home mais tu crées un lien symbolique vers le dossier de ton home dans /root/, tu peux d'ailleurs faire de même pour les icônes et pour les polices :

sudo ln -s ~/.themes /root/.themes
sudo ln -s ~/.icons /root/.icons
sudo ln -s ~/.fonts /root/.fonts

A la limite cette manip qui consiste juste à faire des liens est plus sécure que d'aller directement toucher à des trucs dans /usr/share/

Christophe C

@choops. Oui, faire un lien symbolique est plus élégant. Et forcément moins dangereux.

Par contre pourquoi sudo ln -s ~/.themes /root/.themes ?
C'est plutôt sudo ln -s ~/.themes /usr/share/themes, non ? (édit : non ça marche pas)

abelthorne

Ne. Touche. Pas. À. /usr/share/themes.

L'idée de choops, c'est de faire un lien entre les thèmes de l'utilisateur root et l'utilisateur toi. Comme ça, quand tu deviens temporairement l'utilisateur root, les thèmes seront accessibles. Si tu "remplaces" /usr/share/themes par ton dossier perso, ça va être un beau bordel au niveau des permissions quand ton gestionnaire de paquets va vouloir manipuler ce qu'il y a dedans.

Personnellement, je préconiserais l'installation manuelle des thèmes dans /usr/share/themes, c'est l'endroit normal où on doit installer des données qui doivent être accessibles à tous les utilisateurs (par opposition à un utilisateur en particulier avec des données dans son dossier perso). D'autant que la bidouille avec un lien dans /root ne fonctionne que s'il y a un seul utilisateur (non-admin), ce qui est contraire à la façon de fonctionner de Linux : c'est un système pensé exclusivement pour être multi-utilisateurs donc on part du principe que tout doit être fait de façon à ce que ça fonctionne normalement dans ce contexte. Il n'y a pas spécialement de risques à copier manuellement les fichiers d'un thème dans /usr/share/themes à part si on installe ensuite le même thème via un paquet mais je pars du principe qu'à partir du moment où on se lance dans l'installation manuelle de fichiers dans le système, on s'en souvient et on ne fait pas n'importe quoi.

nam1962

Le -a de cp -a tient en principe compte des symlinks et des permissions

Christophe C

abelthorne a écritSi tu "remplaces" /usr/share/themes par ton dossier perso, ça va être un beau bordel au niveau des permissions quand ton gestionnaire de paquets va vouloir manipuler ce qu'il y a dedans

Si je le remplace, certainement. Mais je proposais simplement de mettre un lien symbolique de ~/.themes dans /usr/share/themes. Ce qui ne mettra sûrement pas le bordel dans /usr/share/themes ... simplement, cela ne fonctionne pas :cool:.

Si on veut faire des lien symboliques dans /usr/share/themes, il faut le faire thème par thème. Par exemple sudo ln -s ~/.themes/MacBuntu/ /usr/share/themes/MacBuntu. Pour un thème c'est simple, mais si on veut copier toute sa collection de 92 thèmes, c'est plus long 😛. Un script pourrais faire cela, forcément..
Le copier-coller de tous les thèmes, en dur, comme tu l'indiques (c'est ce que j'avais d'ailleurs fait) devient alors plus simple. Ou l'idée de choops.
A ce propos, tu dis

que la bidouille avec un lien dans /root ne fonctionne que s'il y a un seul utilisateur (non-admin)

Je suppose que c'est parce que si un autre utilisateur se met en root, le lien symbolique refusera de fonctionner vers un compte tiers ? C'est ça ? Pourtant, root accède bien à tous les utilisateurs, non ?

abelthorne

Christophe C a écritSi je le remplace, certainement. Mais je proposais simplement de mettre un lien symbolique de ~/.themes dans /usr/share/themes. Ce qui ne mettra sûrement pas le bordel dans /usr/share/themes ... simplement, cela ne fonctionne pas :cool:.

Si on veut faire des lien symboliques dans /usr/share/themes, il faut le faire thème par thème. Par exemple sudo ln -s ~/.themes/MacBuntu/ /usr/share/themes/MacBuntu. Pour un thème c'est simple, mais si on veut copier toute sa collection de 92 thèmes, c'est plus long 😛. Un script pourrais fair cela, forcément..

Des liens thème par thème, oui, ça fonctionne. Mais dans ce cas, quitte à taper une commande pour chaque thème, autant copier son dossier...

Et si tu as 92 thèmes, je pense que tu en as un peu trop. Je sais que tu exagères volontairement pour l'exemple mais il ne doit pas y avoir grand monde qui a plus de deux ou trois thèmes supplémentaires d'installés. Généralement, on ne change pas la gueule de l'interface tous les deux jours.

A ce propos, tu dis
que la bidouille avec un lien dans /root ne fonctionne que s'il y a un seul utilisateur (non-admin)
Je suppose que c'est parce que si un autre utilisateur se met en root, le lien symbolique refusera de fonctionner vers un compte tiers ? C'est ça ? Pourtant, root accède bien à tous les utilisateurs, non ?

C'est surtout que si tu as plusieurs utilisateurs, tu ne peux pas avoir des liens vers les thèmes de tous. Si Bob et Jean-Truelle ont chacun un compte sur une machine, root ne peut avoir un lien que vers le dossier themes de l'un ou de l'autre, on ne peut pas avoir un lien qui pointe vers plusieurs dossiers. Ça casse un peu l'idée du truc.

Plutôt que de mettre en place des bidouilles à base de liens dans /root, prenez l'habitude de manipuler Linux comme il a été conçu (des données sont spécifiques à un utilisateur ? elles vont dans son dossier perso ; elles doivent être accessible à tous les utilisateurs ? elle vont dans le dossier système correspondant). Réfléchissez, selon la situation, soit comme un utilisateur ("ce qu'il y a en-dehors de mon dossier personnel ne me concerne pas"), soit comme l'administrateur ("le système doit continuer à fonctionner exactement de la même manière si on ajoute ou qu'on supprime n'importe quel compte utilisateur"). Ça vous évitera des surprises résultant de situations bizarres.

Page suivante »