Xfce 4.16 est désormais disponible. Nous vous proposons une traduction de l’annonce et de la visite guidée, disponibles sur le site officiel.
Sommaire
- Préambule : un petit bilan
- Nouvelles icônes par défaut
- Gestionnaire de paramètres
- Applications par défaut
- Gestionnaire de fichiers
- Tableau de bord
- Gestionnaire d’alimentation
- Boite de dialogue « À propos »
- Gestionnaire de fenêtres
- En outre
- Bilan
Cette visite vous fera découvrir les nouvelles fonctionnalités majeures de Xfce 4.16. Et elles sont nombreuses !
Pour la liste complète des modifications, consultez le journal des modifications.
Préambule : un petit bilan
Fruit d’un an et quatre mois de travail, c’est un nouveau record de rapidité pour ce projet qui était habitué à deux ans minimum entre chaque nouvelle version stable. Mais cela ne tient pas au hasard, car les méthodes de développement ont changé. Fini l’entre-soi entre une dizaine de développeurs, le projet s’est ouvert bien plus qu’auparavant aux contributeurs externes en baissant la barrière à l’entrée.
Une migration vers GitLab, et une image docker plus tard, l’intégration continue a été mise en place et les contributions externes sont désormais à un niveau record pour ce projet. Pour donner une idée, bien qu’elles ne soient pas toutes des contributions externes, il y a eu environ 288 demandes d’intégration de code acceptés ou rejetés rien que pour le cœur des composants Xfce. Ce qui fait que malgré le temps de développement bien plus court, le journal des changements de Xfce 4.16 est plus imposant que pour Xfce 4.14 !
Mais assez de préambules, voici les principales nouveautés.
Nouvelles icônes par défaut
Pendant très longtemps, Xfce utilisait un mélange hétérogène entre les icônes du projet Tango et d’autres icônes grappillés à droite et à gauche, sans convention aucune. La charge revenait aux distributions de rendre cela davantage acceptable. C’est fini !
Afin de rendre l’environnement plus attractif et de renforcer son identité visuelle, nous avons créé de nouvelles icônes pour toutes nos applications principales et les avons basées sur une palette partagée pour assurer la cohérence. Nous avons également défini d’autres contraintes (implicites) de conception, en suivant vaguement les principes du thème Adwaita du projet GNOME.
La palette suivante en est la base :
Gestionnaire de paramètres
Le gestionnaire de paramètres a reçu une nouvelle apparence pour sa barre de recherche, qui peut maintenant être cachée de façon permanente. En outre, ses capacités de recherche ont été améliorées en valorisant la partie « Commentaires » du fichier de lancement de chaque outil (fichiers .desktop).
Achevant le passage à GTK3 réalisé lors de la mise au point de la version précédente de Xfce, tous les outils qu’il présente utilisent désormais des décorations de fenêtre côté client.
Applications par défaut
Ce nouvel outil de configuration représente une fusion entre les « Paramètres MIME » et les « Applications préférées » précédemment disponibles. En regroupant les deux dans un même endroit, les utilisateurs peuvent plus facilement définir les applications par défaut pour traiter certains types de fichiers.
Préférences d’affichage
Pour mieux prendre en charge les écrans à haute densité – qui existent en différentes tailles et densités – nous avons ajouté une mise à l’échelle fractionnaire basée sur l’extension RandR de X11. De plus, le mode d’affichage natif est maintenant marqué d’un astérisque et les rapports d’aspect sont affichés en fonction des résolutions d’affichage.
L’utilisation d’une mauvaise configuration pouvait générer une mauvaise disposition du (ou des) tableaux de bords. Cela a été corrigé.
Raccourcis clavier
Afin de faciliter la vie de nos utilisateurs, nous avons ajouté des raccourcis clavier par défaut, par exemple pour la gestion des fenêtres par pavage de Xfwm, ou pour ouvrir Thunar. Le style visuel de la boîte de dialogue a également été mis à jour.
Gestionnaire de fichiers
Dans les dialogues de copie et de déplacement de Thunar, les utilisateurs peuvent maintenant facilement interrompre l’opération sur le fichier concerné. En outre, la prise en charge du transfert de fichiers en file d’attente, la mémorisation des paramètres d’affichage par dossier et la prise en charge de la transparence dans les thèmes Gtk ont été ajoutées.
Thunar a aussi reçu une liste gargantuesque de petites corrections.
Tableau de bord
Le tableau de bord a reçu quelques mises à jour notables, une animation lors de sa réduction, et un nouveau plugin 'Barre de statut'Status Tray). Ce dernier affichait uniquement les applications compatibles avec l’interface de programmation 'systray' traditionnelle. Désormais, il comprend aussi la prise en charge moderne des applications utilisant l’API StatusNotifier (provenant de KDE).
En outre, la prise en charge du mode sombre, des lanceurs affichant des actions supplémentaires sur le clic droit, des boutons de fenêtre offrant la possibilité de 'Lancer une nouvelle instance…' et bien plus encore, ont été ajoutés.
Gestionnaire d’alimentation
La boîte de dialogue des paramètres du gestionnaire d’énergie a été réorganisée et affiche désormais au choix le mode « sur batterie » ou « branché », au lieu des deux dans un immense tableau.
Boite de dialogue « À propos »
Non seulement l’onglet 'À propos' (About) a été retravaillé pour être plus attrayant visuellement et plus facile à lire, mais un onglet séparé montrant des informations de base sur le système de l’utilisateur a également été ajouté.
Gestionnaire de fenêtres
Le gestionnaire de fenêtres a reçu de nombreuses corrections dans sa gestion de la composition et son usage des extensions OpenGL.
De plus, si un écran primaire a été défini, la boîte de dialogue Alt-Tab ne s’affiche plus que sur cet écran. Par ailleurs, de nouvelles options permettant d’agrandir le curseur avec le reste de l’affichage, ainsi qu’une option permettant de conserver les fenêtres réduites dans la liste des plus récemment utilisées rendent la gestion des fenêtres plus pratique.
En outre
Bureau
xfce4-desktop a surtout reçu de petites améliorations et corrections, et est davantage stable. Il a aussi reçu un nouveau fond d’écran !
Le menu par défaut (nommé garçon) ne démarre plus les applications comme étant des processus fils du tableau de bord. Ainsi un crash de l’application n’entraîne plus avec lui la disparition du tableau de bord.
Gestionnaire de sessions
La prise en charge de GPG 2.1 a été améliorée, et le dialogue de paramètres est davantage lisible.
En vrac
xfce4-appfinder permet désormais de chercher en filtrant par "frecency", une combinaison de la fréquence et de la date de dernière utilisation des applications.
Mousepad l’éditeur de textes de Xfce, a reçu de nombreuses corrections le rendant bien plus stable, et permet notamment une recherche de texte sans bloquer son interface graphique.
xfdashboard et beaucoup d’autres greffons (comme xfce4-calculator-plugin) ont aussi publié de nouvelles versions majeures en même temps que Xfce. Pour rappel, xfdashboard est un greffon qui propose une vue en tableau de bord des applications lancées. Il s’inspire principalement du dashboard du bureau GNOME ou du Mission Control de macOS, et peut être entièrement piloté au clavier.
Bilan
Longtemps pouvant être considéré comme moribond et refermé sur lui-même, le projet Xfce a réalisé ces dernières années un véritable tour de force. Cela fait vraiment plaisir à voir, et personnellement m’a convaincu de rester définitivement. En effet, si LXQt ou MATE étaient tentants dernièrement face aux vieux bugs qui ne bougeaient pas, ce n’est plus du tout le cas.
Plus qu’une chasse aux bugs, c’est un remaniement complet auquel nous avons affaire, quand on compare à Xfce 4.12.
Vive Xfce ! Et bonnes fêtes !
Aller plus loin
- Présentation sur Xfce.org (270 clics)
- Journal des modifcations (27 clics)
- Annonce sur Xfce.org (53 clics)
- Projet sur GitLab (pour les développeurs) (31 clics)
- Container Docker (pour les développeurs) (60 clics)
# Le lecteur multimédia de Xfce (nommé Parole) 4.16 arrive bient̂ôt
Posté par xcomcmdr . Évalué à 5.
Parole 4.15 (version de développement il y a quelques heures) vient d'être annoncé.
Au menu:
* Une bien meilleure compatibilité avec les DVD Video (notamment les menus)
* Une playlist améliorée
* des dialogues revisités
Source:
https://fossbytes.com/xfces-parole-media-player-4-15-0-released-with-improved-dvd-support/
Parole est toujours basé sur GStreamer.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 28 décembre 2020 à 12:04.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Décorations de fenêtres côté client, une régression
Posté par Arthur Accroc . Évalué à 10.
Pour moi aussi les décorations de fenêtres côté client sont une régression.
D’abord parce que quand un logiciel est planté, c’est mieux de pouvoir quand même manipuler sa fenêtre, pas comme sous Windows. Les décorations gérées par le gestionnaire de fenêtres garantissent cela (on peut heureusement aussi faire un clic droit sur le titre de la fenêtre dans la barre des tâches, mais c’est moins pratique).
Ensuite, parce que si on utilise des logiciels pas tous fournis par l’environnement graphique, la décoration par le gestionnaire de fenêtres assure au moins un minimum de cohérence fonctionnelle (les mêmes boutons du même côté) et de style. Cohérence qu’on avait finalement plus sous Linux que sous Windows.
Aussi, parce que ça multiplie le code (notamment pour les logiciels qui ne viendront pas tous du même environnement), donc l’empreinte mémoire et les risques de bugs.
Aussi, parce que comme sur Gnome, la barre de titre est inutilement haute, alors que les écrans notamment de portables ont tendance à perdre en hauteur ce qu’ils gagnent en largeur.
Enfin, parce que j’utilise un thème de gestionnaire de fenêtres qui met nettement en valeur la fenêtre sélectionnée. Ça limite le risque de taper des trucs dans une mauvaise fenêtre. Remarquez par exemple qu’une demande de mot de passe dans un terminal n’affiche rien ; du coup, si on le tape ailleurs, on s’en aperçoit d’autant moins…
Je sais que les décorations côté client sont à la mode, sous l’influence de Wayland et de Gnome, mais ça n’en fait pas une bonne chose pour autant (« Mangez de la merde : 90 milliards de mouches ne peuvent pas se tromper ! »).
À mon sens, le choix des développeurs de Wayland qu’il en fasse le moins possible et de déléguer presque tout aux clients est de très loin leur choix le moins judicieux.
Bon, ça n’est pas une catastrophe pour moi, vu que la plupart des logiciels que j’utilise (logiciels avec fenêtre, donc sans compter les applets du gestionnaire de fenêtres) ne viennent pas de Xfce. Mais je vais peut‐être quand même réessayer de trouver un thème sombre pour Mate, à supposer qu’il n’ait pas aussi été contaminé par cette mode.
Aparté : il y a peu, je partageais un avis avec Zenitram, et maintenant avec yPhil. En plus de la pandémie qui rend déjà l’année franchement bizarre pour tout le monde, c’est une fin d’année bizarre pour moi…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par freem . Évalué à 9.
Le fait qu'ils ne s'occupent pas des décorations de fenêtre ne me choque pas, en soit.
Du peu que je connais, rien ne semble empêcher l'implémentation du paradigme:
Par flemme, tout le monde construit la logique de la gestion des fenêtre dans le serveur graphique, mais je ne vois rien qui empêche de split la chose. En fait, ça serait probablement, la meilleure chose à faire: moins de code dans l'une des parties les plus critiques, qui pourrais (devrais?) ne faire que gérer le respawn de certains services critiques (s'ils existent: le wm, un VNC en entreprise par exemple, un presse-papier, etc) et leur donner les informations dont elles ont besoin (principalement la position et les dimensions des fenêtres, en fait, probablement aussi le temps sans que la fenêtre ait été actualisée, le focus, et 2-3 bricoles?).
Le «seul problème» ici, bien sûr, c'est qu'il est nécessaire de construire un protocole entre
wayland-serverdetwindow-manager, ainsi, forcément, qu'entre le wm et le wd.Avoir ces protocoles séparés ne me choque pas plus que ça, puisque ça permets notamment que, le jour ou wayland sera moisi parce qu'on aura de nouveaux usages, on pourra peut-être ne changer que le coeur, le reste fonctionnerait potentiellement encore, chose qui ne semble pas vraie sous X11.
Le fait est par contre que les bibliothèques (gtk et qt) ont choisi d'embarquer la décoration côté client: c'est plus simple pour aller vite, je dirais.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 28 décembre 2020 à 17:58.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Et on appelerio ça xdg-decoration ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par saltimbanque (site web personnel) . Évalué à 3.
Déjà je n'ai pas de plantage sous Windows. Ensuite si j'ai un soft qui plante, devoir bouger ma souris n'est pas le problème…
cadet soucis
C'est effectivement dommage qu'il n'y ait pas de paramètre aisément accessible. Il doit falloir passer le css et donc le thème j'imagine.
Mais justement l'intérêt des CSD est de gagner de la place en hauteur. Par exemple le navigateur fout sa barre d'onget dans la barre de titre. Ou le navigateur de fichier y met sa barre d'outil. Deux barres en une! même si elle est deux pixels plus haute, au final on a à la fois plus d'espace et de place.
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par gpe . Évalué à 3. Dernière modification le 26 janvier 2021 à 11:19.
Sauf que ça rend le déplacement des fenêtres pénible car la zone pour le faire est minuscule et que par exemple sous gnome il est difficile de voir la fenêtre qui a le focus.
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par ff9097 . Évalué à 1.
Le client doit laisser un minimum de place pour manipuler la fenêtre, de mémoire sous Gnome ça ne m'a jamais posé problème. Quant au focus, c'est un style différent à appliquer. Tout ça est un peu léger pour justifier cette barre de titre.
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par jyes . Évalué à 5.
À appliquer par qui ? Les WM qui s’occupent des décorations le font aisément, mais avec les CSD c’est aux applis elles-mêmes de montrer si elles ont le focus ou non, donc c’est assez facile de perdre 1 cette information visuelle pourtant bien utile.
ou d’avoir un signal visuel différent par appli ce qui revient au même. ↩
[^] # Re: Décorations de fenêtres côté client, une régression
Posté par omer666 . Évalué à 3.
Je comprends que les décorations côté client n'aient pas que des avantages, néanmoins je n'ai jamais eu de soucis à manipuler les fenêtres des logiciels plantés, et je trouve ça tout aussi (voir plus) ergonomique que les décorations côté serveur.
Pour moi c'est plutôt la réaction inverse, maintenant quand je me retrouve sur un bureau avec une barre de titre classique + menu + barre de boutons + barre d'état en bas, j'ai du mal à trouver ça esthétique ou même pratique à utiliser.
[^] # Re: B-bye, Xfce
Posté par xcomcmdr . Évalué à 9.
Ça ne concerne que les outils propres au Gestionnaire de paramètres de Xfce.
Thunar ni xfce4-terminal n'en font pas partie.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: B-bye, Xfce
Posté par zurvan . Évalué à 5. Dernière modification le 29 décembre 2020 à 15:29.
j'aime assez l'idée de xfce, mais en pratique si pour moi il ressemble un peu à Mate, je ne vois justement pas l'intérêt de l'utiliser, je ne le trouve pas vraiment plus léger que Mate, et les logiciels intégrés sont quand même moins bien, par exemple Thunar ne permet pas de scinder une fenêtre en deux (avec un panneau supplémentaire) comme le fait Caja.
Essayons d'être un minimum positif tout de même, le nouveau thème avec les icônes sont très chouette !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: B-bye, Xfce
Posté par FredTux . Évalué à 1.
Bonjour,
XFCE existe depuis 1996 donc bien avant mate. ;)
J'adore XFCE qui est bien pensé, stable, léger et avec tous les bons outils.
Pour moi Mate c'est un fork buggé de Gnome 2.x
Pour moi c'est le contraire, Mate a été créée pour les nostalgiques de Gnome 2.x,
sans pour autant arrivé à faire une interface stable et utile.
Tout ceci prouve qu'il ne faut pas se poser de question, chacun voit midi à sa porte.
Quelque chose est vu bien ou pas par certain et pas par d'autres, tout ce choix
du logiciel libre est enrichissant.
# Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par freem . Évalué à 5.
Donc, si je comprend bien, le tableau de bord plantait quand un processus fils crashait, et la réponse à été de détacher les processus fils?
Pourquoi pas, en soit, parce que je pense qu'en effet, ce n'est pas le rôle du tableau de bord de gérer les applications. Par contre, j'ai déjà eu le cas (à plusieurs reprises, même, et 99% du temps avec des navigateurs web, 1 fois avec claws) d'applications qui n'ont plus de fenêtre, ce qui est très bien pour un certain nombre d'applications (daemons) mais très chiant pour des applications graphiques, comme une application ncurses qui ne se fermerait pas quand stdout est fermé…
Bref, je présume que du coup la gestion du processus remonte jusqu'à PID1? Ou y-a-t-il un processus avant qui récupère la parenté, et éventuellement maintiens (je ne sais pas si c'est possible) la garantie qu'il est possible d'interagir avec la-dite application?
Honnêtement, je ne sais pas ce qu'il est possible de faire dans ce domaine, mais je me pose de plus en plus la question de la fiabilité des applications interactives: comment réagir en cas de problème (race condition, "perte" d'affichage graphique, etc)? Quelles solutions techniques théoriques et pratiques y a-t-il actuellement?
Le but n'est pas de jeter la pierre à xfce pour ce choix, loin de la, juste de profiter de l'occase pour savoir comment ce genre de situations (rares, certes) sont gérées.
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par barmic 🦦 . Évalué à 4.
C'est forcément l'init qui récupère ça.
Ça veut dire quoi maintenir une interaction possible ? Ton programme ne veux plus réagir, on ne peut pas l'y contraindre. A lui d'avoir différentes interfaces si nécessaire (graphique, dbus, une socket unix ou tcp, un pipe nommé,…).
Tu demande comment faire pour qu'une application buguée réagisse bien ? Remonter un bug ou un patch.
Balancer un signal. Si le processus a prévu un handler c'est cool sinon ça te permettra de le tuer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par freem . Évalué à 5.
Certes. Mais du coup, je me demande justement si c'est pertinent.
Je voulais dire, que si le programme ne peut plus interagir, autant le tuer, et c'est pas le job de PID1 d'être capable de vérifier ça.
Ok. Donc, les watchdog, ça sert à rien, revenons à sysVinit (parce que oui, l'intérêt majeur de systemd (et d'autres) est bien de proposer un mécanisme de watchdog logiciel). Quand ça crash, on fait un déplacement (allez, 300 bornes, c'est rien…) et on fait un rapport de bug ou on patche, en espérant qu'il n'y ait plus de freeze.
En fait, même les containers, ça sert à rien: s'il y a une faille, on fait un rapport de bugs et/ou corriger le problème.
Perso, ma solution dans ces cas la, c'est d'essayer de revenir a du moins accéléré, moins performant, plus cher (en temps immédiat de dev) mais plus simple, plus maintenable et plus fiable (en gros, du KISS, qui a un réel coût).
C'est ce que je craignais… perso, j'aimerai un système qui fasse que l'application crash (parce que du coup on peut relancer) quand son «descripteur de fichier graphique» n'est plus fonctionnel.
J'ai vécu le cas, sur le bureau, c'est pas trop grave (avez-vous pensé a rebooter?), et sur de l'embarqué, à plus de 50km du bureau, accès via réseau téléphonique radio seulement, déjà nettement plus chiant (l'utilisateur ne peux pas rebooter). En vrai, la solution, ça a été de revenir aux bases: ce bon vieux framebuffer pour le graphisme, avec rendu logiciel (jusque 10ms par trame, sur un CPU type intel), et libinput pour le tactile. Et pour le texte, ben, la fonte au format PSF (v1 ou v2): ça va qu'on reste dans les zones latines quoi…
C'est une solution de merde, clairement, mais pas trop eu le choix (compte tenu des impératifs de temps, le client était vraiment pas content d'avoir des trucs qui bugguent tout le temps, et le patron était pas fan non plus: il fallait du simple, qui juste marche).
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par barmic 🦦 . Évalué à 2.
Wow tout doux. Sans même avoir à parler d'implémentation. Comment un système peut déterminer qu'une application doit avoir une interface graphique ou non ? Comment ce dernier peut interagir avec elle ? Et enfin pour lui dire quoi ?
Si tu veux ce genre de choses il faut :
Et le gain c'est éviter d'avoir à tuer toi-même un processus ? Et espérer qu'une application dont l'interface graphique est stuck ne sera pas tout aussi bloquée sur son autre interface ?
Non de ce que tu décris tu as utilisé une solution ad-oc pour un besoin précis. Ce qui est très bien. Pousser cette rigueur pour tout le monde va être dramatiquement plus complexe :
Tout ça pour une solution qui ne pourra pas gérer tout tes cas. Je ne vois pas ce qui pousserait une appli buguée à ne pas l'être sur une autre interface. Sachant qu'avec les signaux elle peut déjà faire pas mal de choses. Mais par contre tu complexifie encore ce qu'est une application graphique ce qui augmente les bugs potentiels.
Je n'en sais rien si c'est mal ou pas. Si ça fonctionne pourquoi ce serait si mal. Il semble que chez toi les navigateurs leaks des processus et ou ton pilote graphique/X11/les bibliothèques graphiques plantent en boucle ce n'est pas ce que j'observe. Je ne remet pas en cause ce que tu dis, mais ça ne me paraît pas la norme.
Mais quand j'ai besoin de fiabilité élevée, je met en place des solutions ad-oc et je sais qu'on ne peut pas la construire pour moi (ça ne remplirait probablement que partiellement mon besoin et tout le monde n'a pas à se plier à mes besoins).
Note: tout de même que quand je parle de remonter un bug (et en faire le suivi) ou un patch ce n'est pas une parole en l'air. Quelque soit le système c'est une étape de dernier recours. Ça ne doit pas arriver. Ce n'est pas parce que j'ai un extincteur que je m'en fou de mettre le feu.
on pourrait appeler ça dbus par exemple ↩
il me semble que gnome (et peut être KDE) définissent des usages de dbus pour interagir, ils pourraient faire des choses dans ton sens éventuellement (mais ça a beaucoup de mal à passer hors de leurs appli dédié) ↩
gnome met en place des usages de dbus (et je présume que d'autres aussi) mais là il faut se mettre d'accord au sein de freedesktop, mais quand tu vois comment les évolutions de wayland et de systemd (qui a son propre système de watchdog)rament pour être accepté et utilisé, je doute que le monde des appli avec interface graphiques y passent facilement ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par Psychofox (Mastodon) . Évalué à 4.
Si tu'utilises systemd ta session tourne sous un cgroup et peut être tuée facilement. loginctl est l'outil utilisé pour gérer les sessions.
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par freem . Évalué à 1.
Non, mais, pour tuer facilement, pas besoin de cgroups, just
kill -9 $(pidof foobar)fait le job. Le problème, c'est de tuer quand tu as une perte d'une des conditions importantes pour le fonctionnement. Genre, la perte de connection au serveur graphique (via protocole X11 ou wayland, peu importe) devrais être simple à détecter, et quand c'est le cas, il faut tuer les applications graphiques, idéalement sans le -9, parce que peut-être qu'on peut sauvegarder l'état avant de redémarrer.Bon, je sais, je rêve. Et c'est hors sujet, on parle d'un DE la, après tout, l'utilisateur à accès au clavier et à la souris, pas besoin de chien de garde, il peut faire le job.
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par Frédéric Blanc . Évalué à 3.
et, pouf, vous venez de tuer tous vos process "foobar", voire mieux, si vous étiez connecté en tant que root, tous les process "foobar" du système. (Soit dit en passant : pkill vous économisera la saisie de pas mal de caractères pour vous mettre dans la même situation.)
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par sebas . Évalué à 1.
… et pgrep foobar -a permettra de visualiser ce qu'on va tuer avec un pkill avant de le lancer. ;-)
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par freem . Évalué à 2. Dernière modification le 31 décembre 2020 à 02:24.
Tout à fait, ma réponse était d'ailleurs garantie 100% sans ironie :)
En vrai, ma réponse marche. Dans certains contextes. Pas dans les bons. De la même manière que la réponse à laquelle je répondais…
# Jeu amusant : deviner à quoi correspondent les icones
Posté par dinomasque . Évalué à 7.
Les nouvelles icônes sont fort jolies. En voyant la planche illustrant cette dépêche, j'ai voulu essayer de deviner à quoi elles correspondent.
Et c'est pas facile du tout …
Dans l'ordre (gauche -> droite puis ligne par ligne) :
Les boutons de réglage : panneau de configuration (OK)
Les "fenêtres"(?) empilées avec X bleu : une version XFCE de Xkill ? -> KO apparement c'est "Windows Manager settings" (fallait le deviner celui-la !)
Les "fenêtres"(?) empilée avec un engrenage : un outil de paramétrage du window manager ? --> KO "Window Manager Tweaks"
L'écran avec une équerre : réglage de la résolution (OK)
L'écran avec des ciseaux : capture d'écran
L'écran avec un autocollant de souris : outil de gestion de fonds d'écran ?
L'écran avec une nuit étoilée : gestion de mise en veille ?
Case à cocher bleue puis </> : éditeur de formulaire HTML ??? --> KO, c'était bien sur "Settings Daemon" avec la description hyper explicite "stores your settings in a D-Bus-based configuration systems" , soit une sorte de "base de registre"
Quatre cases dont une avec un + : calculatrice ? (ça ressemble à l'icône Apple) --> KO : "Workspace settings"
Pile verte : gestion de l'énergie
Souris : gestion de la souris ?
Diagramme de Venn : gestion de la colorimétrie ?
Clef USB : ??? --> "Volume manager"
Silhouette blanche sur carré bleu : paramètres d'accessibilité ?
Nuancier : outil de sélection de couleurs ??? --> KO apparemment c'est les réglages d'apparence …
Quatre cases avec des petites icônes : ??? --> "Default Applications" !!! (peut être l'icône la moins explicite du lot)
Cloche : gestion d'alarmes ?
Clavier : paramètres du clavier --> KO "Command Shortcut"
Fusée sur carré bleu : lanceur d'applications ? --> KO "Session Manager"
Marteau de Thor : un jeu ? --> KO, c'est le gestionnaire de fichiers "Thunar"
Chat avec un monocle : enjeu ?
Loupe sur carré bleus : recherche de fichiers ? --> KO "Application Finder" (pas déconnant en fait)
Etoile avec une souris : ???—"About XFCE"
Icone de prompt : terminal
Sorte de demi-pellicule de film sur fond bleu : soit un demi-lecteur de vidéos soit gestion du dock ? --> C'est bien "Panel Preferences"
Armoire à archives : gestionnaire de fichiers ?
Planète : navigateur internet ?
Enveloppe avec papier : email ?
Bloc-notes : bloc-notes
"Aa" sur parapheur : gestion de polices de caractères ???
Oscilloscotpe : moniteur de ressources ?
Café sur arc-en-ciel : ????
Comme quoi, c'est un vrai métier de faire des icônes. Le bon boulot de graphiste effectué ne suffit pas.
BeOS le faisait il y a 20 ans !
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
En fait c'est pour ça qu'il faut un équivalent textuel (et aussi pour des questions d'accessibilité). Ce qui peut parler à quelqu'un ne va pas le faire du tout à quelqu'un d'autre.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par barmic 🦦 . Évalué à 3.
Tout à fait les icônes servent à se repérer plus facilement dans l'espace et à se repérer plus vite avec l'expérience.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Arthur Accroc . Évalué à 6.
En effet. Et on se repère plus rapidement avec des icônes colorées, ce qui a malheureusement échappé aux tenants du flat design et de ses icônes monochromes.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par barmic 🦦 . Évalué à 3.
Tu ne sais pas te repérer sans reflets ? Les icônes devraient ne pas trop s'appuyer sur les couleurs pour des questions d'accessibilité.
Le fait d'être flat ou pas ne change rien. On arrive à lire les panneaux de circulation, ça devrait mettre la puce à l'oreille.
Pour les couleurs je pense que ça peut être intéressant pour ne pas trop multiplier le nombre de couleurs et pouvoir mieux mettre en évidence autre chose avec la couleur. D'ailleurs les icônes monochromes sont souvent colorables. Le développeur peut choisir d'afficher chacune dans la couleur qu'il souhaite. Ça peut servir à donner une signification aux couleurs (rouge pour la suppression et perte d'information,
gris pour une action pas accessible,…). Encore une fois il ne faut pas s'appuyer uniquement dessus.
Ce sont des questions de goût amha.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Arthur Accroc . Évalué à 5.
« Reflets » ?
Simplement, par exemple, quand je cherche l’onglet de LinuxFr, je le repère immédiatement du coin de l’œil à sa couleur dominante. Pareil pour Startpage, qui a des couleurs dominantes complètement différentes. C’est beaucoup plus rapide que de détailler chaque icône, ce qui est indispensable si seule la forme diffère.
On peut mettre des couleurs et viser quand même la lisibilité en noir et blanc. On peut aussi prévoir plusieurs jeux d’icônes.
Beaucoup d’interfaces flat s’accompagnent d’icônes monochromes stylisées (certaines assez compréhensibles et d’autres pas).
Là dessus, les anglais ne font pas comme nous : ils n’affichent pas les noms de villes entièrement en capitales, mais avec des minuscules. Ça permet de repérer la ville dont tu suis la direction à la forme du nom, avant d’être assez prêt pour pouvoir vraiment lire. Les anglais n’ont pas que des mauvaises idées…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par barmic 🦦 . Évalué à 1.
Là tu parles de couleur et pas d'être flat ou pas. Mais les favicon sont pas vraiment contrôlables et tu parle ici en multi site, ce n'est clairement pas maîtrisable de la même manière qu'un jeu d'icônes d'une application.
cf: les 2 premiers commentaires du thread en cours. C'est aussi possible en non flat.
C'est intéressant mais ça n'a aucun rapport. Leur sens interdit est en flat et je n'ai pas essayé mais je ne crois pas que l'excuse "j'ai du mal avec le flat design" marche devant la justice.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Arthur Accroc . Évalué à 6. Dernière modification le 03 janvier 2021 à 13:33.
Oui, je parle de couleur, parce que quasiment toutes les interfaces que j’ai vues qui sont passées au flat design sont aussi passées au monochrome tout de la même couleur (ou non couleur : noir ou gris foncé sur fond blanc ou clair, ou blanc ou gris clair sur fond noir ou gris foncé).
Ça marche aussi pour l’icône de Firefox, mais c’est moins spectaculaire vu que son icône est toujours au même endroit sur mon écran.
Il est en couleur, et pas du tout la même que le sens unique.
Je ne critique pas le flat design pour son style (moche à mon goût, mais bon, c’est secondaire), mais pour le fait que ses tenants l’accompagnent presque systématiquement de la suppression des couleurs.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par barmic 🦦 . Évalué à 2.
Moi je trouve dommage de prendre le flat design1 comme une critique en soit et de considérer les icônes comme pouvant être jugée en soit et pas dans leur manière d'être intégrée dans un tout.
Regarde gimp par exemple:
Tu as une large part d’icônes flat et toutes de la même couleur. Il y a pas mal de raisons pour l'expliquer que ce soit dans le panneau d'outils (où ils n'ont pas respecter le fait de mettre un libellé à coté pour de bonne raison), dans les menus ou dans les boites de dialogues. L'interface se pense comme un tout et il ne me semble pas pertinent de juger des icônes hors de l'interface.
tu vois c'est toi qui a ramené le point du flat design et la manière dont tu l'a amené m'a fait penser que tu avais des reproches au flat design et au monochrome. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Arthur Accroc . Évalué à 6.
Regarde gimp par exemple:
[…]
Tu as une large part d’icônes flat et toutes de la même couleur.
Voilà. Je retrouve justement moins vite la fonction que je cherche qu’avant quand les icônes étaient colorées (je l’utilise assez peu, des fois chez moi et des fois au boulot et sur des écrans de taille différente, les icônes sont disposées différemment…).
Il me semble qu’il y a moyen de restaurer les anciennes icônes, il faudrait que je le fasse.
Je ne dis pas que ce n’est pas cohérent. Mais même si l’esthétique penchait vers la version flat (je ne sais pas, il faudrait que je voie les anciennes icônes à côté pour avoir une opinion sur celles‐ci en particulier), je préfère des icônes colorées que je retrouve plus vite.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par barmic 🦦 . Évalué à -1.
Je vais m'arrêter là c'est la discussion manque de hauteur pour être intéressante recherche "skeuomorphisme vs flat" tu y trouvera tous les arguments pour l'un et pour l'autre et des bonnes pratiques.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Guinns . Évalué à 4. Dernière modification le 24 janvier 2021 à 21:09.
Préférences => interface => Thème d'icone => Legacy
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par xcomcmdr . Évalué à 6. Dernière modification le 03 janvier 2021 à 18:16.
Eh beh non pour moi. Le flat est illisible, me fait perdre du temps. Qui plus est, il est invariablement moche, sans saveur.
Et son existence n'a aucune justification à part l'effet de mode. La preuve, on vivait très bien sans lui.
A mort le flat.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par Dring . Évalué à 5.
On peut reprocher à l'argumentation d'être un peu courte, mais franchement, je suis plutôt d'accord. J'ai pas encore vu de design qui se définisse comme étant "flat" et qui soit vraiment efficace/lisible.
Après, c'est pas spécifique au flat design, c'est juste la notion d'effet de mode. Tout le monde veut en faire parce que c'est le buzz word du moment, même quand on ne comprend pas ce que ça veut dire, à quoi ça sert, etc. Du coup, tout le monde le demande, pour les même raisons.
Pour reprendre l'exemple de GIMP, je préfère largement les anciennes icônes. Par contre, les icônes de iOS, c'est plutôt une évolution positive, avec moins d'effets inutiles (dégradés et ombres qui surchargent sans apporter quoi que ce soit).
# Raccourcis clavier, question bête
Posté par DavidB (site web personnel) . Évalué à 3. Dernière modification le 25 janvier 2021 à 12:27.
Merci pour cette présentation des nouveautés.
Je suis passé en 4.16 sans souci (à part que je ne peux plus utiliser l'extension Orage Clock pour afficher la date dans mon Panel).
J'ai une question à propos des nouveaux raccourcis clavier, peut-être qu'un pro ici pourra éclairer ma lanterne: j'en utilise et en ai ajouté un paquet sur XFCE depuis un momemt déjà et, du coup, j'ai l'impression que les nouveaux n'ont pas été installés du tout (ça m'arrange, hein). Y aurait-il moyen de voir la liste complète de ces nouveaux raccourcis par défaut, sans les installer et sans supprimer les miens?
Je suis curieux de savoir si ça pourrait valoir la peine de laisser tomber les miens pour adopter les nouveaux, histoire de coller au plus près d'une installation par défaut si c'est possible :)
[^] # Re: Raccourcis clavier, question bête
Posté par Cilyan Olowen (site web personnel) . Évalué à 1.
Les raccourcis par défaut sont réglés ici: https://gitlab.xfce.org/xfce/libxfce4ui/-/blob/master/libxfce4kbd-private/xfce4-keyboard-shortcuts.xml
(Même si c'est pas top-lisible, c'est mieux que de cliquer sur le bouton "Restaurer par défaut" si tu as bichonné ta config pendant des mois :) )
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.