Journal Créer un environnement de bureau à sa sauce: nouvel essai

Posté par  .
Étiquettes : aucune
-5
13
nov.
2017

Sommaire

Préambule

Licence

Licence CC-BY.

«Historique»

Il y a longtemps, j'ai voulu écrire une dépêche ici sur la création d'un «guide imparfait pour construire un environnement de bureau à sa sauce».
J'avais voulu faire une dépêche, mais, je n'ai probablement pas ce qu'il faut pour diriger un travail collectif, alors je vais reprendre de zéro, mais je tiens malgré tout à remercier ceux qui ont essayé de m'aider et dont je me permets de jeter les efforts aux orties (alors que je ne fais au final sûrement pas aussi bien):

  • nyco,
  • oumph,
  • okram,
  • olivierweb,
  • palm123,
  • baud,
  • royalpanda,
  • syvolc,
  • fiuzzy,
  • anaseto,
  • ytterbium,
  • andrianarivony,
  • jcr83,
  • neox,
  • benoît,
  • oulala,
  • jarillon,
  • montaigne,
  • groumph,
  • err404,
  • fdf,
  • titiii,
  • lenod,
  • dareg--2,
  • leowzukw

Je retente donc, en prenant en compte les leçons tirées:

  • ne pas tenter d'être exhaustif
  • partitionner
  • ne pas essayer de faire une dépêche quand on n'a aucune expérience d'édition
  • ne pas faire l'âne de buridan: se décider.

En conséquence de ces points, de nombreux raccourcis seront pris, de fréquents partis pris commis, d'éventuels trolls appelés, et j'en oublie.
Je préfère prévenir de suite, ce journal et ceux qui suivront éventuellement ne sont pas destinés à Madame Michu, mais plutôt aux jeunes individus d'une variété bien particulière de moules à barbe et de trolls velus.

Introduction

Compte tenu du fait que je compte plutôt faire une série qu'un article mono-bloc chaque «temps» sera l'occasion d'un article. Je pense que je consacrerai un préambule de chaque journal pour revenir sur les points des précédents, en fonction des commentaires. Une sorte de façon de patcher, quoi… À voir.

Plan d'action

Introduction

Tout d'abord, l'introduction.
Cet article, quoi.
Vu que c'est chiant et creux, tant à écrire que probablement à lire, je vais aussi faire un rappel de ce que l'on appelle un environnement de bureau (par la suite de cet article et des suivants, abrégé DE, pour Desktop Environment, le terme anglois), et pourquoi on appelle ça comme ça. S'en suivront un certain nombre de questionnement pas nécessairement pertinents.

Les fondations

Dans un deuxième temps, je compte définir les composants de base qui vont servir de fondations au reste, et imposer les outils que j'utilise moi: vous voila averti, une bonne dose de subjectivité et de parti pris est à prévoir. Bien sûr, je serai heureux de lire les trolls moules intéressées au débat :]

La base

Viendra ensuite un article sur un choix, parmi tant d'autres, sur les outils de base d'un DE non orienté geek ou nerd, et comment intégrer ces outils de travail.
Ce ne sera probablement pas très long, parce que pour être honnête, c'est plutôt une sélection parmi les outils que j'ai testés au fur et à mesure, souvent basée sur l'idée d'avoir un système avec le moins de paquets installés: soit je favorise Qt, soit je favorise Gtk, parfois des softs en Xlib ou en ncurses…
J'émaillerai ce passage de commentaires de pourquoi j'ai préféré tel ou tel outil, pourquoi parfois je fais une entorse à ma règle de me baser sur un minimum de toolkits différents…

La déco

Le quatrième point sera plutôt orienté vers une sélection d'outils liés au confort: principalement les applications multimédia. Peut-être que cette partie sera fusionnée avec la précédente, je verrai en fonction de la taille.

Le productif

J'enchaînerai sur une partie plus technique, et qui est vraisemblablement la raison qui m'a fait adopter ce mode de travail.
On y parlera d'outils de programmation, de comment on peut oser dire qu'un IDE c'est pour les gens incapables de structurer leurs projets, de la façon d'administrer un jeu restreint de machines, pas forcément de la façon la plus efficace (parce que je suis très mauvais en réseau et plus plus que bof en administration système: il ne sera pas compliqué de m'envoyer paître sur des erreurs de sécurité, même si j'essaierai de faire attention).

la conclusion ?

Éventuellement, je trouverai le matériel pour un autre journal, qui lui traitera d'éventuelles optimisations du système, d'opinion personnelles sur le futur de mon propre DE, des difficultés que j'ai parfois pu rencontrer avec les jeux vidéos ou certains softs récalcitrants, des outils qui se foutent royalement de noyer l'utilisateur dans leur chiée de fichiers de config mal placés, de l'éventualité de construire un méta-paquet qui installerait les outils ainsi que quelques scripts permettant de customiser tout ça de manière uniforme…
À voir donc, il me faudrait déjà arriver jusque la :]

Vous conviendrez que c'est une introduction plutôt longue, et plutôt inutile.
J'enchaîne donc sur… la première partie, comme promis.

Histoire des DE

En version courte et biaisée:
L'idée derrière les DE informatiques est de transposer les termes et les techniques de travail sur papier pré-«informatique grand -public» à l'informatique, de sorte à faciliter la transition entre l'espace de travail physique (accès aux données de manière visuelle, vocale et tactile (le métier de secrétaire à bien changé ;]), pertinent, mais limité en vitesse et en portée), et l'espace de travail virtuel (accès au données parfois lointaines de façon quasi-instantanée, tri ultra-rapide, mais absence de sensibilité, absence originelle de contrôle vocal, lui-même encore plutôt inefficace, accessibilité parfois douteuse?). C'est de la que nous viennent diverses adaptations de termes:

  • fichier,
  • dossier,
  • corbeille,
  • bureau (justement),
  • BSOD,
  • probablement d'autres que j'oublie ou ignore

J'ai aussi envie de dire que c'est de cette dette technique que viens l'idée de se limiter à seul bureau, too much windows (la lumière naturelle ça abîme les écrans, bordel!) et du foutoir sur le bureau, justement.

En version longue, je vous invite plutôt à lire les divers articles de wikipedia. Oui, je sais, c'est plus court comme explication, du coup, mais je ne suis pas une encyclopédie, moi: déjà, je pense avoir prouvé un certain nombre de partis pris, ce qui me semble contraire aux buts d'une… ben, encyclopédie.

Bref.
Nous, ou plutôt nos pères, voire grand-pères pour certains d'entre vous, avons transposé, avec plus ou moins de succès, le bureau papier vers le bureau numérique, avec le succès que l'on connaît aujourd'hui.

Concrètement, des logiciels ont été écrits afin de gérer de manière (parfois semi-)graphique ces éléments, afin de permettre à l'utilisateur de gérer au mieux son espace de travail (workspace en anglais), les plus pauvres ne disposant pour tout espace de travail que d'un bureau unique, les plus débrouillards et organisés sachant en exploiter plusieurs (et parfois même le sol, vécu!).
Ces logiciels sont habituellement appelés «gestionnaires de fenêtres» ( par la suite, j'utiliserais l'abréviation WM), mais en réalité, et les vrais barbus vous l'expliquerons peut-être mieux que moi, les WMs sont, en pratique, limités aux seules applications graphiques. Pour les irréductibles amoureux du terminal, il existe ce que l'on appelle des multiplexeurs de terminaux (tmux, screen), qui ont, au final, un rôle très proche, voire identique. Je préfère prévenir de suite, je ne connais les multiplexeurs de terminaux que de nom, mais à priori, ils sont de véritables gestionnaires de fenêtres pavant (je reviendrai sur le terme pavant plus tard), sauf que personne ne semble avoir fait de travail équivalent dessus à celui qui a été fait pour nos WM habituels.

L'approche la plus connue, et en tout cas la première que j'aie connu, fut de mimer à l'identique les bureaux physiques, avec des documents de travail , ou fenêtres dans notre jargon, qui peuvent s'empiler, pour «ne pas perdre» l'utilisateur.
Sauf que, tout le monde n'a pas considéré que c'était une bonne chose, et de la sont (peut-être) nées les deux familles de WM:

  • les WM en foutoir, forçant l'utilisateur à jongler avec des piles de papiers pour essayer d'accomplir sa corvée pile, qui nécessitent de gérer manuellement les fenêtres afin d'être «productif». Les utilisateurs de ces gestionnaires utilisent souvent de nombreux outils dédiés à leurs tâches quotidiennes, capables de gérer un grand nombre de tâches dans un seul logiciel, je vous laisse deviner pourquoi. Ces outils représentent l'immense majorité au doigt levé. Est-ce la résistance au changement? Je vous laisse seuls juges. J'hésite à les appeler FWM, pour Foutoir Window Manager (le terme anglais correspondant au F était tellement moins poétique…).

  • les WM pavant (ci-après abrégé TWM, pour Tiling Window Manager), dont le principe est de laisser la machine gérer un placement optimal des papiers fenêtres sur le bureau. Leur capacité fondamentale est l'utilisation optimale de l'espace de l'écran, souvent au détriment de l'esthétique mais pour divers gains d'efficacité non-négligeables.
    Ces gestionnaires se divisent à priori en 2 grandes familles:

    • les gestionnaires basés sur un nombre pré-défini de stratégies de placements: imposent un certain nombre de stratégies de placement, parmi lesquelles l'utilisateur doit choisir. Je vous avoue ne pas avoir été séduit par l'idée, mais avec le temps je pense que je devrais y réfléchir à nouveau. En conséquence, je n'ai pas trop d'exemples à donner: mes recherches à ce sujet sont trop anciennes.
    • les gestionnaires basés sur un placement semi-libre: laissent l'utilisateur composer sa stratégie au fil de ses besoins. Parmis ceux que j'ai testés figurent notamment ratpoison le tueur de souris, et i3, qui semble au final très populaire, son nom apparaissant majoritairement et avec une fréquence grandissante dans mes lectures (ça sent le biais, hein? Je suis d'accord.).

Je comptais, à l'origine, intégrer la notion d'applications et de comment en «lancer» à partir d'un WM, mais cet article est déjà bien trop long, finalement, et il me reste à poser un certain nombre de questions, sur lesquelles j'aimerai bien avoir vos opinions.

Par exemple, j'ai mentionné l'accessibilité:

je n'ai, à priori, aucune déficience physique (pour le mental, ça reste à prouver…) qui m'empêche d'utiliser mes machines avec l'interface de mon choix, mais d'autres n'ont pas cette chance (s'il y en a dans la salle, venez me voir à la fin de… je m'égare la…) et je me demande, de manière générale, si prendre en compte ces aspects et contraintes ne pourrait pas améliorer l'usage de ceux qui ne sont pas affectés, voire retarder l'éventualité de le devenir, ou même réduire l'impact lorsqu'un problème arrive: nous vivons de plus en plus vieux, et j'ai pu voir une personne dépérir suite à la perte de l'ouïe. Je n'ose imaginer la vue pour moi, gros utilisateur d'écrans (en théorie j'en suis encore loin, mais…).

Doit-on considérer que le contrôle sonore (synthèse et reconnaissance vocale) font partie d'un DE? Si oui (et je pense que oui), quels outils permettent de traduire le traditionnel saisie+visuel vers ce domaine?

D'ailleurs, est-ce pertinent de chercher à traduire des applications de base mal pensées? Ne serait-il pas possible de penser un outil pour faciliter la mise en place de frontaux permettant l'accès à diverses «cibles» (sourds, muets, féministes, trisomiques, geeks, famille Michu…)?

Quid des périphériques embarqués? Des géants (je sais, c'est ironique, de qualifier µsoft de géant) ont essayé, mais se sont cassés les dents dessus: pourquoi? Quelles sont les spécificités des tablettes et débilophones qui rendent ces outils si peu simples à utiliser pour des usages avancés ( rappelez-vous: la cible de cette série de journaux, sont les utilisateurs avancés)? D'ailleurs, c'est quoi, un usage avancé?

Voila, j'avoue, je trouvais que ça manquais de techno-trolls par ici ces derniers temps, alors je me dévoue pour, au moins, essayer de lancer un truc :]
Bon, j'aurai probablement du poster ça un jeudi soir ou trolldi matin, mais j'aimerai essayer de régler ce guide un jour, et vu que je suis motivé ce soir…

PS: je note que l'usage de ] au lieu de ) pour les smiley évite la confusion de mon éditeur de texte favori. Que pensez-vous de cette idée? En plus, ça évite de gâcher la journée de ceux qui noterons une incohérence entre les ( et les )?

  • # et ben...

    Posté par  . Évalué à 10.

    Je crois qu'effectivement, il te faut un rédacteur, car là c'est indigeste!

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: et ben...

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      Je confirme.

      En attendant tu peux améliorer ces points par exemple :

      • Faire un plan qui suit une logique cohérente pour le lecteur : par exemple, les informations de licence et les excuses pour avoir supprimé du travail de rédaction devraient être plutôt en annexe à la fin et pas en préambule.
      • Éviter les digressions qui n'apportent rien au lecteur. Par exemple, dans : « En version longue, je vous invite plutôt à lire les divers articles de wikipedia. Oui, je sais, c'est plus court comme explication, du coup, mais je ne suis pas une encyclopédie, moi: déjà, je pense avoir prouvé un certain nombre de partis pris, ce qui me semble contraire aux buts d'une… ben, encyclopédie. », la première phrase suffit, tout le reste est principalement une méta-réflexion qui n'apporte rien.
      • Te relire en te demandant si ta prose est compréhensible. Il y a des phrases dont je ne suis pas sûr de ce qu'elles veulent dire.
      • D'une manière générale, supprimer tout ce qui n'est pas indispensable à ton propos.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: et ben...

        Posté par  . Évalué à 3.

        J'ajouterai que le sujet des types de window managers pourrait être pertinent mais il est traité sous forme de troll, dénigrant les Stacking window manager.
        Alors que tout un chacun pouvant avoir sa préférence en fonction de son usage.

Suivre le flux des commentaires

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