Gnu/Linux, Ubuntu

Essayez Final Term, un terminal très moderne

screencast

Final Term est un projet de terminal pour GNU/Linux, qui va changer sûrement l’idée et l’image qu’ont certains sur les interfaces des terminaux. Son auteur, Philipp Emanuel Weidmann, s’est beaucoup inspiré des IDE et le résultat est bluffant, bien que l’application soit encore qu’à ses débuts .

Parmi les fonctionnalités qui m’ont séduit dès les premières captures d’écran que j’ai vu, il y a la complétion automatique des commandes, via l’historique de ceux déjà exécuté. Très pratique si on veut éviter de ressaisir des longes lignes de commandes.

autocompletion

Quand vous listez les éléments d’un répertoire, si vous cliquez sur fichiers ou dossiers, une boite de dialogue s’ouvre, vous présentant quelques commandes que vous pouvez exécuter (copier/coller, copier le nom du dossier/fichier, déplacer, suppression…).

L’autre fonctionnalité qui m’a vraiment plu, c’est la capacité de Final Term de prendre correctement en charge le texte affiché dans votre terminal que vous redimensioner ce dernier.

reflow

Bref, c’est juste un petit aperçu des nombreuses fonctionnalités qu’offre Final Term, je ne les ai pas toutes cité, les curieux peuvent se rendre sur le site du projet et les découvrir, où ils peuvent installer Final Term. Pour Ubuntu, un dépôt PPA a été mis en place par le développeur de l’application :

sudo add-apt-repository ppa:finalterm/daily
sudo apt-get update
sudo apt-get install finalterm

Pour les autres distributions, il existe des explications sur la procédure d’installation depuis les sources sur la page github du projet.

11 Comments

  1. J’ai un message d’erreur concernant une librairie indisponible :(
    “Les paquets suivants contiennent des dépendances non satisfaites :
    finalterm : Dépend: libkeybinder-3.0-0 (>= 0.3.0) mais il n’est pas installable”

  2. Même en faisant comme indiqué sur leur site un
    “export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/” :(

  3. Cet émulateur de terminal Linux est plein d’avenir mais tu a oublié de précisé qu’a l’heure actuel il est encore instable et qu’il est même déconseiller pour le moment de l’utiliser dans une optique de production et/ou journalière.

  4. Je suis moi aussi particulièrement intéressé par de nombreux points de finalterm, c’est un projet que je trouve très intéressant et qui propose enfin certaines fonctions qui sont absentes de tous les terminaux (c’est quand même incroyable qu’en 2013, un terminal ne puisse pas redimensionner son contenu lorsqu’il est redimensionné !).

    Par contre, pour l’instant, il y a certains points qui me semblent carrément rédhibitoires :

    - C’est lent. Même le terminal par défaut de Ubuntu se lance beaucoup plus vite, c’est dire ! Et c’est pas seulement au démarrage, à l’usage aussi il y a un sentiment de latence…

    - il ne supporte pas le clic milieu pour coller du texte, il ne supporte pas non plus le glisser-déposer de fichier…

    Ce sont des points importants qui font que pour l’instant je ne peux pas utiliser le projet en production. Vraiment dommage.

    • Super projet. Plein de bonnes idées !

      Il manque plein de fonctionnalités et certains défauts rendent effectivement son utilisation difficile pour l’instant.

      Mais ça donne envie de l’utiliser et de contribuer :)

    • C’est lent ? Étonnant cela, à mon avis c’est vraiment un soucis de version en développement car en tout cas de ce que j’ai pu lire du code, l’interprétation des séquences ne peut être que plus rapide que celles de GTerm. Maintenant je n’ai pas regardé la boucle de rendu, c’est un point très critique pour un terminal. Si ce n’est pas optimisé, le terminal va écrire chacun des caractères de la matrice un par un, espaces compris, ce qui peut être très consommateur avec libFreetype.

      Mais du coup, vu le points négatifs que tu cites, quels sont les points positifs de ce terminal pour toi ?

  5. Alors je n’ai pas testé directement car les dépendances de ce projet me semble un peu overkill pour le besoin (glee, gtk3, Clutter, Mx, etc..) et mes remarques sont donc plus des questionnements que des affirmations sentencieuses :)

    Pour commencer par le très positif, l’auteur de FinalTerm a fait les choses bien car ce n’est pas un nième terminal utilisant la nullissime libvte, mais bel et bien sa propre implémentation de l’émulation vt220. Donc ça doit au moins être aussi rapide qu’urxvt (avec un code sûrement plus compréhensible ;-).

    Il me semble cependant que les fonctionnalités que tu évoques sont surtout utiles à ceux qui utilisent essentiellement leur terminal pour du travail en ligne de commande. Si l’on prend le rewrap par exemple, il ne peut j’imagine pas fonctionner sur une command “man” (essaye un man en petite taille de fenêtre, puis redimensionne en plus grand, le texte du man devrait rester étroit). La raison est que les applications texte gèrent généralement elles même (bien ou mal ;) le rewrapping. Certains plus évoluées ou utilisant des framework comme ncurses feront le boulot dynamiquement, d’autres comme man, font cela une fois pour toute et c’est donc mort après pour redimensionner. En revanche si tu utilises la commande “cat” , qui n’opère aucun traitement, les lignes longues seront gérées par le terminal et là le rewrap va fonctionner. Sauf que ça, urxvt le fait déjà très bien (contrairement à xterm). Maintenant si tu me dis que finalterm rewrap aussi le man, je cours voir comment il fait ;-)

    Pour ce qui est de l’auto-complètement, mise à par un visuel qui peut convenir à certain, pour moi c’est avant tout le travail de l’applicatif et non du terminal. Un interpréteur évolué de ligne de commande comme zsh fait même des merveilles sur ce point précis. Et si l’on repasse au niveau applicatif, toute les applis qui ont à gérer des popups utiliseront leur système de toute façon (ex. vim). Du coup une fois de plus c’est un avantage surtout pour la ligne de commande et un avantage qui me semble plus relever du conflit d’intérêt. Sur ce point je n’ai jamais trop compris d’ailleurs pourquoi personne n’avait jamais eu l’idée de coder un shell en utilisant ncurses. Cela permettrait entre autre de jolie (tout est relatif ;-) popups plutôt que les menus à la zsh.

    Après il y a l’interprétation des éléments sémantiques qui sont des choses parfaitement implémentable sur urxvt (ce n’est qu’un exemple). Il existe déjà des greffons pour interpréter par exemple les URLS. Maintenant là aussi il n’y a pas de miracles. Si par exemple on utilise Mutt avec le panel de gauche et que l’URL est sur deux lignes, bien malin sera le terminal capable de détecter la dite url séparée en deux par une volée de caractères UTF8. Ceci étant dit, la notion sémantique est déjà présente dans d’autres terminaux nouvelle génération, comme par exemple Terminology (Enlightenment).

    Maintenant la chose qui m’ennuie un peu c’est que ces nouveaux terminaux délaissent complètement leur coeur de métier, à savoir l’émulation de terminal et surtout l’amélioration de la norme. Dans un terminal moderne j’ai envie d’avoir par exemple un enrichissement plus étoffé des caractères avec au hasard de l’undercurl, du barré, etc. Une gestion de couleur qui ne se limite pas aux 256 couleurs actuelles mais utilisant une véritable notation RGBA. Ce genre de choses. À l’époque d’XTerm on ne s’était pas gêné pour étoffer la norme VT220 d’extensions de ce genre (c’est par exemple le cas de la gestion de la souris, ou des 256 couleurs des terminaux). Aujourd’hui on dirait que nous sommes dans une notion figée du terminal, comme si c’était un musée. Et que par dessus on rajoutait des couches pour rendre le musée attractif et moderne….

  6. Bob

    D’accord avec les posts précédents, c’est lent et la gestion du copier/coller est inexistante (impossible de copier du texte affiché avec la commande cat). De je ne trouve pas que l’utilisation de menus contextuels soit plus rapide que de la vrai complétion sur les commandes. Pour le moment çà ne prend que l’historique de tes commandes précédentes. C’est beau c’est neuf mais encore trop jeune !

Trackbacks / Pings

Laisser un commentaire