Plus de trois ans après la version précédente, voici awesome 3.5. Il s'agit d'un gestionnaire de fenêtres léger, scriptable, et disposant d'une présentation des fenêtres configurable. Il permet notamment de faire cohabiter des dispositions de fenêtres de type pavant, flottant ou encore plein écran. Il est scriptable et adaptable à souhait par l'utilisateur, au point qu'il est présenté par ses pères comme une plate-forme permettant de construire son propre gestionnaire de fenêtres, plutôt qu'en tant que gestionnaire de fenêtres « classique ». Cette approche permet de répondre à de multiples usages, au prix d'une plongée dans le fichier de paramétrage et la programmation en lua.
Sommaire
- L'esprit awesome
- Sous le capot
- Nouveautés de la version 3.5
- En bref, pour la migration 3.4 vers 3.5 (configuration utilisateur)
L'esprit awesome
Awesome a su se faire une place sur le bureau (en plus d'être dans l'interface du Kindle Touch d'Amazon), et l'on peut désormais sentir sa touche dans d'autres applications. Nous proposons ici quelque chose d'assez subjectif : on peut caractériser awesome, entre autres, par une approche orientée clavier, par l'utilisation d'étiquettes et par la présence d'outils visant à faciliter la personnalisation du gestionnaire de fenêtres.
Tout au clavier (ou pas)
Le but d'awesome est de proposer un gestionnaire de fenêtres complètement pilotable au clavier, tout en laissant la possibilité d'une utilisation centrale de la souris (par exemple pour le déplacement et le rédimensionnement des fenêtres en mode flottant). Contrairement à d'autres gestionnaires de fenêtres orientés clavier, l'ensemble des raccourcis est centralisé par défaut autour d'une même et unique touche : la touche Super_L (Mod4). Assez peu utilisée dans les applications, elle permet de mettre en place des raccourcis clavier qui s'intègrent facilement dans les configurations existantes et qui restent cohérents sur l'ensemble d'awesome. La configuration des raccourcis clavier peut être facilement modifiée via l'édition du fichier de configuration (rc.lua), de même que la variable meta, qui définit la touche principale.
Les étiquettes
Un système d'étiquettes (tags), utilisé dans d'autres gestionnaires de fenêtres de type pavant, est préféré au concept de bureau virtuel. Les étiquettes permettent de répartir les applications (clients) par groupes, auxquels on applique un type de mise en page (pavant, flottant, plein écran). Un client peut être déplacé d'une étiquette à l'autre ou même affiché sur plusieurs étiquettes. On peut également afficher à l'écran une combinaison du contenu de plusieurs étiquettes (c.-à-d. des clients associés à ces étiquettes).
Cela rend awesome facilement utilisable dans les configurations multi-écrans : il est possible d'associer un client à une étiquette dans la configuration, et laisser awesome gérer le placement des clients sur les écrans.
Un esprit « Tune It Yourself »
Il est vrai que la configuration par défaut d'awesome est assez minimaliste (peu ou pas de widgets, des étiquettes non personnalisés, un menu standard, etc.). Mais tout est fait pour faciliter la personnalisation au plus haut degré (un vrai terrain de jeu pour les bidouilleurs de l'extrême et autres accrocs de la personnalisation). On citera quelques points :
- les scripts en Lua, qui permettent d'étendre soi-même le comportement du gestionnaire de fenêtres via l'API Lua d'awesome. En bref, cette API permet de définir une surcouche au gestionnaire de fenêtres de base, en manipulant directement le comportement des clients, des étiquettes, des barres d'informations, des menus et des « keygrabbers » qui permettent de réaliser des menus contextuels et plein de choses encore ;
- les widgets, qui, en tant qu'éléments de personnalisation, sont à configurer par l'utilisateur. On peut les créer soi-même ou utiliser des bibliothèques de widgets, telles que Vicious ou Blingbling ;
- l'outil awesome-client, qui n'est autre qu'un simple client dbus, fourni sous la forme d'un binaire. Il constitue un outil classique, mais puissant, qui permet d'appeler du code lua — par exemple une fonction utilisateur définie dans le fichier de configuration rc.lua — depuis un processus extérieur au gestionnaire de fenêtres. Cela permet d'intégrer des routines du patrimoine logiciel ou encore des scripts écrits dans nos langages préférés pour compiler des informations, puis les fournir aux widgets d'awesome pour affichage (mises à jour du gestionnaire de paquets, état de la batterie, ou toute autre information « conky-like », notifications, etc.).
Depuis sa création, de nombreux scripts ont été écrits pour ajouter des notifications vers des applications (mpd, mail) ou ajouter des fonctionnalités (météo, calendrier), voir même modifier la gestion des tags pour faciliter l'ergonomie (shifty).
Sous le capot
- utilisation de la bibliothèque asynchrone XCB, ce qui est censée rendre le gestionnaire de fenêtres plus réactif ;
- implémentation de plusieurs standards Freedesktop : EWMH, XDG Base Directory, XEmbed, Desktop Notification, System Tray ;
- support du multi-écrans (XRandR, Xinerama or Zaphod mode) ;
- support Dbus (client binaire fourni) ;
- un système d'extensions en Lua, bien documenté.
Et bien d'autres choses.
Nouveautés de la version 3.5
Voici la liste des nouveautés dans cette nouvelle version. Les citations sont issues des annonces officielles de la mailing-list.
Compatible Lua 5.2
Awesome est désormais scripté avec Lua 5.2. Cela entraîne un changement dans le paramétrage puisque la syntaxe du langage a évolué, et que certains scripts ne seront plus compatibles. Pour l'instant, il est toujours possible de compiler awesome avec Lua 5.1, mais ceux qui veulent passer à Lua 5.2 peuvent déjà le faire.
Nous avons réalisé quelques modifications pour permettre à awesome d'anticiper les évolutions. Avec Lua 5.2, module() est obsolète. Awesome n'utilise plus cette fonction. Toutefois, cela a des impacts visibles par l'utilisateur : il est maintenant nécessaire d'expliciter l'assignation de module à des variables globales :
local awful = require("awful")
Réécriture des décorations de fenêtre
Un point discuté fut celui des décorations de fenêtres. Actuellement, il est possible de choisir si la barre de titre est affichée ou non (par exemple, ne l'afficher que pour les fenêtres flottantes, ou sur une étiquette particulière…). Par contre, il n'est pas possible de choisir de quoi sera composé cette barre de titre.
La barre de titre a bénéficié de la réécriture des widgets, et est maintenant paramétrable. Il est possible de choisir les composants affichés, et de créer ses propres composants.
Au lieu de forcer le type des barres de titres disponibles pour l'utilisateur, celles-ci sont désormais configurables à la manière des wiboxes.
Nouveau système de widget
Conséquence des points précédents, il a fallu réécrire les widgets. On annonce la couleur directement :
Tout le monde va me maudire pour avoir à nouveau remplacé le système de widget, mais le résultat me plait. En conséquence, tout fonctionne désormais différemment.
Mise à jour des dépendances
Le monde évolue, les bibliothèques aussi. GObject fait son apparition dans awesome à travers la bibliothèque lgi (Lua GObject Introspection). La bibliothèque actuellement utilisée pour cairo, pango, et PangoCairo. Toutefois, il ne s'agit pas d'une bibliothèque nécessaire pour la compilation.
À noter que la bibliothèque de widgets vicious, est déjà compatible avec Lua 5.2 et que la branche master de blingbling (la petite nouvelle), basée sur oocairo, est également compatible avec la version 3.5 d'awesome.
En bref, pour la migration 3.4 vers 3.5 (configuration utilisateur)
Je propose de lister en bref les changements au sein du fichier de configuration (rc.lua), qui vous attendent probablement si vous envisagez une migration d'awesome 3.4 vers 3.5 :
Import des modules Lua 5.2
Pour ceux qui utiliseront awesome avec Lua 5.2 (la façon d'importer des modules Lua ayant changé), il faudra ajouter des variables pour pouvoir accéder aux modules awesome. Par exemple, pour utiliser naughty :
local naughty = require("naughty")
Et ceci est à faire pour chaque module (ça peut être un poil long, surtout pour les gros malins, qui comme moi (vlamy), ont éclaté le fichier de conf.)
Changements API Widgets
Comme annoncé plus haut, les widgets ont été totalement repensés. Ceci implique malheureusement une ré-écriture de chaque widget (création, assignement de texte et autres champs). Toutes les bibliothèques de widgets développées avant la version 3.5 et non mises à jour sont donc obsolètes :(
Heureusement, il existe un très bon tutoriel pour écrire des widgets compatibles avec la version 3.5 (en anglais).
Changements API mineurs
Les points suivants sont principalement constitués de simples modifications syntaxiques :
- retouche API signaux ;
- retouche API menu ;
- retouche API tasklist.
Et ma config ?
Va-t-il falloir réécrire sa configuration ? La réponse est donnée dans l'annonce officielle :
Il est manifestement impossible que votre configuration ne soit pas cassée.
Vous êtes prévenus !
Aller plus loin
- Site officiel (1451 clics)
- Guide de migration de la version 3.4 vers la 3.5 (165 clics)
- L'annonce de la RC1 (39 clics)
- Annonce de la version 3 sur DLFP par Julien Danjou (164 clics)
- Annonce officielle (71 clics)
# Pas très power user mais…
Posté par ianux (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 23 décembre 2012 à 00:57.
Je suis venu à Awesome pour une raison un peu bizarre. En fait, sur mon écran 16/10 en 1280x800, je trouvais que les barres de menu, barres des tâche et décorations de fenêtre bouffaient un peu trop l'espace vertical. J'ai donc cherché un WM léger, utilisable sans décoration de fenêtre et avec une zone de notification. Awesome remplit ce cahier des charges et, utilisant énormément la ligne de commande, le pilotage au clavier est venu comme un bonus. Et le côté pavant est sympa.
Mais je n'ai pas une utilisation très poussée de toutes les possibilités offertes par Awesome, j'utilise les tags comme des bureaux virtuels, je fais pas trop de blingbling, justement, en utilisant un simple conky et bidouille a minima le fichier de conf (je suis pas fan de la syntaxe lua).
Et même dans le cas ou je venais à changer pour un laptop plus puissant, je pense que je continuerai à utiliser Awesome (115 Mo d'usage mémoire avec wicd-gtk, pulseaudio, conky et urxvt(d-c) lancés au démarrage, on va pas bouder notre plaisir).
Enfin, je comprends donc que la MàJ va encore casser la conf. Ça faisait longtemps…
[^] # Re: Pas très power user mais…
Posté par vlamy (site web personnel) . Évalué à 4.
Tout à fait ! Mais à force on ne va plus être surpris. C'est le prix de la « configurabilité » d'Awesome.
Pour cette MAJ, je suis parti du rc.lua donné dans la release, que j'ai ré-adapté à mes besoins et ça m'a pris 20 bonnes minutes (ce qui donne aussi l'occasion de faire un peu de ménage).
Objectif : 10 minutes pour la prochaine release !
[^] # Re: Pas très power user mais…
Posté par chimrod (site web personnel) . Évalué à 3.
Merci beaucoup pour ta participation à la dépêche vlamy !
Le problème de la réécriture de la config se pose surtout pour ceux qui ont écrit leur propres scripts, c'est vrai qu'en restant proche de la config initiale, ça ne pose pas de problème.
Dans tout les cas, c'est dommage de casser l'API, mais c'est parfois nécessaire, et comme toujours, si on su faire le boulot une fois, l'adapter ne devrait pas poser de problème…
[^] # Re: Pas très power user mais… ou pas!!!
Posté par freem . Évalué à 4.
Je vais tenter, malgré l'heure todive (ben oui, le contraire de tardive quoi… me suis fait avoir entre mes mousses et linuxfr…) de discuter…
AWM m'a toujours intrigué. Je n'ai jamais osé l'essayer (oh, le gros troll qui se pointe!) à cause de sa prétention à utiliser un langage de programmation pour configurer le bousin.
Là, normalement, il y a plusieurs types de réactions, et comme mon intention est de bel et bien de faire naître le débat, sans forcément chercher, dans un premier temps du moins - tout en espérant trouver des arguments ennemis assez efficaces pour me convaincre de tester, comme quoi je ne suis pas fermé à 100%, signé, un utilisateur de i3 - , à utiliser awm, je vais essayer de lever les lièvres qui font que je n'ai pas envie de tester cet outils, qui peut, pourtant, potentiellement convenir à mes besoins.
Déjà, le côté "poweruser".
Est-il vraiment nécessaire à un twm? Je suis d'accord quand on parle de laisser à l'utilisateur une grande quantité de libertés. C'est ce qui me plaît, après tout. Mais un logiciel doit-il n'être configurable que par les poweruser, ou doit-il être gérable par tous, mais n'être maîtrisable qu'uniquement par les power users?
Bon, je sais, awm n'a pas pour objectif de séduire les utlisateurs de base… D'ailleurs, selon i3, il semble que les twm soient tous un minimum élitistes…. mais j'en doute :)
Autre point qui m'intrigue, awm est, quand même, un incontournable parmis ceux qui cherchent à essayer un twm.
Pourtant, le point qui m'a fait peur, et me fait encore peur, actuellement, c'est de devoir apprendre un nouveau langage de dev. Sincèrement, je me suis peut-être planté en misant tout sur le natif et pour être plus précis le C++. Mais je me demande, est-il raisonnable de considérer un langage de programmation comme un système de configuration?
Certes, un système de config change le comportement de l'appli… mais l'usage d'un langage de dev ne contraint-il pas, à votre avis, trop l'utilisateur, au risque de le repousser? D'autant qu'il me semble que lua n'est pas un langage utilisant un paradigme classique… mais le paradigme fonctionnel? (vraie question ici, flemme de wikipedier à 5H15 du mat)
Bon, ok, ce post est très trollifère… mais vous noterez ma volonté d'argumenter, et je vous garantis que je suis prêt à essayer, mais que j'ai juste très peur d'essayer un wm qui me fasse apprendre un nouveau langage de dev.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par chimrod (site web personnel) . Évalué à 2.
Alors, je vais essayer de répondre de la même manière, en restant aussi objectif que possible.
En premier lieu, il faut savoir que Awesome est livré avec une configuration de base. Elle est cohérente et fonctionne bien. Ça permet déjà de se familiariser avec le WM sans perdre trop de temps, et déjà avoir une prise en main.
Après c'est comme tout, c'est standard, c'est pas parfait, et il y a toujours des points qui ne nous correspondent pas. Par exemple, dans la config par défaut, le raccourci clavier pour fermer un client est « Mod4 + SHIFT + c ». Ça faisait beaucoup de touches pour une mes petits doigts, et j'ai modifié ça en « Mod4 + c ». C'est pas grand chose, mais une fois qu'on a commencé à modifier la configuration, c'est difficile de s'arrêter là.
Le fait d'avoir un fichier de configuration qui fonctionne aide beaucoup quand on se plonge dedans : au lieu d'avoir la page blanche, on a un déjà une base qui fonctionne, et que l'on peut modifier petit à petit. Même si l'on ne connait pas lua, et le langage n'est pas compliqué — du moins tant qu'on ne cherche pas à l'interfacer avec du C — si l'on se contente de rester bas niveau, il s'apparente à du script/objet (en fait c'est de la Programmation_orientée_prototype) et l'on se plonge assez rapidement dedans.
Pour ma part, je trouve ça très puissant : je vois l'informatique comme un outil, est pouvoir l'adapter et l'utiliser comme bon me semble donne une autre dimension à l'application. Je ne sais pas si tu utilise déjà Vim ou Emacs, mais si c'est le cas, tu devrais déjà ressentir ce que je suis en train de dire.
L'inconvénient est que ça demande du temps. Mais c'est largement rentabilisé à l'usage, crois-moi !
[^] # Re: Pas très power user mais… ou pas!!!
Posté par freem . Évalué à 2.
Moui, j'utilise vim. D'ailleurs, c'est bien ça, le mot juste: j'utilise. Je n'arrive pas à me motiver à le configurer, parce que je trouve que ce n'est pas aisé. (Je rencontre d'ailleurs le même problème avec uzbl…)
J'aime beaucoup cet éditeur, qui à de sacrément bonnes idées (les modes, surtout, qui permettent le reste des bonnes idées, genre hjkl et la foultitude de possibilités de déplacements) mais il possède à mon avis de gros défauts.
Sinon, i3 aussi venait avec une config par défaut qui fonctionne pas trop mal, et quand je vois la simplicité pour le configurer, je me mets à penser que tout devrait être aussi simple, parce que même un lambda serait capable de comprendre comment ça marche.
D'ailleurs, l'auteur mets un point d'honneur à ne pas transformer le fichier de configuration en langage de programmation, ainsi qu'a ne pas ajouter de fonctionnalités inutuiles (genre les bords arrondis… en plus, ça évite les emmerdes avec Apple, c'est ce qu'on appelle faire d'un vers deux pommes, non?)
Je vois aussi l'informatique comme un outil… ou plutôt comme un ensemble d'outils. Je suis plus dans le délire 1 programme => 1 seule tâche moi. Alors l'éditeur de texte qui gère le multi-fenêtrage (tâche qui reviens au wm, pas vrai? Certes, vim est un soft TTY, mais dans ces situations, il me semble que screen peut intervenir?) je trouve ça bof. Certes, c'est une fonctionnalité utile (quand on arrive à l'utiliser), mais est-ce son rôle?
Enfin, ce n'est qu'un exemple (facile en plus, et limite mesquin) mais je trouve que pouvoir tout scripter à tendance à rendre les choses plus complexes pour celui qui débarque, et je ne vois que difficilement l'utilité d'ajouter des modules, au risque de transformer un logiciel propre et efficace en bloatware. (je ne dis pas que ça arrive souvent, je dis juste que c'est un risque)
Par contre, pour le temps rentabilisé, je te crois sur parole, je customise aussi ma bécane à l'extrême (hum… a l'extrême simplicité, dans mon cas) et tu prêches donc un convaincu sur ce point précis.
PS: je vais voir à quoi ressemble ce type de programmation… toujours intéressant de découvrir d'autres paradigmes. Donc merci pour la note.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par detail_pratique . Évalué à 3.
Et encore, t'as pas essayé zino.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par vlamy (site web personnel) . Évalué à 5.
Effectivement, tu mets le doigt sur une particularité d'awesome : on le configure à l'aide d'un langage de script (comprendre de bidouillage) : Lua. Lua qui, au passage n'a rien d'un langage fonctionnel (bien moins compliqué à appréhender et bien moins puissant, à mon avis).
L'objectif, c'est d'avoir un langage qui permet aux utilisateurs de scripter (donc « bidouiller ») des extensions au WM. Cela dit, si tu ne cherches qu'a configurer le WM, c.-à-d. configurer les raccourcis claviers, changer les thèmes, configurer les étiquettes et bien d'autres choses, tu n'auras pas besoin de comprendre le Lua. A l'inverse, si tu veux coder des extensions en Lua, du type gestionnaire d'étiquettes dynamique, widgets écrits en Lua, …etc, tu pourras le faire, mais avec des bases de Lua.
Je trouve que de ce côté là, Awesome donne un bon compromis entre complexité et « configurabilité/bidouillabilité ». Après, pour s'en convaincre, il faut essayer ou commencer par regarder les confs. utilisateurs publiques.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par lolcat . Évalué à 2.
Surtout que lua est un langage plutôt simple à apprendre, ça ne coûte pas cher et ça peut rendre de fiers services, même si je ne me suis pas encore franchement penché dessus.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par barmic . Évalué à 2.
AWM est loin d'être le seul à le faire, xmonad, wmii et dwm le font aussi. Dans les éditeurs de textes emacs se configure en lisp et vim utilise un langage qui est une sorte de langage de configuration évolué.
Personnellement ce que j'aime bien c'est d'avoir pu ajouter simplement le « run or raise » qui lance mon terminal que s'il n'est pas lancé (sinon il me positionne dessus). J'aime bien aussi la gestion du multi écran avec une série de tag pour chaque écran. La programmation ici me permet d'avoir des profils différents sur l'écran externe de mon netbook en fonction de s'il s'agit d'un écran de bureau ou pas.
Je ne suis pas encore allé très loin dans la configuration (la version 3.5 devrait me donner le courage) pour toucher au layout pour créer mon propre layout.
Le lua ne présente aucune difficulté.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas très power user mais… ou pas!!!
Posté par freem . Évalué à 1.
Je le sais. C'est d'ailleurs le peu de choix dans ceux qui ne font pas comme les autres qui m'a fait me décider…
Vim, emacs, word, excel, même les bureaux, de nos jours en viennent à utiliser le paradigme du langage de script intégré.
Signe de qualité? Hum, j'en doute, en fait, non, je suis
convaincupersuadé du contraire!Je t'accordes volontiers que ces projets n'ont que peu de choses en commun et surtout pas leur objectif, mais.. en fait, ce qui me fait peur, en tant que bidouilleur, c'est peut-être pas d'apprendre un nouveau langage en soi, après tout, je maîtrise déjà C++ et une bonne partie de ses subtilités, et j'ai entamé l'apprentissage de prolog et perl l'an dernier (sans trop aller loin, ok, mais par manque de temps, il faut que j'acquiere de nouveaux paradigmes de pensée pour un projet de jeu personnel).
Par contre, de commencer à utiliser un outil, sachant que je suis le seul de mon entourage à aimer l'informatique, j'aime m'assurer que le temps ne sera pas entièrement perdu.
Hors, si pour configurer un wm, je dois apprendre un nouveau langage, fut-il "simple et peu coûteux", ça ne va pas.
Pourquoi?
Parce que, tout bêtement, j'ai déjà un wm que je maîtrise, qui est simple, mais pour de vrai, à configurer, et qui est extensible via IPC. Le wm en question se prétend élitiste, mais moi, j'ai envie de crier "menteurs!" parce qu'il est simple et efficace.
Il est élitiste dans le sens ou il se contente de gérer les fenêtres. Pas leur contenu.
Marrant, tu parles de vim… et, justement, ce qui fait que vim est, selon moi, un mauvais (j'ai bien dis mauvais, et tant pis pour les moins) éditeur de texte, c'est qu'il ne fait pas qu'éditer du texte.
Il gère aussi des fenêtres. Mal, d'ailleurs.
Il gère aussi les interactions avec le reste du système. De façon honteuse, parce qu'il est pas foutu de faire un copier/coller avec les numéros de lines affichés (entres autres) d'un émulateur de terminal à l'autre.
Oui, ** vim, c'est de la merde ** d'un point de vue UNIX. D'ailleurs, à ce que j'ai compris, emacs ne vaut pas mieux…. oh mon dieu, j'ai tapé sur les 2 éditeurs de texte populaires… allez, -5, -7?
Pour remonter ma moyenne, je vais dire qu'a l'heure actuelle, aucun éditeur de texte ne fait ** que ** son job, dès lors qu'il intègre une IHM.
Et sans IHM, un éditeur de texte n'est que l'ombre de lui-même….
J'ai rien de mieux à proposer, pour le moment, c'est vrai. Mais pour rester vrai, j'y travaille, parce que je pense honnêtement que les éditeurs de texte et les IDE actuels sont le genre d'outils qui font dire que c'est vraiment le cordonnier le plus mal chaussé.
Et l'IDE qui en résultera sera trop spécialisé, ne fonctionnera que sur les UNIX et aura des tonnes d'autres défauts. Mais, il me conviendra (quoique… il faut que je parvienne à trouver un outil pour parser du C++ et faire un dégage stable…)
[^] # Re: Pas très power user mais… ou pas!!!
Posté par Mali (site web personnel) . Évalué à 3.
Essayes nano.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par barmic . Évalué à 2.
J'ai pas dis que c'était un signe de qualité ou un défaut. C'est juste ainsi. J'utilise firefox que je configure via l'interface graphique, je ne trouve pas que c'est mauvais ou pas, mais pour des besoins très spécifiques j'utilise un fichier .pac pour les proxy et ça c'est de la programmation.
D'une manière générale (que ce soit pour de la configuration ou du développement) apprendre un nouveau langage ne me fait pas peur bien au contraire. Ça permet de s'ouvrir l'esprit. Les langages ne sont pas des vases clos et ce que tu apprend de l'un te servira toujours dans l'autre, c'est systématique. Tu peut regarder mon dernier journal sur l'utilisation du paradigme fonctionnel en C++ par exemple. Ensuite je trouve que la dénomination de langage de programmation est très formelle. Le xml en est un et une énorme quantité de logiciel se configurent via du xml, il n'en sont pas pour autant mauvais. Pour moi la seule différence entre un langage comme le yaml et le lua c'est qu'il ne s'agit pas du même paradigme.
Je vois pas le rapport avec l'entourage (je suis le seul utilisateur d'awesome de mon entourage), mais tu ne perd du temps que si tu n'apprends rien, ce n'est à mon avis pas le cas.
Ben c'est cool.
Alors :
Je ne sais pas d equoi tu parle. Pour moi il ne gère pas les tampons du système. Pour ça j'utilise xclip et des commandes comme :
pour coller (bien sûr c'est mappé sur un raccourcis). Donc je ne vois pas où est le problème : tu n'aime pas sa gestion des copier/coller ? Ne t'en sert pas. C'est là l'un des points agréable avec la configuration par programmation.
Quand tu utilise un langage type xml pour configurer un logiciel tu es limité par l'imagination des développeurs du logiciel. S'ils ont prévus la conf tant mieux sinon tampis. La configuration par programmation offre beaucoup plus d'ouverture. Au lieux de dire que les décoration des fenêtres font N px tu peux définir que cela dépend de la taille et de la résolution de ton écran de la météo ou du jour de la semaine. Au lieu de gérer des hooks comme « sur l'appui de tel touche je lance telle commande qui est en fait un script de ma création », tu peut directement tout faire dans un même langage ou sortir de ce langage si l'envie te prend. Pour awesome et wmii c'est déjà écorme la quatité de configuration que tu ne peux faire, mais pour dwm, emacs ou xmonad c'est encore plus énorme car tu peut aller vraiment bidouiller les entrailles du logiciel (dans awesome, wmii et vim le langage est une interface alors que dans emacs, dwm et xmonad tu programme réellement le logiciel).
Je ne dis pas que c'est mieux ou moins bien, je dis juste que ça ouvre infiniment plus de possibilité sans être pour autant forcément très compliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas très power user mais… ou pas!!!
Posté par freem . Évalué à 0.
Ce que je voulais dire, ce n'est pas qu'apprendre un langage me fait peur en soi, mais apprendre un langage pour configurer un logiciel, me fait craindre par rapport à la complexité que ce logiciel possède.
Cependant, je dois admettre un minimum que j'ai un peu de mal a apprendre de nouveaux langages, tout de même, mon principal argument (bidon, clairement, même moi je le dis et le pense) étant que ça m'emmerde d'apprendre à utiliser un nouveau framework pour faire le moindre truc.
Cela dis, j'envisage très sérieusement, j'ai déjà commencé en fait, d'apprendre prolog, uniquement parce que c'est un paradigme radicalement opposé à ceux que je connaît.
Si je devais conclure ce point, je dirai qu'apprendre un langage ne me gêne pas, tant qu'il m'apporte un paradigme que je ne connaît pas, et pour lequel j'ai des idées d'applications.
J'ai limite envie de dire que savoir certains langages fait que l'on en connaît automatiquement d'autres: genre celui qui connaît C++, saura écrire du Java et du C# (bon, pas avec les astuces de chaque langage), alors que le contraire ne sera pas
forcémentsouvent vrai (je parle, en n'ayant jamais touché l'autre langage, simplement en regardant un bout de code moyen et en le modifiant, hein, pas de trucs à grande échelle ni super optimisés.)Et pour conclure cette première conclusion, je crois que le lien "fonctionnel" -> "mathématique" , probablement erroné, et les bouts de code composés à 50% de '(' et ')' me font un peu flipper tout de même :/
Je l'ai lu, j'ai une tendance à bien aimer lire ce qui touche à ce genre de choses (mêler les paradigmes dans un seul langage). Et je dois même dire que depuis j'ai un peu moins peur de ce paradigme, si c'est celui auquel je pense…
Euh… Désolé, je vais faire mon chieur, c'est p'tet parce que je n'aime pas xml, mais xml, bien qu'étant un langage, n'est pas un langage de programmation, mais de description. Même que c'est dans le nom… "langage de balisage extensible". Une balise, ça décrit, ça ne programme pas…
Ah, et, oui, ça implique que html 4 et 5 ne sont pas des langages de prog. JS, PHP, oui, en revanche, c'en sont.
Je vais dire un truc tout simple: j'ai plus d'attirance envers yaml qu'xml. Au moins, c'est à peu près lisible par l'oeil, compact, et il me semble même qu'il soit possible de le parser en une seule passe tout en étant sûr de la validité, contrairement, il me semble, a XML.
Il y a donc là gain de performance CPU, de place (important sur le réseau, il me semble… faudra que je redemande à des utilisateurs de 3G qui dépassent leur limite souvent pour en être sûr :D ) et de lisibilité.
Oui, j'aime bien YAML, et, en plus, je trouve JSON meilleur qu'XML: moins verbeux, c'est déjà ça…
En revanche, j'insiste, pour moi, ce ne sont pas des langages de programmation, ils se contentent de décrire: telle donnée de tel type possède telle valeur.
Je ne crois pas qu'il y ait des boucles, des conditions, des variables… bref, de la programmation.
[^] # Re: Pas très power user mais… ou pas!!!
Posté par barmic . Évalué à 2.
Et puis un jour on découvre ant, un autre jour on découvre Oracle Service Bus et on se rend compte qu'XML peut très bien servir de langage de programmation. Le paradigme est différent mais ça n'est pas un problème.
C'est à mon avis un énorme problème d'une manière générale… Beaucoup trop de monde laisse leurs choix dictés par de l'affectif et non par des faits.
Compact et lisible sont deux choses trés différentes. Compact oui on ne peux pas dire le contraire yaml est plus compact que xml, mais pour ce qui est de la lisibilité c'est discutable. yaml (comme json par exemple) t'oblige à connaître le format pour pouvoir lire un document, alors qu'xml quand c'est bien fait c'est autodécrit (comme les fichiers ini) :la balise contient le nom d'utilisateur par exemple. yaml est sensible au formatage ce qui n'est pas le cas de XML (ni de JSON par exemple) c'est dommages d'un point de vu de la lisibilité.
Avec yaml tu peut valider la syntaxe, alors qu'avec XML tu peut valider la gramaire complète (tu peut valider que la balise doit contenir 2 balises , tu peut valider le format des données). Je n'ai aucune idée du nombre de passes, mais ça n'a pas d'intérêt une passe lourde et bien plus longue que 2 ou 3 passes légères (c'est aussi un mythe qu'il y avait à propos de la compilation il y a quelques décénies). Bien sûr cela dépend de la taille du fichier à analyser.
Alors… Pour la lisibilité j'en ai déjà parlé, pour la place oui, pour les performances c'est différents. Pour de tout petits document oui, mais xml permet de traiter les documents comme un flux (avec les analyseurs SAX ou PAX) ce qui permet d'avoir de bonnes performances malgrès la taille des données (ou la lenteur de l'accès).
Oui le XML pose souvent des problèmes à cause entre autre de l'utilisation de requètes XPath qui sont nuisibles pour les performances, alors qu'il vaut mieux avoir une étape d'analyse du fichier XML qui récupère toutes les données en une seule fois.
Le shell est un langage de programmation ou une interface ? Les makefiles sont de la programmation ou une description du projet ? Il n'y a pas de boucles en lisp ce n'est pas pour ça que ce n'est pas un langage de programmation. Le XML dans une parties de ces gramaire permet d'avoir des variables, des fonctions, des confitions etc. C'est pas agréables à utiliser parce que ce n'est pas le paradigme pour lequel il est fait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# vs fluxbox ?
Posté par wilk . Évalué à 2.
Je me demande toujours quels seraient les avantages par rapport à fluxbox par ex vu que je le pilote déjà entièrement au clavier avec des raccourcis à la vim…
[^] # Re: vs fluxbox ?
Posté par lolcat . Évalué à 1.
cf http://linuxfr.org/nodes/96775/comments/1418519
[^] # Re: vs fluxbox ?
Posté par vlamy (site web personnel) . Évalué à 4.
Si ton seul critère est la gestion au clavier, alors effectivement : pas la peine de changer de WM si tu y arrives déjà avec fluxbox.
Bien entendu, awesome propose la même chose.
Si tu as d'autres critères, nous serons ravis de t'expliquer en quoi awesome peut (ou ne peut pas) les satisfaire.
[^] # Re: vs fluxbox ?
Posté par wilk . Évalué à 3.
Je n'ai à priori pas d'autres critères que de pouvoir contrôler mes quelques fenêtres avec les raccourcis VIM. Mais peut-être que je passe à côté de quelque chose dont je n'ai même pas l'idée ?
[^] # Re: vs fluxbox ?
Posté par chimrod (site web personnel) . Évalué à 3.
Un petit exemple de ma config (basé sur une extension, shifty) :
quand j'appuie sur la touche « XF86Mail » je demande l'affichage du tag « mail » Dans la définition de ce tag, il est demandé de lancer mon client mail à la création.
Résultat, si l'appli est déjà lancée, elle s'affiche, si elle n'est pas lancée, elle va se lancer automatiquement. Cela permet d'être sûr que l'application ne sera lancée qu'une fois, et laisser awesome s'occuper de la lancer ou non. (au final, ça n'occupe pas mon écran puisqu'elle est lancée dans une étiquette part).
Autre exemple : gimp. On dit souvent que Gimp possède mauvaise une interface graphique. J'ai configuré awesome pour que la fenêtre Gimp n'utilise que 15% de l'écran, en laissant le reste pour la fenêtre du dessin. Une image valant mieux qu'un discourt, voici le placement par défaut :
Le but étant de ne pas avoir à me soucier de placer les fenêtres quand je lance une application, tout est géré de manière automatique…
[^] # Re: vs fluxbox ?
Posté par chimrod (site web personnel) . Évalué à 2.
note : sur la capture, je ne sais pas d'où viens le rectangle noir (problème d'
import?), et j'ai voulu faire vite : je ne vais pas passer ma soirée devant le PC.Sur ce, bon réveillon !
[^] # Re: vs fluxbox ?
Posté par wilk . Évalué à 1.
Jusque là je le fait aussi avec fluxbox puisqu'on peut mémoriser l'emplacement et le workspace des fenêtres. Je fait pareil avec le navigateur et le client mail qui sont donc toujours dans leurs workspaces respectifs et à la même place. C'est vrai que je peux lancer plusieurs fois le client mail, mais si je voulais m'en préserver je pourrai faire un petit script pour ça.
[^] # Re: vs fluxbox ?
Posté par gouttegd (site web personnel) . Évalué à 3.
Je ne pense pas que le pilotage au clavier soit la caractéristique marquante de Awesome ; en tout cas, ce n’est pas celle qui m’intéresse le plus. Pour moi, le principal intérêt d’Awesome est davantage sa grande « bidouillabilité ».
Après, ce n’est pas le seul gestionnaire de fenêtres bidouillable, certes. wmii, que j’utilisais auparavant, est aussi très bien de ce point de vue (à mon avis il est même mieux, en fait, parce qu’il laisse le choix du langage de script au lieu d’imposer Lua) — mais il gère très mal les écrans multiples, à la différence de Awesome.
[^] # Re: vs fluxbox ?
Posté par p403 . Évalué à 1.
Peut-être parce-que awesome est le seul gestionnaire de fenêtre à utiliser XCB.
[^] # Re: vs fluxbox ?
Posté par freem . Évalué à 2.
C'est une réponse intéressante.
Pourrais-tu nous décrire les intérêts de XCB? Sans compter que, bien entendu, XCB est obsolète vu que wayland tape aux portes?
Oui, je trolle, je sais…
Mais, venant d'un tout nouveau wm, je pense qu'adapter le code à wayland aurait été un plus gros attrape-geek qu'a XCB.
Ce que je veux dire, c'est que dire qu'on dépends d'une lib A au lieu de la lib B, sachant que les libs A et B font la même chose, ne me semble pas offrir un intérêt si important que ça.
Mais, si quelqu'un m'explique l'immense avantage, je suis tout ouïe…
[^] # Re: vs fluxbox ?
Posté par Juke (site web personnel) . Évalué à 2.
Il me semble que c'est également le cas de i3.
[^] # Re: vs fluxbox ?
Posté par Shuba . Évalué à 1.
Qt5 utilisera XCB au lieu de la Xlib non? Donc ça devrait profiter à KDE.
# sauveur de netbook
Posté par zplinux (site web personnel) . Évalué à 2.
J'ai essayé la version d'avant packagé dans ubuntu hier soir apres avoir lu cette article, et je dois avouer que ca semble tres agréable à l'utilisation.
Et niveau utilisation des resources sur un netbook avec atom la différence se resent vraiment par rapport à kde ou gnome shell.
J'ai bien aimé le fait d'avoir un accés direct au manuel sur le bureau comme ca, c'est rafraichissant :)
[^] # Re: sauveur de netbook
Posté par freem . Évalué à 2.
Je compatis, mais outre les ressources systèmes, un point super intéressant avec ce type de wm, c'est le gain de place à l'écran.
L'atom, j'ai aussi, avec XFCE, il s'en sortait pas trop mal. Mais depuis que j'ai viré de mon esprit l'idée d'utiliser un DE classique pour un wm en tuile, accompagné d'une savante sélection de logiciels, il est plus rapide que certaines machines de bureau, et le manque de place à l'écran est nettement moins handicapant (parce que bon… 1024*600 sur un 10"… aieu!)
# Point fort : le multi-écran
Posté par lolcat . Évalué à 2.
Bonjour,
au risque de répéter ce qui est dit dans l'article, un des intérêts de awesome est sa gestion native du multi-écran (mod4+o pour envoyer une fenêtre sur l'autre écran, mod4+shift+j pour switcher l'écran). Je n'utilise plus que ça, c'est très pratique pour taper un code latex et visualiser le résultat en direct sur l'autre écran, ou pour d'autres tâches similaire, comme par exemple la traduction, la lecture de documentation en parallèle avec la programmation, etc.
[^] # Re: Point fort : le multi-écran
Posté par freem . Évalué à 1.
Cette idée de balancer directement une appli sur un écran précis est intéressante, i3 ne peut pas le faire si je ne m'abuse… (i3 considère simplement que le dual-screen "n'existe pas", 1 workspace= 1 écran, donc en fait on manipule plus des workspace, typiquement, j'utilise les workspae 8,9 et 0 sur l'écran secondaire, donc il faut que je fasse $mod+x ou x est le numéro du workspace. Parfois ennuyeux, mais ça va encore.)
Par switcher l'écran, tu veux dire balancer le contenu de l'un vers l'autre et vice-versa, ou juste changer d'écran?
[^] # Re: Point fort : le multi-écran
Posté par lolcat . Évalué à 1.
juste passer le focus sur l'écran voisin.
[^] # Re: Point fort : le multi-écran
Posté par freem . Évalué à 1.
Ah… ben, je vais devoir être honnête alors, il n'y a rien ici d'extraordinaire, du moins pour un wm en tuiles… cela dis, je dois admettre un point, si je suis resté aux tuiles, c'est grâce à leur supériorité dans le multi-écran et dans les petits écrans, supériorité due à la simplicité du concept. Simple, et efficace, comme diraient mes ancêtres (grands-mères, vu que les mâles ont passé l'arme à gauche depuis plusieurs années)
# Encore tout casser ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
Je suis pas mal déçu de voir qu'il va falloir recommencer toute ma config. J'avais déjà retardé mon passage à la version 3 car j'avais déjà du refaire ma config entre la 2.0 et la 2.2 (et la 2.4 avait encore tout changé je crois). C'est vraiment mais vraiment chiant de passer plusieurs jours à chaque fois à reconfigurer son environnement de travail sérieux, je veux juste un truc qui marche. Et je ne peux pas utiliser la config par défaut car de 1. je n'ai pas de touche windows sur mon clavier de 2. les raccourcis par défaut me semblent totalement illogiques (enfin chacun son truc ça) et de 3. il faut bidouiller pendant des jours, trouver un script qui marche, l'adapter etc. juste pour avoir des trucs de base genre l'état de la batterie ou du réseau dans la barre des tâches…
Donc là franchement voir que je vais encore une fois devoir tout refaire ça commence vraiment à me saouler… Surtout que j'imagine qu'il va encore falloir tout refaire, avec quasiment aucune indication de ce qu'il faut faire (genre impossible de porter ma config de 2.0 à 2.2 malgré des jours à me prendre la tête). Au secours !
Quelqu'un aurait pas un truc un peu plus stable svp ?
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Encore tout casser ?
Posté par Juke (site web personnel) . Évalué à 2.
i3 semble stable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.