Sortie de ValaTerm 0.3

Posté par  . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
18
18
mai
2011
Ligne de commande

J'ai le plaisir de vous annoncer la sortie de ValaTerm, un émulateur de terminal léger écrit en Vala en version 0.3.

Le projet est sous licence GNU GPLv3.

Pourquoi un autre terminal ?

En premier lieu, j'aimerais vous expliquer pourquoi je l'ai écrit :

Il y a encore quelques-mois, j'étais sous GNOME et j'utilisais gnome-terminal. Seulement, par la suite j'ai décidé de me mettre sous Openbox.

J’ai ajouté Openbox sur une Gentoo fraîchement installée, et je fus frappé de voir que les terminaux étaient soit trop complexes, soit pas très bien intégrés à Openbox, soit avec des dépendances interminables.

J'ai donc décidé d'en écrire un moi-même. Pour cela j'utilise le langage Vala, un langage qui compile le code en C, lui-même compilé en langage machine. Ce qui en fait une application rapide et sans dépendances interminables (seulement GTK+, VTE et gettext).

Installation

Si vous êtes sous Arch Linux, c'est très simple, le paquet et présent sur AUR :
```console

yaourt -S valaterm










Pour les autres passez par Git:
```console
$ git clone git://gitorious.org/valaterm/valaterm.git

Note : Le paquet ebuild (pour Gentoo) est disponible sur le dépôt Git, mais n'est pas encore testé…

Pour voir la liste des nouveautés, consulter le changeLog ou/et le fichier NEWS.

Aller plus loin

  • # trop light ?

    Posté par  . Évalué à 2.

    Je viens de le compiler, light rien à redire la dessus.
    Quel est la roadmap ? car light ne veux pas dire sans feature :

    • raccourcis clavier ?
    • tab de term ?
    • division du term (à la terminator)

    ce genre de features me feront l’adopter ;)

    • [^] # Re: trop light ?

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

      • tab de term ?
      • division du term (à la terminator)

      Ça, ce sont des fonctionnalités qui devraient être apportées par le gestionnaire de fenêtres. Personnellement, un émulateur de terminal qui les implémente, je n'installe pas, c'est redondant.

      • [^] # Re: trop light ?

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

        Actuellement, les tabs dans le gestionnaire de fenetre, c'est de la merde en boite, ca te fait lancer une fenêtre par tab pour l'application (voir un instance avec des terminaux genre urxvt).

        Y'a bien KDE qui réfléchie à une protocole pour faire passer les tabs dans la barre de fenêtre mais rien de fait...

        Donc actuellement, bien sur que les tabs doivent être supportées par le terminal.

        • [^] # Re: trop light ?

          Posté par  . Évalué à 4.

          J'imagine que sa remarque valait pour tous les softs. Si Firefox avait été implémenté sur ce principe, ça ferait un peu Nestcape 4. :)

          • [^] # Re: trop light ?

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

            Oui la remarque est valable pour tout les softs, c'est d'ailleurs l'objet de la séparation entre uzbl-browser et uzbl-tabbed.

            Après on peut être en désaccord mais cela reste une opinion qui se tient.

        • [^] # Re: trop light ?

          Posté par  . Évalué à 0.

          Et c’est quoi le problème ? En quoi c’est gênant de lancer une fenêtre par onglet ? En quoi c’est gênant de lancer une instance par fenêtre ? Me dis pas que ça te bouffe de la RAM… Je tourne avec konsole, j’ai tourné avec urxvt il fut un temps et ça ne m’a pas gêné plus que ça, idem pour mon navigateur web, il me semble d’ailleurs qu’il y a des mécanismes et le code d’une application ne se trouve qu’une seule fois en RAM.

          • [^] # Re: trop light ?

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

            Mais bien sur que c'est pour la RAM...

            • Dolphin: 20 Mio
            • Dolphin avec 5 onglets: 20 Mio
            • Dolphin avec 5 fenêtres: 30 Mio

            • [^] # Re: trop light ?

              Posté par  . Évalué à 1.

              Oui, Dolphin débarque comme un cheveu sur la soupe. Tu m’étonnes, tu l’as bien choisi. Effectivement les onglets ne concerne que la vue des dossiers. Pas les panneaux latéraux. Ce qui fait que les onglets n’ont pas la même signification (ceux de Dolphin ne n’intègrent pas les informations contextuelles&co, ils sont limités).

              Je ferai de plus amples tests ce soir pour voir ce qu’il en est des terminaux et du navigateur web, par contre pour Dolphin je n’obtiens pas du tout tes chiffres.

              • [^] # Re: trop light ?

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

                Bon, on va faire simple,

                tu prends ton navigateur web avec 5 onglets:
                Il n'y qu'une barre d'outils qui change d'état en fonction de l'onglet

                tu prend ton navigateur avec 5 fenêtres:
                Il y'a autant de barre d'outils que de fenêtre avec des états différents

                Donc obligatoirement il y'a augmentation de conso mémoire vu que tu dupliques des widgets qui n'ont pas besoin de l'être avec des onglets.

                • [^] # Re: trop light ?

                  Posté par  . Évalué à 3.

                  Bah je sais bien.

                  Alors on va pas faire simple maintenant. Les questions sont :
                  — Est-ce que la barre d’outil te bouffe une place monstre ?
                  — Quelle est la consomation mémoire relativement à la mémoire totale prise par l’application.

                  Je n’avais pas le sentiment que ça prenait tant que ça vu que je tourne avec des onglet géré par le WM depuis un bon bout de temps (minimaliste pourtant!). Mais comme je l’ai dit, je ferai des tests plus poussés pour avoir une petite idée, plutôt que de parler dans le vide ça sera plus constructif. Toutefois, vu les avantages apportés par une gestion unifiée des onglets au niveau du WM je me vois mal m’en passer.

                  • [^] # Re: trop light ?

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

                    Non, mais la barre d'outils c'est un exemple, c'est vrai pour tous les éléments de l'interface qui ne sont pas dans la zone d'onglet.

                    Après, certe c'est pas non plus de la folie mais les onglets dans le WM sont pour l'instant une solution non optimale...

                    • [^] # Re: trop light ?

                      Posté par  . Évalué à 2.

                      Voila. Je donne les chiffres, sauf mention particulière : c’est d’abord une instance lancée, ensuite avec 11 fenêtres, ensuite avec 11 onglets. Attention ! Certains dans la liste varient pas mal.

                      Konsole
                      18 25 27
                      Urxvt
                      6 RES - 4 SHR = 2 par fenêtre
                      Urxvtd+c
                      <1 par fenêtre
                      rekonq
                      97 105 97 (linuxfr +9)
                      dolphin
                      25 27 34
                      firefox(4?)
                      63 98 67 (linuxfr +13)

                      Voilà, la différence entre onglets gérés par l’application et onglets du WM est notable sans être « de la merde en boite », relativement à la consommation à vide des logiciels. Par contre dès qu’on y ajoute les données gérées par une application, zsh qui consomme 1 Mo (RES-SHR) par instance au démarrage, une page web, la différence ne devrait jamais dépasser les 10 % — au pire il y a un choix d’applications à faire (une instance par fenêtre a aussi ses avantages en cas de crash de l’une d’entre elles…).

      • [^] # Re: trop light ?

        Posté par  . Évalué à 5.

        tab de term ?
        division du term (à la terminator)

        Ça, ce sont des fonctionnalités qui devraient être apportées par le gestionnaire de fenêtres. Personnellement, un émulateur de terminal qui les implémente, je n'installe pas, c'est redondant.

        Amusant comme point de vue: si pour des tab tu utilise le gestionnaire de fenêtres, en fait tu utilise plus de ressources qu'avec une application gérant elle-même les tabs, puisque tu dois lancer plusieurs instances complètes de la même application..

        • [^] # Re: trop light ?

          Posté par  . Évalué à 2.

          Ouai c'est le cas des applications pas prévue pour (il y en a pleins les dépôts de distrib'), mais si tu choisi d'utiliser urxvt, tu lance le deamon/serveur, puis que des clients, ça consomme plus ou moins rien.

          Mais pour ceux qui n'aiment pas avoir à lancer deux fois la même appli' comment font ils avec leur shell ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: trop light ?

          Posté par  . Évalué à 5.

          Sauf que dans le cas qui nous intéresse, çàd les terminaux, ceux qui n'utilisent pas de tabs (xterm ou rxvt) sont infiniment plus léger que ceux qui en ont (gnome ou kde), quelque soit le nombre de tabs ou fenêtres ouverts, donc prétendre utiliser ces derniers du fait des tabs, et prétendre utiliser les tabs car c'est plus léger, c'est du flan...

          • [^] # Re: trop light ?

            Posté par  . Évalué à 3.

            Sauf que si gnome-terminal et konsole sont plus lourd, ça m'étonnerait que ça soit dû à leur gestion des onglets mais aux frameworks qu'ils utilisent : ils sont censés s'intégrer dans leurs bureaux respectifs et donc utiliser les bibliothèques déjà en mémoire.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: trop light ?

            Posté par  . Évalué à 2.

            Sauf que dans le cas qui nous intéresse, çàd les terminaux, ceux qui n'utilisent pas de tabs (xterm ou rxvt)

            rxvt a des onglets:

            rxvt -pe tabbed

        • [^] # Re: trop light ?

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

          Certes mais l'argument n'étais peut-être pas en faveur d'une légerté accrue. Pour ma part, je recherche des logiciels qui laissent la gestion des onglets au gestionnaire de fenêtre afin de profiter au maximum de raccourcis clavier unifiés sur mon bureau.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: trop light ?

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

        Alors, est-ce qu'un fenouil, c'est redondant ?

        • [^] # Re: trop light ?

          Posté par  . Évalué à 4.

          C'est-à-dire, je suis pas un pro du combat au fenouil, mais enfin comme ça instinctivement je dirais non.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: trop light ?

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

      Vraiment light, adopté !
      Le fait que ce soit sans tab de term me convient, le gestionnaire de fenêtre sait gérer les multi-fenêtres et au moins on peut utiliser la navigation des fenêtres pour naviguer entre les onglets.

      Les raccourcis nécessaires :
      - CTRL+n pour créer une nouvelle fenêtre
      - CTRL+q pour quitter
      - CTRL+, pour les préférences
      - F1 pour le menu à propos (Peut-être fusionner licence dans un tab de crédit
      - CTRL+SHIFT+l pour vider l'écran
      - CTRL+SHIFT+C : Copier
      - CTRL+SHIFT+V : Coller

      Voir aussi si on peut gérer la transparence du fond pour une meilleur intégration au bureau.

      Bon travail.

      • [^] # Re: trop light ?

        Posté par  . Évalué à -1.

        Je veux bien que ce sois le gestionnaire de fenêtre mais en attendant ce n'est pas géré et je ne veux pas ouvrir ~100 terminal voir plus pour travailler.

      • [^] # Re: trop light ?

        Posté par  . Évalué à 1.

        Pour les raccourcies, je préfère ne pas en mettre pour l'instant pour éviter les interférences avec les applications comme emacs par exemple...

    • [^] # Re: trop light ?

      Posté par  . Évalué à 6.

      Personnellement, après avoir fait un nombre d'essai incalculable pour trouver chaussure à mon pied, je suis tomber sur la solution idéale selon moi : n'importe quel term associé à screen.

      Vous allez dire, encore un qui utilise un outils à l'ergonomie préhistorique, et bien je dis non !

      Mon besoin était simple :
      - scrollbare ou history custom pour pouvoir remonter haut
      - onglets
      - raccourcis claviers simples (marre des tendinites pour trouver l'onglet suivant)

      Jugez vous même (screenrc) :

      termcapinfo xterm|xterms|xs|rxvt ti@:te@ # See history with shift+Pg Up
startup_message off
defscrollback 65535
hardstatus alwayslastline "%{= RW} %-Lw%{= WR}%n+%f %t%{-}%+Lw %=[${USER}@%H] [%d/%m/%y %0c]"

# Bind arrow keys
# to know signals, try cat > /dev/null and press keys
bindkey ^[[D prev       # Ctl-left, prev window
bindkey ^[[C next       # Ctl-right, next window
bindkey ^T screen       # Ctl-t, new window
bindkey ^W kill         # Ctl-w, kill window
bindkey -k k2 title     # F2, rename

      • [^] # Re: trop light ?

        Posté par  . Évalué à 1.

        J'ai couplé l'utilisation screen à un script de gestion de session screen.

        Je suis parti d'un script existant (screenie), ce n'est toujours pas parfait mais si le cœur t'en dit Cc ! :
        https://github.com/talineo/screenie

        Par contre, je ne conseille pas l'utilisation de screen + screenie + urxvtc/d -pe tabbed + dwm, c'est ... trop !
        (j'ai essayé.)

        • [^] # Re: trop light ?

          Posté par  . Évalué à 1.

          Mais c'est complètement bien cet outils que je ne connaissais pas.
          Comme j'ai régulièrement 5 ou 6 sessions screen avec chacun une dizaine de windows, ça permet d'avoir toujours un visuel sur les sessions sans se taper des screen -ls et compagnie.

          Merci !

  • # LXTerminal

    Posté par  . Évalué à 3.

    "Terminal léger", ça me fait tout de suite penser à LXTerminal, celui du projet LXDE, qui est indépendant de l'environnement et qui n'a aussi que peu de dépendances (GTK+ et VTE). Était-il encore trop lourd ?

    • [^] # Re: LXTerminal

      Posté par  . Évalué à 2.

      J'ai pas de quoi le compiler ici, mais y'a des interfaces de config, tout ca...

      Bref, pour la légèreté, je suis pas certain que ca fasse aussi bien que urxvtd + urxvtc...

      • [^] # Re: LXTerminal

        Posté par  . Évalué à 1.

        Effectivement si LXTerminal est encore trop "lourd", je comprends l'écriture d'un émulateur de terminal minimaliste, mais qui s'intégrera tout de même bien avec un environnement GTK+ (ce qui n'est peut-être pas le cas d'urxvt).

    • [^] # Re: LXTerminal

      Posté par  . Évalué à 1.

      J'ai essayé et il bug chez moi...
      Une partie de l'écran noir et quand je le quitte, il reste noir...

    • [^] # Re: LXTerminal

      Posté par  . Évalué à 1.

      Dans le genre termimal léger en GTK, il y a également Sakura

    • [^] # Re: LXTerminal

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

      Et euh, xterm c'est léger et rapide non ? Pourquoi ne pas utiliser xterm ?

  • # Et chez Suckless ?

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

    As tu regardé le terminal de chez Suckless ? Ils ont l'air habitué au code léger. Par contre je ne sais pas si ça te conviens pour l'intégration avec OpenBox.

    http://st.suckless.org/

    • [^] # Re: Et chez Suckless ?

      Posté par  . Évalué à 3.

      Il est bien st.
      Très léger, ne gère rien comme fonctionnalités (pas de tab, pas de tous ces trucs qui peuvent être gérés par le gestionnaire de fenetres et/ou GNUscreen)

      Avec un environnement type wmii, c'est parfait pour ma vieille bécane.

      Mais je vais quand-même essayer valaterm, ça a l'air intéressant.

    • [^] # Re: Et chez Suckless ?

      Posté par  . Évalué à 3.

      En effet c'est léger...
      Faire tenir le tout dans un fichier C de seulement 1929 lignes, je dit chapeaux !

      • [^] # Re: Et chez Suckless ?

        Posté par  . Évalué à 1.

        Merci :)

        Il est très léger et très (trop?) simple dans l'implémentation : il est un peu lent à dessiner (lance alsamixer en plein écran) et pas très configurable (genre les fontes). Ce sont les deux points où mes maigres connaissances de X font défaut et que je vais essayer d'améliorer.

  • # Vala 0.12 required!

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

    Un des requis pour compiler, c'est Vala 0.12, qui est sorti le 3 avril dernier!

    Du coup sur un paquet de distribs faudra compiler Vala avec!

    • [^] # Re: Vala 0.12 required!

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

      Pareil pour libvte (que j'ai du mal à trouver...).

      En fait j'ai abandonné l'idée de compiler ton truc sous Fedora, faut se taper la recompilation de Vala, libvte, qui ne veut pas de ma glib, et je ne sais quoi encore.

      Je suis frustré!

      • [^] # Re: Vala 0.12 required!

        Posté par  . Évalué à 5.

        Pareil... J'ai du recompiler Vala 0.12. Après l'avoir récupéré sur le site officiel, il me dit
        **Error**: You must have valac >= 0.10.0 installed to build vala. ... la bonne blague... et pour compiler la 0.10 il faut la 0.9, c'est ça?

        Finalement en allant récupérer les sources ailleurs ça passe mieux. Ensuite pour VTE, j'ai bien galéré pour trouver les sources... sauf que le svn s'arrête à la version 0.20 et que c'est la 0.26 qui est réclamée!!! Là, j'ai abandonné...

        Pour un truc « sans dépendances interminables », il va falloir repasser...

        C'est dommage, il y a une fonctionnalité que j'aurai voulu vérifier qui n'est malheureusement présent sur aucun terminal : la possibilité d'avoir des lignes plus longues que la largeur de l'écran (le line wrap). Il n'y a que xterm qui fait semblant de s'en sortir en défaussant la fin de la ligne. C'est quand même assez bizarre... alors que c'est une fonctionnalité de base (tous les éditeurs de texte l'ont par exemple), elle est ignorée dans les terminaux face à d'autres fonctionnalités bidons (AMHA) comme la transparence ou les tabs.

        • [^] # Re: Vala 0.12 required!

          Posté par  . Évalué à 2.

          Pour vte il faut que je change ça.
          J'ai mis en minimum la 0.26 mais je pense que elle se compile parfaitement avec des versions inférieur.
          C'est parce-que j'avais sous la main que la version 0.26. C'est une erreur de ma part.
          Il faudrait que je sache jusqu’à quelle version il supporte.

          Pour modifier la version minimum requis, il faut modifier le fichier wscript à la racine du projet et modifier la partie associé à vte.
          Ensuite recompiler avec la commande:

          $ ./waf configure build

          Si quelqu’un arrive à la compiler avec une version de vte inférieur à 0.26 (je suppose que ça devrait marcher), qu'il me le dise, ça m'aiderais grandement !

        • [^] # Re: Vala 0.12 required!

          Posté par  . Évalué à 1.

          Ah oui, j’oubliai. Pour vte il faut cherche "gnome vte".
          Du coup on tombe sur la page suivante: http://developer.gnome.org/vte/
          Et là on a toutes les versions qu'on veut...

          • [^] # Re: Vala 0.12 required!

            Posté par  . Évalué à 2.

            J'ai tenté avec vte 0.16 sans succès, et pour les version plus récentes c'est ma glibc qui est trop vieille. Enfin merci quand même pour le lien.

            • [^] # Re: Vala 0.12 required!

              Posté par  . Évalué à 1.

              Tu as tenté de compiler ValaTerm avec VTE 0.16 ?
              Si oui:
              Es ce que tu pourrais mettre l'erreur de compilation, s'il te plaît.

              • [^] # Re: Vala 0.12 required!

                Posté par  . Évalué à 3.

                Ça a quand même l'air mal barré...

                [18/18] cprogram: build/src/about.c.1.o build/src/colors.c.1.o build/src/config-file.c.1.o build/src/configurations-window.c.1.o build/src/context-menu.c.1.o build/src/default-dialog.c.1.o build/src/image-menu-item.c.1.o build/src/main.c.1.o build/src/main-window.c.1.o build/src/menu-bar.c.1.o build/src/menu-item.c.1.o build/src/parameter-box.c.1.o build/src/pictures.c.1.o build/src/settings.c.1.o build/src/terminal.c.1.o -> build/valaterm
                src/image-menu-item.c.1.o: In function 'image_menu_item_construct':
                image-menu-item.c:(.text+0xd6): undefined reference to 'gtk_menu_item_set_label'
                image-menu-item.c:(.text+0xe6): undefined reference to 'gtk_image_menu_item_set_use_stock'
                image-menu-item.c:(.text+0xf6): undefined reference to 'gtk_menu_item_set_label'
                src/main.c.1.o: In function 'main':
                main.c:(.text+0x96): undefined reference to 'g_thread_init'
                src/menu-item.c.1.o: In function 'menu_item_construct':
                menu-item.c:(.text+0xd2): undefined reference to 'gtk_menu_item_set_label'
                src/terminal.c.1.o: In function 'terminal_has_foreground_process':
                terminal.c:(.text+0x242): undefined reference to 'vte_terminal_get_pty'

                • [^] # Re: Vala 0.12 required!

                  Posté par  . Évalué à 1.

                  En fait c'est GLib, GTK+ et VTE qui sont trop anciens...
                  Par contre ça m'étonne qu'il est bien voulu compiler et qu'il ne veuille pas linker...
                  Ça veux dire que tes headers se sont pas à la même version que tes bibliothèques dynamique (.so).

                • [^] # Re: Vala 0.12 required!

                  Posté par  . Évalué à 1.

                  Au fait, merci, ça m'a bien aidé pour avoir une idée précise des versions minimale des libs.
                  Il me manque juste celle de glib.
                  Quel est ta version de glib ?

                  • [^] # Re: Vala 0.12 required!

                    Posté par  . Évalué à 3.

                    Long week end.... retour difficile. Avec vte-0.20.5:
                    Requested 'glib-2.0 > 2.18.0' but version of GLib is 2.16.6

                    • [^] # Re: Vala 0.12 required!

                      Posté par  . Évalué à 1.

                      Merci, grâce à toi je me suis replongé dans la doc de la glib et j'ai trouvé cette note tout en bas:

                      To use g_thread_init() in your program, you have to link with the libraries that the command pkg-config --libs gthread-2.0 outputs. This is not the case for all the other thread related functions of GLib. Those can be used without having to link with the thread libraries.

                      Donc c'est normalement résolu...
                      Note: J'ai mis la version minimal de glib à 2.6.

    • [^] # Re: Vala 0.12 required!

      Posté par  . Évalué à 7.

      Certains programmes écrit en Vala fournissent le code C généré dans les tarballs.

      Avec Git on peut imaginer que la branche master ne contient pas le C (pour ne pas alourdir les diffs des commits), et qu'il y ait une branche releases avec le code C généré. Les tarballs seraient basés sur des commits de la branche releases.

      Bref, ce n'est pas très compliqué à faire, et ça permet une plus grande facilité d'installation.

    • [^] # Re: Vala 0.12 required!

      Posté par  . Évalué à 1.

      Si ça intéresse quelqu'un, la version minimale requise de Vala pour compiler est maintenant la 0.10.
      Je vient le mettre ce matin dans le dépôt et testé avec valac 0.10.0.

  • # et xterm?

    Posté par  . Évalué à 8.

    xterm était trop lourd?
    Nan parce que perso si je veux un terminal 'léger' j'utilise xterm. Sinon c'est konsole la possibilité de préciser les caractères de césure lors d'un double clique est tout simplement indispensable.

    Je ne parlerai pas des onglets qui sont aussi super pratique (et qui me fait utiliser konsole); oui avec screen on peut se dépatouiller ce qui les rends moins indispensable mais néanmoins pratique.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: et xterm?

      Posté par  . Évalué à 1.

      oui, le fait de pouvoir indiquer quels caractères feront partie de la selection lors d'un double-clic, c'est indispensable.

      J'en profite: quelqu'un sait comment le faire avec un xterm ? Dans mon souvenir, c'est en modifiant un fichier tcap, mais j'avais abandonné devant la complexité. Si quelqu'un connait un bon lien la dessus, je suis preneur!

      Et sinon, pour ceux qui veulent ouvrir des onglets dans un xterm, je ne peux que recommander d'utiliser screen:
      http://www.gnu.org/software/screen/
      pour voir à quoi ca ressemble:
      http://forum.ubuntu-fr.org/viewtopic.php?id=390985

      • [^] # Re: et xterm?

        Posté par  . Évalué à 6.

        je ne peux que recommander d'utiliser screen:

        Et moi je ne peux que recommander de le remplacer par tmux http://tmux.sourceforge.net/

        Étienne

        • [^] # Re: et xterm?

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

          Sans argument ca donne pas trop envie...

          • [^] # Re: et xterm?

            Posté par  . Évalué à 8.

            • Rien que le split horizontal ET vertical suffit à passer à tmux (cf http://tmux.sourceforge.net/tmux5.png)
            • avec sont model client/serveur, tmux permet par exemple de faire passer des fenêtre d'une session tmux à une autre
            • toutes les commandes tmux peuvent être lancée par le shell, les key-bindings appellent ces même commandes
            • à titre personnel, je trouve la manipulation de tmux plus aisée que screen
            • je trouve également la configuration plus claire

            Étienne

            • [^] # Re: et xterm?

              Posté par  . Évalué à 6.

              Screen est sous GPL, tmux sous BSD.
              Sinon, la config est largement plus claire imho, surtout pour les status bar...

              Dans mon vieux .screenrc j'ai :

              caption always "%{=b k}[%{=b W} %0c %{=b k}] %{= G}%?%-Lw%?%{=b R}%n%f %t%{=b R}%{= G}%?%+Lw%?"

              Clair non ?

              Dans mon .tmux.conf, c'est plus long, mais plus clair. Et plus facile à modifier.

              set -g display-time 2000
              set -g status-fg white
              set -g status-bg default
              set -g status-attr default
              set-window-option -g window-status-fg cyan
              set-window-option -g window-status-bg default
              set-window-option -g window-status-attr dim
              set-window-option -g window-status-current-fg white
              set-window-option -g window-status-current-bg default
              set-window-option -g window-status-current-attr bright
              set -g message-fg white
              set -g message-bg black
              set -g message-attr bright
              set -g status-justify centre
              set -g status-right ""
              set -g status-left ""
              set -g status-left "[#[fg=green] rei #[default]]"
              set -g status-right "[ #[fg=cyan,bright]%a %Y-%m-%d %H:%M #[default]]"
              set -g status-right-length 50

            • [^] # Re: et xterm?

              Posté par  . Évalué à 6.

              Je rajouterais:
              - plus simple à scripter (du à la config plus claire).
              - gestionnaire de buffers pour le copier/coller.
              - raccourcis claviers soit à la emacs soit à la vim (très efficace dans mode copie pour rechercher une chaîne de caractères particulière dans la sortie de la commande précédente par exemple).
              - possibilité de changer de sessions sans devoir d'abord détacher celle où l'on se trouve. (s)
              - développement actif contrairement à screen il me semble.
              - c'est le logiciel qui à accepté mon tout premier patch (comment ça c'est pas un argument valable ? :p)

              • [^] # Re: et xterm?

                Posté par  . Évalué à 1.

                Markdown m'a bouffer mes balises :
                Je refais:
                - possibilité de changer de sessions sans devoir d'abord détacher celle où l'on se trouve. (<C-b>s)

      • [^] # Re: et xterm?

        Posté par  . Évalué à 5.

        en fait je viens de retomber sur le site que explique comment faire
        ici :
        http://www.jaymzworld.com/wiki/XTerm_double-click_word_selection

        une ligne du genre
        XTerm*charClass: 39-48:61:64:91:93
        devrait répondre à la majorité des cas; mais bon pour modifier la ligne faut se baser sur une tables; alors certes d'un coté c'est plus puissant; d'un autre à configurer sans utilitaire c'est galère.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: et xterm?

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

        Byobu a été développé par Canonical pour être une surcouche de Screen plus facile à manipuler. Cet outil a été présenté aux JM2L, la vidéo est disponible sur TuxFamily.

        Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: et xterm?

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

      xterm n'est pas si léger que cela :
      Benchmark de terminaux

      À noter qu'en terme de consommation de RAM, rien ne vaut urxvtd+urxvtd.

      • [^] # Re: et xterm?

        Posté par  . Évalué à 3.

        heu...
        Tu as vu le benchmark utilisé? affichage d'une RFC faisant un paquet de ligne pour chronomètre le temps d'affichage... Mise à part pour faire des défilement à la matrix, je ne vois pas trop l'intérêt, et les terminaux tenant le haut du pavé utilisent un rafraichissement incomplet (ie n'affichent pas tout le contenu de la RFC).
        Ce qui est pertinent dans la performance des terminaux c'est (de mon point de vue)
        - la consommation mémoire.
        - la vitesse de lancement.
        - et dans le cas présent les dépendances.
        rxvt et xterm répondent amplement à ces besoins, il fut un temps où j'utilisai aterm qui me semblait aussi correct; par contre la konsole ne se lance pas instantanément (j'en sais rien pour le gnome-terminal)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: et xterm?

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

          Ok après un rapide bench, la consommation en RAM de xterm a effectivement chuté. Cela dit, il y a une dizaine d'année, ce porc me bouffait 15 copieux Mo de RAM par instance.

          J'en retiens simplement qu'il n'y a aucune bonne raison d'utiliser xterm. Je ne l'utilise que lorsque je n'ai rien d'autre.

          Après je fais pas de prosélytisme pour un quelconque terminal, c'est un appeau à troll. Mais xterm se fait bouffer par la concurrence, à tous les points de vue.

          • [^] # Re: et xterm?

            Posté par  . Évalué à 2.

            La disponibilité sur a peu près tout ?
            maintenant, faut bien avouer que chez moi j'ai un alias xterm=rxvt...

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: et xterm?

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

        Normal, xterm il intègre un émulateur Tektronic remarquablement inutile.

      • [^] # Re: et xterm?

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

        un benchmark qui fait apparaitre gnome-terminal premier en terme de legereté c'est forcement une grosse pantalonade.

    • [^] # Re: et xterm?

      Posté par  . Évalué à 1.

      Pour xterm, je répondrais la même chose qu'ici

  • # Gnome-terminal

    Posté par  (Mastodon) . Évalué à 3.

    Je ne comprends pas pourquoi passer sous Openbox implique de laisser tomber gnome-terminal s'il te convenait... Trop lourd ? Tu veux ne pas avoir à installer Gnome ?

    • [^] # Re: Gnome-terminal

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

      Surtout que gnome-terminal ne dépend que de:
      -gconf
      -vte3
      -gsettings-desktop-schemas
      -libsm

      C'est pas trop violent pour quelqu'un qui utilise des applications GTK+

      • [^] # Re: Gnome-terminal

        Posté par  . Évalué à 1.

        T'oublie gnome-desktop et j'en passe.

        • [^] # Re: Gnome-terminal

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

          ~$ aptitude show gnome-terminal
Package: gnome-terminal
State: installed
Automatically installed: no
Version: 2.30.2-0ubuntu1
Priority: optional
Section: gnome
Maintainer: Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>
Uncompressed Size: 430k
Depends: libatk1.0-0 (>= 1.29.3), libc6 (>= 2.4), libdbus-glib-1-2 (>= 0.78), libgconf2-4 (>= 2.27.0), libglib2.0-0 (>=
                 2.23.5), libgtk2.0-0 (>= 2.18.0), libice6 (>= 1:1.0.0), liblaunchpad-integration1 (>= 0.1.17), libpango1.0-0 (>=
                 1.14.0), libsm6, libvte9 (>= 1:0.22.0), libx11-6 (>= 0), gnome-terminal-data (>= 2.30), gnome-terminal-data (< 2.31)
Recommends: yelp, gvfs
Replaces: gnome-terminal-data (< 2.28.1-1ubuntu1)
Provides: x-terminal-emulator
Description: The GNOME terminal emulator application [...]

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

          • [^] # Re: Gnome-terminal

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

            Et pour la version 3 donc:

            $ pacman -Si gnome-terminal
Dépôt                 : extra
Nom                   : gnome-terminal
Version               : 3.0.1-2
URL                   : http://www.gnome.org
Licences              : GPL
Groupes               : gnome
Fournit               : --
Dépend de             : gconf  vte3  gsettings-desktop-schemas  libsm
Dépendances opt.      : --
Est en conflit avec   : --
Remplace              : --
A télécharger         : 1208,29 K
Taille (installé)     : 8512,00 K
Paqueteur             : Ionut Biru <ibiru@archlinux.org>
Architecture          : x86_64
Compilé le            : sam. 30 avril 2011 17:29:05 CEST
somme MD5             : 5a643c0ec72406cf10f75aef49c8185d
Description           : The GNOME Terminal Emulator

            Donc non je n'oublie rien.

            • [^] # Re: Gnome-terminal

              Posté par  . Évalué à 1.

              Oui enfin tu triches là. Il faut prendre en compte les dépendances récursives. Depuis une arch de base on se retrouve avec avahi, gdk, libcups, dbus, polkit,…

  • # Et urxvt ? Recodons la roue joyeusement !

    Posté par  . Évalué à 4.

    On ne peut pas dire que urxvt aie un nombre de dépedances abominables…
    En plus il est rapide, léger scriptable en perl, et surtout il a une architecture client serveur.
    (quoique le mode daemon aie aussi des inconvénients, quand le daemon crash tout crash)
    Sans compter qu'il est configuré dans les ressources X, donc centraliser c'est plus clean je trouve.

    Et sinon j'ai un peut du mal à saisir le concpet d'intégration avec un gestionnaire de fenêtre… Toute appli utilisant les APIs X11 est intégrée à Openbox non ? m'enfin…

  • # et vala-terminal ?

    Posté par  . Évalué à 3.

    Et par rapport a vala-terminal ?
    Qui est aussi, comme son nom l'indique, un terminal écris en vala.

  • # Compiler du vala en c ?

    Posté par  . Évalué à -3.

    Juste pour info, on ne /compile/ pas d'un langage (par ex. vala) vers du C. Éventuellement on le /traduit/...

    D'ailleurs, d'après le site officiel :
    "valac, the Vala compiler, is a self-hosting compiler that /translates/ Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code."

    • [^] # Re: Compiler du vala en c ?

      Posté par  . Évalué à 1.

      Désolé si j'en ai choqué certains.
      Je sais tout ça, sauf que par habitude de langage j'utilise le verbe compiler...

      • [^] # Re: Compiler du vala en c ?

        Posté par  . Évalué à 2.

        Non non, c'est pas un abus de langage que de parler de compilateur dans ce cas la. C'est juste sa définition de compilateur est trop restrictive.

    • [^] # Re: Compiler du vala en c ?

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

      Ah bon ?...

      Mais alors, quand on passe du C en assembleur, on /traduit/ aussi ?

      https://secure.wikimedia.org/wikipedia/fr/wiki/Compiler

      • [^] # Re: Compiler du vala en c ?

        Posté par  . Évalué à 1.

        En effet, mais on fait très peut le lien entre le C et l'assembleur. On fait plutôt le lien entre le C et le code machine.

    • [^] # Re: Compiler du vala en c ?

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

      L'argument sémantique me semble un tantinet raté. Rappelons que le terme de compilation viens de l'époque des cartes à trou. Il fallait alors sélectionner certaines cartes et les mettre dans le bonne ordre. Cela formait une «compilation» de cartes --- comme pour vos CD. Point de référence ici à l'assembleur où à un langage en particulier. Il me semble donc assez à propos de parler de compilation lorsqu'on transcrit du Vala en C. C'est en tout cas valable du point de vue étymologique.

    • [^] # Re: Compiler du vala en c ?

      Posté par  . Évalué à 4.

      Heu non pas du tout, retourne voir la définition de compilateur. Tout les compilateur font de la traduction d'un langage vers un autre. Dans ta définition tu supposes que le langage cible est du langage machine, mais ça reste un langage. Le niveau d'abstraction du langage cible n'a rien a voir dans la notion de compilateur.

      D'ailleurs dans mes cours de compilation (et probablement dans beaucoup d'autres), Pour illustrer les concepts généraux (analyse syntaxiques, transformation d'arbres, génération de code, ...) on prenait comme exemple un compilateur vers le C, pour éviter la partie pénible de génération d'assembleur, linker, etc...

      Compilateur

      • [^] # Re: Compiler du vala en c ?

        Posté par  . Évalué à 1.

        Je crois que j'ai voulu répondre un peut trop vite à l’affirmation.

      • [^] # Re: Compiler du vala en c ?

        Posté par  (Mastodon) . Évalué à 2.

        Le niveau d'abstraction du langage cible n'a rien a voir dans la notion de compilateur.

        /me repasse en mode dino ...

        Pour avoir une bonne idée de l'immensité abyssale de l'abstraction que peut atteindre un langage cible, il y a un bon truc à essayer : prendre un programme un peu tordu en fortran77, le passer à travers f2c, et regarder le code C généré ;)

    • [^] # Re: Compiler du vala en c ?

      Posté par  (Mastodon) . Évalué à 3.

      En général on parle de compilateur en opposition à un interpréteur: l'interpréteur traduit au fur et à mesure et ne conserve pas la traduction, le compilateur traduit une bonne fois pour toutes. Par contre, tout ça est indépendant du langage de destination.

  • # Et un terminal

    Posté par  . Évalué à 10.

    En Node.js/WebKit?
    Titre de l'image

    http://acko.net/blog/on-termkit

    /O\

    Depending on the time of day, the French go either way.

  • # Envoi des saisies à n onglets d'un coup ?

    Posté par  . Évalué à 1.

    Une fonctionnalité de Konsole que je peine à retrouver sur des émulateurs de terminaux plus légers est le fait d'envoyer tout ce qui est tapé au clavier à n onglets d'un coup. Quand on travaille sur un groupe d'équipements identiques, c'est extrêmement pratique. Il n'y a guère que dans mrxvt que j'ai retrouvé quelque chose d'approchant. Hélas mrxvt n'est pas "Unicode aware". Son cousin urxvt l'est mais ne gère pas la fonctionnalité recherchée.

    De même, la fonctionnalité consistant à pouvoir adapter chaque onglet à un encodage des caractères particulier (UTF8 pour l'un, ISO8859-15 pour l'autre, par exemple) fait cruellement défaut dans le lot des "petits légers".

    ...mais je ne les ai sans doute pas tous testés. Qui aura la perle rare ? :)

    • [^] # Re: Envoi des saisies à n onglets d'un coup ?

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

      Pour cela j'utilise Terminator, qui permet de diffuser la frappe à des groupes (j'envoie à lui, lui, lui, mais pas lui, maintenant j'envoie à tous…).

      Mais je ne sais pas si c'est considéré comme un émulateur de terminal « léger ».
      De plus, si tu utilisais Konsole, je suppose que la librairie gtk est redondante avec celle de tes autres applis !

      Certains diront, avec raison, qu'il réinvente aussi le gestionnaire de fenêtre :
      Non seulement il fait des onglets mais il réimplémente le pavage…

      …mais malgré tout ces défauts, ça marche.

      ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

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