Xfce 4.16 : La souris fait la fête !

Posté par  . Édité par BAud, ted, palm123 et Ysabeau. Modéré par Xavier Teyssier. Licence CC By‑SA.
Étiquettes :
88
28
déc.
2020
Serveurs d’affichage

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

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

Icônes Xfce 4.16

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 :
Palette de couleurs des icônes Xfce

Gestionnaire de paramètres

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

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

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

Modification d’un raccourci 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

Opération de copie de fichiers dans Thunar

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

Mode sombre activé dans les préférences du 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.

Le nouveau plugin statustray

l’autohide

Lancement d’une nouvelle instance d’une application

Gestionnaire d’alimentation

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 »

A propos

Onglet Système

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

  • # Le lecteur multimédia de Xfce (nommé Parole) 4.16 arrive bient̂ôt

    Posté par  . É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 !)

  • # B-bye, Xfce

    Posté par  (site Web personnel) . Évalué à 1. Dernière modification le 28/12/20 à 12:04.

    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.

    …Et donc, les outils en question, utilisés dans un WM qui gère ses widgets "comme ci" (par exemple et au hasard, i3) aura ses widgets "comme ça", yay. J'arrive même pas à trouver une seule bonne raison de faire ça.

    Perso, j'utilisais Thunar et xfce-terminal, bin je vais devoir leur trouver des remplaçants.

    Ils ont du trouver qu'ils avaient trop d'utilisateurs.

    • [^] # Décorations de fenêtres côté client, une régression

      Posté par  . É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…

      Guerres, déréglement climatique, effondrement de la biodiversité, épuisement des ressources, pandémie, montée du fascisme, de l’intégrisme et du complotisme… On vit une époque formidable…

      • [^] # Re: Décorations de fenêtres côté client, une régression

        Posté par  . Évalué à 9.

        À 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.

        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:

        Wayland-serverd
         |-- window-manager
         |-- some-client
         `-- window-decorator
        

        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-serverd et window-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.

        • [^] # Re: Décorations de fenêtres côté client, une régression

          Posté par  (site Web personnel) . Évalué à 4. Dernière modification le 28/12/20 à 17:58.

          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?).

          Actuellement, tu n'as pas à t'occuper des widgets du tout. Si l'idée du paradigme CSD est de juste fournir au dev la liberté de s'occuper de ça s'il le veut, mais dégrade gracieusement vers le WM la gestion des widgets s'il ne le souhaite pas, fort bien, il reste juste à l'utilisateur de choisir d'utiliser ou non des soft ergonomiquement cassés, no biggie.

        • [^] # Re: Décorations de fenêtres côté client, une régression

          Posté par  (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  (site Web personnel) . Évalué à 3.

        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.

        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…

        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

        cadet soucis

        Aussi, parce que comme sur Gnome, la barre de titre est inutilement haute

        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  . Évalué à 3. Dernière modification le 26/01/21 à 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  . É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  (site Web personnel) . Évalué à 5.

              c'est un style différent à appliquer.

              À 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.


              1. 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  . É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  . É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  . Évalué à 5. Dernière modification le 29/12/20 à 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 !

        • [^] # Re: B-bye, Xfce

          Posté par  . É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  . Évalué à 5.

    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.

    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  . Évalué à 4.

      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é

      C'est forcément l'init qui récupère ça.

      éventuellement maintiens (je ne sais pas si c'est possible) la garantie qu'il est possible d'interagir avec la-dite application?

      Ç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é,…).

      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)?

      Tu demande comment faire pour qu'une application buguée réagisse bien ? Remonter un bug ou un patch.

      Quelles solutions techniques théoriques et pratiques y a-t-il actuellement?

      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  . Évalué à 5.

        C'est forcément l'init qui récupère ça.

        Certes. Mais du coup, je me demande justement si c'est pertinent.

        Ç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é,…).

        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.

        Tu demande comment faire pour qu'une application buguée réagisse bien ? Remonter un bug ou un patch.

        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).

        Balancer un signal. Si le processus a prévu un handler c'est cool sinon ça te permettra de le tuer.

        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  . Évalué à 2.

          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.

          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 :

          1. mettre en place une description de ce qui semble être un comportement normal ou non de ton appli
          2. mettre en place un protocole pour interagir avec ton appli1
          3. décrire comment on utilise ce protocole2

          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 ?

          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).

          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 :

          • il faut que la solution soit généralisation, qu'elle mette tout le monde d'accord3
          • il faut que ce soit implémenté dans les WM, par les bibliothèques graphiques et par les appli (gtk/qt ne peuvent pas deviner si c'est normal ou non de ne plus avoir de gui)

          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.

          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).

          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.


          1. on pourrait appeler ça dbus par exemple 

          2. 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é) 

          3. 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  . É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  . É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  . Évalué à 3.

          just kill -9 $(pidof foobar) fait le job.

          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  . Évalué à 1.

            et, pouf, vous venez de tuer tous vos process "foobar" […] (Soit dit en passant : pkill vous économisera la saisie de pas mal de caractères pour vous mettre dans la même situation.)

            … 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  . Évalué à 2. Dernière modification le 31/12/20 à 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  . É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  (site Web personnel) . É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  . É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  . É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.

          Guerres, déréglement climatique, effondrement de la biodiversité, épuisement des ressources, pandémie, montée du fascisme, de l’intégrisme et du complotisme… On vit une époque formidable…

          • [^] # Re: Jeu amusant : deviner à quoi correspondent les icones

            Posté par  . É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  . Évalué à 5.

              Tu ne sais pas te repérer sans reflets ?

              « 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.

              Les icônes devraient ne pas trop s'appuyer sur les couleurs pour des questions d'accessibilité.

              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.

              Le fait d'être flat ou pas ne change rien.

              Beaucoup d’interfaces flat s’accompagnent d’icônes monochromes stylisées (certaines assez compréhensibles et d’autres pas).

              On arrive à lire les panneaux de circulation, ça devrait mettre la puce à l'oreille.

              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…

              Guerres, déréglement climatique, effondrement de la biodiversité, épuisement des ressources, pandémie, montée du fascisme, de l’intégrisme et du complotisme… On vit une époque formidable…

              • [^] # Re: Jeu amusant : deviner à quoi correspondent les icones

                Posté par  . Évalué à 1.

                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.

                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.

                Beaucoup d’interfaces flat s’accompagnent d’icônes monochromes stylisées (certaines assez compréhensibles et d’autres pas).

                cf: les 2 premiers commentaires du thread en cours. C'est aussi possible en non flat.

                Là dessus, les anglais ne font pas comme nous[…]

                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  . Évalué à 6. Dernière modification le 03/01/21 à 13:33.

                  Là tu parles de couleur et pas d'être flat ou pas.

                  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é).

                  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.

                  Ç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.

                  Leur sens interdit est en flat

                  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.

                  Guerres, déréglement climatique, effondrement de la biodiversité, épuisement des ressources, pandémie, montée du fascisme, de l’intégrisme et du complotisme… On vit une époque formidable…

                  • [^] # Re: Jeu amusant : deviner à quoi correspondent les icones

                    Posté par  . Évalué à 2.

                    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.

                    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:

                    capture d'écran de gimp 2.0

                    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.


                    1. 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  . É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.

                      L'interface se pense comme un tout et il ne me semble pas pertinent de juger des icônes hors de l'interface.

                      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.

                      Guerres, déréglement climatique, effondrement de la biodiversité, épuisement des ressources, pandémie, montée du fascisme, de l’intégrisme et du complotisme… On vit une époque formidable…

                      • [^] # Re: Jeu amusant : deviner à quoi correspondent les icones

                        Posté par  . É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  . Évalué à 4. Dernière modification le 24/01/21 à 21:09.

                        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.
                        Il me semble qu’il y a moyen de restaurer les anciennes icônes, il faudrait que je le fasse.

                        Préférences => interface => Thème d'icone => Legacy

            • [^] # Re: Jeu amusant : deviner à quoi correspondent les icones

              Posté par  . Évalué à 6. Dernière modification le 03/01/21 à 18:16.

              Tu ne sais pas te repérer sans reflets ?

              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  . É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  (site Web personnel) . Évalué à 3. Dernière modification le 25/01/21 à 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 :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.