Lidecli : Un outil en ligne de commande pour interagir avec les environnements de bureau

Posté par  . Édité par Julien Jorge, Benoît Sibaud et Ysabeau 🧶. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
48
13
juil.
2023
Ligne de commande

Lidecli - abréviation de Linux Desktop CLI - est un wrapper libre (MIT) développé en Python permettant de scripter plus facilement le positionnement de vos fenêtres quel que soit votre environnement de bureau. Habituellement, scripter ou automatiser le positionnement des fenêtres nécessite :

  • l’utilisation d’outils bien connus (wmctrl, xprop, qdbus, xrandr, etc.),
  • ou, pour certains environnements - du code (LUA pour AwesomeWM par exemple).

En d’autres termes, il n’existe pas vraiment de moyens « simples » permettant de scripter à sa guise son environnement. Lidecli agit comme un wrapper qui simplifie grandement cette tache.

Lidecli

Lidecli par l’exemple

  • Vous souhaitez donner le focus à votre terminal via un raccourci-clavier configuré au niveau de votre environnement ?
    lidecli.py x-focus-name Terminal

  • Vous voulez mettre votre navigateur web en plein écran ?
    lidecli.py x-set-win-name-fullscreen Firefox

  • Vous souhaitez déplacer votre navigateur web sur votre second moniteur ?
    lidecli.py x-move-win-name-screen Firefox 2

  • Vous souhaitez changer l’opacité de votre terminal à 80% ?
    lidecli.py x-set-win-name-opacity Terminal 80

  • Vous avez l’habitude d’ouvrir plusieurs VSCode et souhaitez pouvoir basculer de l’un à l’autre via des raccourcis-clavier ?

    lidecli.py x-focus-name-nth "Visual Studio" 1
    lidecli.py x-focus-name-nth "Visual Studio" 2
    lidecli.py x-focus-name-nth "Visual Studio" 3

Il vous suffit d’associer - dans votre environnement de bureau - ces commandes à des raccourcis-clavier, et le tour est joué !

Plus de 160 commandes disponibles

L’outil est livré avec plus de 160 commandes qui peuvent être affichées en tapant :

lidecli.py -l

Chaque commande possède plusieurs tags (étiquettes), notamment pour mentionner quels outils sont nécessaires à son fonctionnement (wmctrl, xprop, etc.), les environnements de bureau compatibles le cas échéant, et si la commande est compatible X ou Wayland.

Il est possible de filtrer la liste des commandes en fonction des tags. Par exemple, lidecli.py -l -t x11 -n kde affichera la liste des commandes compatibles X mais qui ne sont pas spécifiques à KDE.

Un autre moyen de consulter les commandes disponibles est de consulter le site de l’outil : https://lidecli.com

Initialement, Lidecli a été développé pour KDE pour éviter les appels D-BUS, ce qui explique le nombre important de commandes dédiées à cet environnement de travail.

Mais Lidecli s’est ensuite étendu en utilisant les outils génériques de type wmctrl, et on peut donc l’utiliser quel que soit son environnement. À noter que le nombre de commandes pour Wayland semble pour le moment assez limité puisque le contrôle des fenêtres est dépendante du gestionnaire de fenêtres utilisé, contrairement à X ou l’architecture (et la sécurité) est différente.

Un wrapper, mais aussi un framework

Lidecli est un wrapper/une surcouche qui fait appel aux binaires usuels dédiés au scripting des fenêtres et écrans. Mais il s’agit également d’un framework, puisqu’il est relativement simple d’ajouter de nouvelles commandes. En effet, l’intégralité des commandes sont enregistrées dans un fichier unique - db.py - contenu dans le repository.

Chaque commande est simple à définir : nom, description, tags, les arguments, et les commandes shell à exécuter.

Exemple de définition d’une commande simple permettant de fermer une fenêtre :

 {
    "name": "x-kill-win-name",
    "description": "Kill a window specified by its name",
    "forwarded_arguments": [
        { "name": "WinName", "description": "The part of the window name to kill"}
    ],
    "command": "wmctrl -c #1#",
    "versions_working": [("x11", "all")],
    "versions_not_working": [],
    "tags": ["x11", "windows", "wmctrl" ]
},

Il est également possible de faire appel à des callbacks (en Python) pour analyser le résultat de certaines commandes shell. De la même façon, une nouvelle commande peut faire appel à du code Python et non des commandes shell, pour des cas plus complexes.

Un outil pratique

L’idée de réaliser un outil unifié permettant de gérer ses fenêtres en ligne de commande semble intéressante. Même si des outils comme wmctrl accomplissent des merveilles, certaines tâches sont parfois plus complexes et nécessitent le développement d’un script. Ce manque est comblé par Lidecli.

À titre d’exemple, pour déplacer une fenêtre d’un moniteur à un autre sans changer sa géométrie ni son positionnement relatif, il est nécessaire d’avoir la configuration des écrans (avec xrandr par exemple), puis de faire des calculs d’offset pour repositionner la fenêtre à l’endroit souhaité.

De la même façon, pour donner le focus à la 3e fenêtre d’une application donnée (si vous avez 3 terminaux ouverts par exemple), il est possible de le faire avec wmctrl seulement mais ce n’est pas trivial :

wmctrl -lx |grep Terminal | cut -d ' ' -f1 | head -3 | tail -1 | xargs wmctrl -i -a

Lidecli semble donc combler un manque et offrir la possibilité à tous - sans connaissances particulières - de scripter leur environnement de travail relativement aisément.

Enfin, si une communauté se développe autour de l’outil (diffusé sous license MIT), cela pourrait ouvrir la voie à une véritable bibliothèque pour gérer aisément la disposition des fenêtres en ligne de commande quel que soit son environnement.

Aller plus loin

  • # Kdecli ?

    Posté par  (site web personnel) . Évalué à 1.

    C'est très intéressant, je me pencherai dessus quand j'aurais un moment !

    Je note beaucoup de commandes commençant par kde, mais aucune par gnome ou xfce.
    Est ce le support de kde qui est plus avancé ou au contraire nécessite-t’il des commandes spécifiques ?

    • [^] # Re: Kdecli ?

      Posté par  . Évalué à 7.

      Pour XFCE et plus généralement les Desktop qui tournent uniquement sur X11, je crois que ça n'aurait pas de sens car il est compatible EWMH/netWM donc tout peut être fait par wmctrl et ce type d'outils.

      Là ou la spécialisation est nécessaire, ce sont les DE qui tournent sous Wayland (ou sur X et Wayland comme KDE et Gnome).

      Toutes les commandes qui utilisent D-BUS (qdbus / dbus-send) fonctionnent à la fois sous X et sous Wayland. C'est l'idéal bien entendu, mais ces appels sont difficiles et mal documentées pour un utilisateur. Le travail a été partiellement fait pour KDE de façon très laborieuse en piochant à droite et à gauche les appels DBUS pour les tâches les plus courantes.

      Le problème de fond c'est qu'il n'y a pas de docs "user-friendly" sur les appels disponibles (on est très loin de documentations comparables aux API web par exemple). On peut dumper / voir tous les appels D-BUS (exemple pour KDE ici) mais c'est pas vraiment intuitif/utilisable.

      Idéalement il faudrait le faire pour Gnome également en effet.

      Il y a tout de même une exception dans la qualité des docs : Sway (équivalent de i3 sous Wayland), et leur outil swaymsg qui permet d'interagir en ligne de commande avec le desktop. Et même une page man assez exemplaire avec toutes les commandes disponibles.

      Quoi qu'il en soit, cela interroge sur Wayland. Avoir des API différentes pour chaque DE - plus ou moins bien documentées - pour scripter des fenêtres, cela risque de devenir pénalisant pour l'utilisateur sans un wrapper.

      • [^] # Re: Kdecli ?

        Posté par  (site web personnel) . Évalué à 4.

        sous OS/2, fallait déjà apprendre à faire du REXX pour configurer son bureau…

        mais bon, IBM n'a jamais réussi à le faire comprendre à ses commerciaux :/

      • [^] # Re: Kdecli ?

        Posté par  (site web personnel) . Évalué à 3.

        Le problème de fond c'est qu'il n'y a pas de docs "user-friendly" sur les appels disponibles …

        Ça.

        Et je me pose cette question : Linux c'est RTFM et pages de man, mais pas dans ce cas-là. Autant j'aime KDE/Plasma, autant le manque de doc me surprend. Et je ne parle pas des autres DE.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

        • [^] # Re: Kdecli ?

          Posté par  (site web personnel) . Évalué à 3.

          La doc, c'est long à faire.
          Il y a aussi les traductions dans les différentes langues.

          Sur Matrix, il y a 4 room KDE:
          - KDE branchée sur le bridge IRC
          - KDE Debian branchée sur le bridge IRC
          - KDE francophone
          - KDE germanophone
          Et probablement d'autres

          Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # Pas d'extension

    Posté par  (site web personnel) . Évalué à 10.

    Bonne initiative, mais attention à ne pas tomber dans le trou Microsoft. Sous UNIX, les exécutables n'ont pas d'extension et ne doivent pas en avoir. Un bon exécutable doit pouvoir être reprogrammer dans un autre langage. Et puis, on s'en fout qu'il soit programmé en Python, C, Rust… lors de son utilisation.

    Bref, le renomme lidecli sans l'extension .py finale très moche.

  • # installation & dépendances ?

    Posté par  . Évalué à 3. Dernière modification le 15 juillet 2023 à 11:45.

    bonjour,

    Apparemment l'installation nécessite prettytable et d'autres paquets python,
    ce serait bien d’avoir une section install dans le readme avec la liste des dépendances.

    Il me donne cette erreur :

    lidecli.py -l                                                                                                                                                        
    
    Traceback (most recent call last):
      File "/home/david/racine/local/bin/lidecli.py", line 9, in <module>
        import parsing_callbacks
    ModuleNotFoundError: No module named 'parsing_callbacks'
    zsh: exit 1     lidecli.py -l
    

    quel paquet faut-il installer ?

    Si jamais tu souhaites le publier sur pypi.org, un lien que j'ai trouvé vite fait : https://packaging.python.org/en/latest/tutorials/packaging-projects/

  • # Wrapper unifié ?

    Posté par  . Évalué à 5.

    En lisant le titre de la dépêche, j'ai compris que l'idée était de faire un outils qui gomme les différences d'API entre les environnements de bureau.
    Mais après lecture il me semble que c'est plutôt un outil qui facilite et uniformise l'utilisation d'API, quelles soient spécifiques ou non.

    Est ce que ça serait dans les plan de gommer ces différences quand il y en a, par exemple, si une commande particulière est disponible via une API sous gnome et une différente sous kde, proposer une commande lidecli unique qui fait le bon appel selon l'environnement en cours d'utilisation ?
    Je n'ai pas l'impression que ça soit l'objectif de l'outil. Mais c'est quelque chose qui pourrait se greffer par dessus.

    • [^] # Re: Wrapper unifié ?

      Posté par  . Évalué à 3.

      Je m'attendais à ça aussi. Un fichier de configuration qu'on puisse trimballer de DE en DE, de WM en WM, sans devoir y toucher.

Suivre le flux des commentaires

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