Journal Tiling interne ou externe, telle est la question

Posté par (page perso) . Licence CC by-sa
Tags :
18
5
nov.
2012

Pour changer un peu des journaux / dépêches de veilles, j'aimerais vous mettre à contribution pour résoudre un problème que j'ai.
Évidemment, il s'agit d'un problème extrêmement capital, si ce n'est absolument critique !

Dernièrement, je me suis mis à i3wm. Pour ceux qui ne connaissent pas, il s'agit d'un gestionnaire de fenêtre pavant (_tiling_ quoi). C'est la première fois que j'en utilisais un et je dois dire que je suis plus qu'agréablement surpris :

  • très très léger
  • facile à configurer
  • création des bureaux virtuels à la volée
  • simple à prendre en main, pour découper et utiliser l'espace.
  • presque joli (en fait tellement minimaliste que ça passe bien, j'ai juste une barre noire avec mes différents noms de bureaux, un conky minimaliste (le statut de mpd, vaguement ram et cpu et date/heure) et la zone de notification (qui ne contient, au plus, qu'un xchat mais ça ne sert à rien en fait).

Pour le moment, j'utilise en général 6 à 8 bureaux, dont un certain nombre avec des terminaux, de 6 à beaucoup (rarement en dessous car j'utilise les terminaux pour la musique (client mpd), git, ssh, vagrant, volume, etc.).

Jusque là tout allait plutôt bien (cool non ?) et je recommande à tout le monde de tester réellement un bureau du genre, c'est vraiment agréable.

Par contre, je viens de découvrir (enfin je connaissais déjà, mais jamais vraiment utilisé) tmux. Et là, ça en devient nikel pour gérer mes terminaux :

  • plusieurs "onglets", finalement c'est comme si javais des sous-bureaux virtuels pour mes terminaux
  • possibilité de découpage horizontal/vertical
  • facile à mettre en oeuvre et plutôt simple à utiliser

Mais j'ai un problème (ah enfin, ça commençait à devenir long) : je me mets donc à utiliser un gestionnaire de fenêtre pavant tout ça pour lancer un terminal en plein écran qui lance un tmux dans lequel je gère mes terminaux sur le même principe…
J'arrive donc à avoir un gestionnaire pavant dans un gestionnaire pavant…

Et je trouve ça franchement dommage.
J'en viens donc à me demander si ça serait pas plus intéressant d'avoir un gestionnaire de fenêtre normal (pratique pour certains logiciels), avec tout de même un certain nombre de bureaux, et sur au moins l'un deux un tmux en plein écran qui gère mes terminaux.

Et voici donc le moment où vous pouvez m'aider : comment gérez vous ce type de situation ?

  • À l'ancienne, des terminaux indépendants.
  • les tty y'a que ça de vrai
  • tiling + tmux
  • desktop "classique" + tmux
  • autre solution
  • 42

Merci à tous, pour vos idées, suggestions, avis, toucekvousvoudrez !

  • # dwm + dmenu + screen

    Posté par (page perso) . Évalué à  2 .

    • dwm livré tel que Debian Stable le fournit (sans recompilation du fichier .h de config)
    • dmenu pour lancer les applications
    • GNU screen pour les terminaux
    • [^] # Re: dwm + dmenu + screen

      Posté par (page perso) . Évalué à  3 .

      oué mais là ça ne résout pas vraiment le problème

      • dwm ? qu'aurait-il de mieux que mon i3 ? (sachant que de toute façon je n'ai pas de debian stable, pas fou ;) )
      • dmenu : je l'ai déjà
      • screen : ok, on remplace tmux par screen, mais ça me change quoi ?
      • [^] # Re: dwm + dmenu + screen

        Posté par (page perso) . Évalué à  3 .

        dwm par rapport à i3: je ne connais pas i3 ;-).

        screen: l'intérêt que je vois, c'est que tu n'as pas cette histoire de "tiling interne".
        Personnellement, j'ouvre via dmenu un nouveau terminal chaque fois que j'ai besoin d'une nouvelle "vue", terminal dans lequel screen est lui aussi chargé. Je choisis ensuite la "vue" (le tty) que screen doit afficher.
        L'intérêt pour moi est le fait de ne rien perdre si par malheur X crashait. Autre avantage, je peux me connecter à distance et via "screen -rx" récupérer les tty dans lequel je bossais.
        Du coup, je n'utilise que le tiling de dwm, et un seul screen avec une vue par fenêtre.

        • [^] # Re: dwm + dmenu + screen

          Posté par . Évalué à  3 .

          screen: l'intérêt que je vois, c'est que tu n'as pas cette histoire de "tiling interne"

          Biensûr que tu as du "tiling" sous GNU/screen, horizontal, vertical, extensible etc.

      • [^] # Re: dwm + dmenu + screen

        Posté par . Évalué à  3 .

        dwm ? qu'aurait-il de mieux que mon i3 ? (sachant que de toute façon je n'ai pas de debian stable, pas fou ;) )

        dwm est minimaliste et se configure via ses sources. C'est la principal différence. Il n'a pas sa propre barre dynamique, il faut utiliser xmobar ou dzen pour en avoir une.

        screen : ok, on remplace tmux par screen, mais ça me change quoi ?

        screen c'est GNU et tmux c'est BSD. tmux est plus récent et apporte quelques trucs en plus.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Cahier des charges incomplet

    Posté par (page perso) . Évalué à  2 .

    En fait, je comprend pas très bien ton cahier des charges.
    En effet, de ce que j'ai compris de ton journal, tmux fait complètement double emploi avec ton gestionnaire de fenêtre quand à l'aspect tiling.
    La seule différence que j'ai retenu est la fonctionnalité d'onglet et la "facilité" d'utilisation.
    Pourrais tu énoncer plus clairement ce qu'il manque a i3wm pour te passer de tmux ?

    Sinon, je ne sais pas si ça peut combler tes besoins, mais je me met actuellement à utiliser awesome progressivement et je dois avouer que ce gestionnaire de fenêtre me plait de plus en plus.

    Dans ces points forts, je citerai:
    - minimaliste, rapide et fortement tweakable en LUA.
    - fonctionnement mixte floating/tiling (paramètrable par bureau virtuel)
    - plusieurs modes de tiling: l'organisation des différentes fenêtres obéit à un "schéma", encore une fois défini pour chaque bureau virtuel. Ainsi, tu peux choisir d'avoir en permanence un terminal occupant la moitié gauche (ou haute, ou droite) de l'écran, etc… Une fois le mode adequat choisi, les nouvelles fenêtres se placent automatiquement en fonction de celui-ci.

    Désolé si j'ai compris de travers, lundi, toussa …

    • [^] # Re: Cahier des charges incomplet

      Posté par (page perso) . Évalué à  2 .

      En effet, de ce que j'ai compris de ton journal, tmux fait complètement double emploi avec ton gestionnaire de fenêtre quand à l'aspect tiling.

      Exactement

      Pourrais tu énoncer plus clairement ce qu'il manque a i3wm pour te passer de tmux ?

      Ha mais c'est le contraire, je me pose la question de virer i3 car tmux rempli la part de tiling dont je me sert pour les terminaux. Et un gestionnaire non pavant pourrait suffire pour mes autres programmes (en gros deux navigateurs, un éditeur de texte en plein écran et un thunderbird - sauf si je trouve le courage de le remplacer par un mutt)

      • [^] # Re: Cahier des charges incomplet

        Posté par . Évalué à  3 .

        sauf si je trouve le courage de le remplacer par un mutt
        http://stevelosh.com/blog/2012/10/the-homely-mutt/
        Note, je ne recommande pas de passer a mutt, même si je me questionne vaguement en ce moment a ce sujet.

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

        • [^] # Re: Cahier des charges incomplet

          Posté par (page perso) . Évalué à  1 .

          Merci pour le lien, je l'avais zapé celui-là.

          En fait c'est surtout que j'apprécie assez peu thunderbird (je le trouve peu pratique, pas super lisible, pas génial quoi).

          Je n'ai par contre jamais essayé mutt, mais j'ai fait un peu de gnus. D'ailleurs ça pourrait aussi être une solution.

          Mon passage sous i3 m'a redonné plutôt le goût pour des logiciels plus simples et plus léger (ok, emacs…) et finalement mutt me semble relativement intéressant. Surtout si je le couple avec un tmux et emacs daemon (pour vim j'ai commencé à le tester mais j'ai encore trop de mal)

          Je cherche donc à avoir quelque chose de plutôt léger, simple, assez peu intrusif, mais qui fait juste son job.

          Bon ok, d'ailleurs pour mon problème, je pourrais aussi simplement remplacer tmux et autres par emacs… :)

          • [^] # Re: Cahier des charges incomplet

            Posté par . Évalué à  2 .

            Merci pour le lien, je l'avais zapé celui-là.
            C’est parce que tu ne fais pas de python :)

            En fait c'est surtout que j'apprécie assez peu thunderbird (je le trouve peu pratique, pas super lisible, pas génial quoi).
            J’suis dans ma phase trimestrielle de Mon client mail me les broutes faisons le tour de ce qui existe, et présentement je suis sous Thunderbird (Earlybird pour être plus précise) et je ferais les mêmes critiques, sans parler du manque d’intégration avec mon système, ce qui contrairement a ce que le mozilien de service prétendait, est important.

            Je n'ai par contre jamais essayé mutt
            Mutt est pas mal, ce n’est pas la poudre verte que certains en font, mais ça s’en rapproche quand même un peu…
            mais j'ai fait un peu de gnus.
            Well… nobody's perfect!
            For your RSS needs, have you considered http://newsbeuter.org/ ?

            Bon ok, d'ailleurs pour mon problème, je pourrais aussi simplement remplacer tmux et autres par emacs… :)
            http://nooooooooooooooo.com :)

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

            • [^] # Re: Cahier des charges incomplet

              Posté par (page perso) . Évalué à  2 .

              Merci pour le lien, je l'avais zapé celui-là.

              C’est parce que tu ne fais pas de python :)

              Non, mais je connais son blog pour mercurial

              Mutt est pas mal, ce n’est pas la poudre verte que certains en font

              Je pense bien, mais en fait je trouve thunderbird pas assez ergonomique et agréable. Et en fait il n'y a pas 36 clients mails sous linux finalement…
              Et comme je suis actuellement dans ma phase i3/tmux/jefaisauclavier je me suis dit que ça pouvais être intéressant…

              mais j'ai fait un peu de gnus.

              Well… nobody's perfect!

              Mais heu !
              D'ailleurs je me pose la question de le réutiliser, surtout que j'ai toujours un emacs --daemon qui traine, et que mon $EDITOR est un emacsclient

              For your RSS needs, have you considered http://newsbeuter.org/ ?

              Ha non, jamais pensé. Mais là par contre ça me tente moins pour la simple et bonne raison que j'ai un tt-rss sur un serveur perso et que je l'utilise donc n'importe où. A la rigueur si j'avais un client en console pour lui… ;)

      • [^] # Re: Cahier des charges incomplet

        Posté par . Évalué à  2 . Dernière modification : le 07/11/12 à 09:32

        Ha mais c'est le contraire, je me pose la question de virer i3 car tmux rempli la part de tiling dont je me sert pour les terminaux. Et un gestionnaire non pavant pourrait suffire pour mes autres programmes (en gros deux navigateurs, un éditeur de texte en plein écran et un thunderbird - sauf si je trouve le courage de le remplacer par un mutt)

        Personnellement, j’aime bien avoir un gestionnaire pavant pour mes autres applications aussi. Un usage typique c’est la doc dans firefox dans la colonne de gauche et un terminal de l’autre, avec possibilité assez simple d’en mettre un seul des deux en plein écran.

        Du coup c’est wmii et pas de tmux, un tty = un xterm.

        Pour les RSS dont tu parles plus bas, j’ai un petit programme qui me les envoie directement dans une boîte Maildir (et dans le dossier qui va bien), et je les lis avec mon client mail (claws-mail).

      • [^] # Re: Cahier des charges incomplet

        Posté par . Évalué à  1 .

        Si il fait double emploi pour le tiling, à quoi sert-il donc?

        Pour le mode onglet? i3 l'a aussi. Il peut même faire un mode "onglets verticaux" (dont je me sert pas, soit dit en passant) et avec l'imbrication de conteneurs et le choix du modèle de chaque, tu peux très bien avec un conteneur père "onglet", des conteneurs fils verticaux/horizontaux, dont des conteneurs petit-fils sont aussi en mode onglet.

        Oui, je sais, c'est le bordel, et je n'ai pas encore appris à tout bien manipuler avec i3 (il doit me manquer un truc, mais quoi… P'tet une commande que je n'utilise pas genre sélection du conteneur parent/fils?)

        Pour le non pavant, tu peux aussi passer i3 en non pavant: $mod+SPACE fait le travail chez moi (avec $mod==WIN). Naturellement, tu peux aussi imposer le non pavant par défaut sur un espace de travail entier, histoire de pas se prendre la tête.

        Pour l'utilisation de i3, j'ai en général un peu moins de workspace que toi, (quoique ça dépende de la machine, si je suis en réseau ou pas et de l'endroit ou je suis…) mais j'utilise surtout :

        • ncmpcpp (qui ne s'actualise d'ailleurs pas toujours très bien), sachant que j'ai aussi collé un mode pour piloter mpd via mpc…
        • 2-3 consoles de dev
        • 1-2 consoles de config de mon système (j'aime customiser vite et tapper le "su" à chaque fois n'est pas patrick)
        • xosview (que je dois déplacer à la main, je sais pas pourquoi… pénible d'ailleurs)
        • un IDE
        • wesnoth
        • uzbl / opera (selon l'usage)

        Ca doit me faire genre entre 3 et 5 workspaces…

        Accessoirement, j'ai encore quelques tracas avec le TWM, peut-être que quelqu'un saura les résoudre?

        Déjà, personne ici ne trouve que dmenu, par défaut, c'est ridicule?
        Je m'explique avant qu'on m'accuse de troller: je lui reproche 2 choses (qui ne sont pas son problème, en fait, il fait juste son taf, mais je trouve que ça ne suffit pas) :

        1. il affiche par défaut TOUTES les appli dans PATH. Hors, seules les applications X ont un intérêt dans le cas du lanceur pour TWM. Limite, il faudrait juste lister les applis ayant un *.desktop (fichiers qui sont listés dans /usr/share/desktop ce me semble) sauf que bien sûr, on ne peut les lancer. Peut-être qu'il faudrait créer un dossier contenant des liens symboliques vers les applis du PATH, mais il faudrait pouvoir le mettre à jour automatiquement à chaque install de soft (ça dois être possible mais je sais pas comment faire avec dpkg, quelqu'un à une idée?)
        2. il ne supporte pas les arguments de commande. Ce serait un véritable pied de pouvoir lancer, par exemple (qui est fort pourri dans ce cas-ci, et peut-être même invalide, mais c'est l'esprit l'important) "wesnoth --nosound" en tappant "w --n". Une sorte de bash avec auto-complétion, mais juste avec les programmes cochons en somme (cf 1)

        Je trouve aussi que vim fait trop de trucs, de façon trop compliquée. S'il pouvait laisser la gestion de fenêtre au WM, supporter un véritable copier/coller, et si je pouvais trouver comment changer les raccourcis clavier de déplacement pour qu'ils soient les mêmes que ceux de i3 que je trouve plus logiques (jklm au lieu de hjkl, ça évite de bouger un doigt pour rien) je crois que je serai presque comblé (je trouverais bien un truc pour râler après tout).

        Note: pour les amoureux des fonds d'écran, on peut même utiliser xplanet ou xphoon :P je le fais pour moins intimider les gens normaux qui regardent mon PC, histoire de passer pour un peu moins cinglé, ce qui échoue lamentablement quand ils voient les peintures de console, et que la souris reste inerte alors que les fenêtres dansent plus vite qu'ils n'ont jamais vu :D

        Note2: le fichier de conf monolithique de i3 étant un peu barbarre quand on multiplie les modes, j'ai aussi trouvé une astuce qui consiste à faire un script qui concatène des fichiers. Plus simple à maintenir et à répliquer les parties utiles d'une machine à l'autre (genre le mode audio et le lancement auto de ncmpcpp sur le netbook, il me sert pas: j'ai endommagé ce qui touche au son, alors je le réplique pas)

        • [^] # Re: Cahier des charges incomplet

          Posté par . Évalué à  1 . Dernière modification : le 07/11/12 à 20:24

          dmenu se contente de permettre à l'utilisateur de sélectionner une entrée dans une liste. Que cette liste soit composée des binaires du PATH est le fait du script dmenu_run. C'est un script shell plutôt simple et le modifier pour lui faire afficher ce que tu veux me semble assez trivial. La seule difficulté est de savoir quoi faire de ce fichier *.desktop. J'aurais bien quelques candidats pour les gérer : dapper, dex, fbautostart, … Mais, bizarrement, aucun d'eux n'est packagé par ma distribution et j'ai un peu la flemme du coup. :p

          Pour les raccourcis clavier, j'ai préféré modifier les raccourcis clavier d'i3. Il y a moins de conflits à gérer. Mais tu peux regarder du coté de noremap :

          noremap j h
          noremap k j
          noremap l k
          noremap m l
          
          

          A placer dans ton ~/.vimrc

          Si il fait double emploi pour le tiling, à quoi sert-il donc?

          Le découpage de terminal en carré de tmux est presque anecdotique à coté de ses autres fonctionnalité. J'apprécie particulièrement sa gestion de l'historique et du copier/coller.

          Oui, je sais, c'est le bordel, et je n'ai pas encore appris à tout bien manipuler avec i3 (il doit me manquer un truc, mais quoi… P'tet une commande que je n'utilise pas genre sélection du conteneur parent/fils?)

          # focus the parent container
          bindsym $mod+a focus parent
          # focus the child container
          bindsym $mod+b focus child
          
          

          Attention ça devient vite le bordel ! :P

          • [^] # Re: Cahier des charges incomplet

            Posté par . Évalué à  0 .

            Oui, je sais qu'on peut facilement déplacer le dossier scanné, d'ailleurs je l'ai fait pour voir même si du coup l'utilitaire est devenu moins utile vu qu'on ne peut pas lancer de .desktop :D

            debian semble avoir le dernier de packagé, je testerai ça ce soir. Peut-être qu'il y aurait moyen de combiner et le dossier /usr/share/applications pour binder une commande pour les applis X (et garder le mode classique sur un autre binding, vu que je viens d'apprendre qu'on peut passer des paramètres et que pour les kill ça peut effectivement devenir sympa avec un peu de travail)

            Pour la config vim: merci je teste ça dès que possible aussi!

            Et au sujet du bordel, oui, j'ai constaté que passé les 4 fenêtres mon workspace commence à sérieusement devenir moins évident à contrôler xD
            D'un autre côté, sauf pour mon workspace à tout faire, j'ai rarement plus de 3 applis donc bon.

        • [^] # Re: Cahier des charges incomplet

          Posté par . Évalué à  1 .

          Je m'explique avant qu'on m'accuse de troller: je lui reproche 2 choses (qui ne sont pas son problème, en fait, il fait juste son taf, mais je trouve que ça ne suffit pas) :

          Trollons peu mais trollons bien.

          1. il affiche par défaut TOUTES les appli dans PATH. Hors, seules les applications X ont un intérêt dans le cas du lanceur pour TWM. Limite, il faudrait juste lister les applis ayant un *.desktop (fichiers qui sont listés dans /usr/share/desktop ce me semble) sauf que bien sûr, on ne peut les lancer. Peut-être qu'il faudrait créer un dossier contenant des liens symboliques vers les applis du PATH, mais il faudrait pouvoir le mettre à jour automatiquement à chaque install de soft (ça dois être possible mais je sais pas comment faire avec dpkg, quelqu'un à une idée?)

          Ce comportement par défaut me va plutôt bien et le pourquoi du comment vient contredire ton second grief à son encontre…

          1. il ne supporte pas les arguments de commande. Ce serait un véritable pied de pouvoir lancer, par exemple (qui est fort pourri dans ce cas-ci, et peut-être même invalide, mais c'est l'esprit l'important) "wesnoth --nosound" en tappant "w --n". Une sorte de bash avec auto-complétion, mais juste avec les programmes cochons en somme (cf 1)

          … Ainsi, bien sûr que si.
          J'utilise dmenu très régulièrement avec des arguments.
          Typiquement pkill -USR1 redshift lorsque je souhaite désactiver redshift le temps d'un film ou autre, mais aussi quelques autres commandes dont la sortie n'a pas d'intérêt.

          A moins que le package archlinux et le port freebsd intègrent un patch pour cela, ne reproche pas à ce pauvre dmenu des choses qu'il fait si bien, en tout cas pour moi.

          • [^] # Re: Cahier des charges incomplet

            Posté par . Évalué à  0 .

            Pour les paramètres, ben… merde, j'étais sûr d'avoir essayé et que ça n'avais pas marché!!! Merci, pour le coup, vrai que ça va être plus pratique.

            Cela dis, pour la plupart des outils ligne de commande, je vois absolument aucune utilité. Certains kill (j'aurai plus pensé à killall moi, je ne connaissais pas pkill) ok, mais dans l'ensemble, pas sûr de voir. Après, c'est peut-être encore une manifestation de mon manque de connaissance.

            Conclusion: mea culpa pour avoir dis de la merde sur le fait que je ne pensais pas qu'on puisse lui fourguer des arguments et merci pour l'info. Reste a apprendre à manier ça pour voir l'intérêt d'un plus gros pourcentage de la pléthore d'outils en ligne de commande qu'il affiche (parce que les kill, ça fait quand même un très faible %)

  • # J'ai eu le même problème que toi mais en pire....

    Posté par . Évalué à  4 .

    J'utilisais aussi les tabs et les splits dans vim (dans tmux (dans tilling wm))…
    Le pire c'est de mapper les comportements identiques avec des shortcut différents pour par que ça fasse conflit… à devenir fou je te dis :)

    La sol pour moi:
    - essayer d'abord d'utiliser les fontionnalités en bas niveau quand elles sont dispo, puis si non satisfaction, monter un étage en plus (donc tout d'abord utiliser ce que vim propose, puis tmux, puis le wm)

    • [^] # Re: J'ai eu le même problème que toi mais en pire....

      Posté par . Évalué à  3 .

      C’est marrant mais j’ai tendance à faire exactement l’inverse : d’abord haut niveau puis bas niveau si j’ai des manques (typiquement le copier-coller dans vim).

      Ça fait moins à apprendre et ré-apprendre je trouve, puisque tu as plus de programmes « en bas » (vim, emacs, weechat, mutt, whatever), qu’en haut (tu as un seul wm à priori ;)).

  • # Pour les KDEistes

    Posté par . Évalué à  3 .

    J'imagine que beaucoup connaissent mais enfin au cas où : Yakuake !!

    Il sait se faire très discret (non présent dans la barre des tâches), permet bien sûr les onglets, et surtout sait se découper dans tous les sens (sans compter la personnalisation, mais ça ça va sembler normal à quiconque utilise KDE ;)

    • [^] # Re: Pour les KDEistes

      Posté par (page perso) . Évalué à  1 .

      Oui, mais non… :)
      j'ai longtemps utilisé kde, mais ça ne m'attire pas du tout ces derniers temps.
      J'ai essayé de m'y remettre il n'y a pas longtemps, mais je suis justement reparti sous i3 (après avoir essayé gnome 3, mais là j'ai vraiment pas tenu longtemps)

      En fait le côté light de i3 (ou équivalent) est quand même hautement addictif.
      Et je n'utilise aucun logiciel kde, du coup ça perd beaucoup de son intérêt.
      Dans une utilisation perso je dirais oui, mais là bof

      (en fait les logiciels que je lance sont quasiment tous en texte, à part sublime, chrome et thunderbird)

    • [^] # Re: Pour les KDEistes

      Posté par . Évalué à  2 .

      Ou guake.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # HS mais...

    Posté par . Évalué à  3 .

    Désolé ça me gêne trop : on écrit "tiling" et pas "tilling". Sinon ça se prononce pas taïling mais avec un "i" à la française, et ça me choque à la lecture…

    • [^] # Re: HS mais...

      Posté par (page perso) . Évalué à  8 .

      ha oué, pas faux :)

      Tiens, un pansement pour tes yeux…

        ________-------------________
       /        |           |        \
      |         |           |         |
       \________|           |________/
                -------------
      
      
      • [^] # Re: HS mais...

        Posté par (page perso) . Évalué à  3 .

        Corrigé.

        (et merci d'avoir attendu le 5e  thread de commentaires).

  • # Yo dawg !

    Posté par (page perso) . Évalué à  10 .

    I heard you like tiling, so I put a tmux inside a screen inside a terminator inside a tiling WM so you can tile while you tile while you tile while you tile !

    We must go deeper...

    \o/

    (Bon en fait j'avais la flemme d'installer un tiling WM juste pour ça, donc j'ai laissé openbox, mais tu peux le refaire avec i3wm, si tu y tiens)

  • # Une alternative

    Posté par (page perso) . Évalué à  4 .

    J'ai eu le plaisir d'essayer ratpoison, et je pense que ça peut t’intéresser : les fenêtres dans ce WM sont gérées comme des terminaux dans un tmux ou un screen. En pratique ça fait tout de même une manipulation de plus pour ouvrir une application (il faut d'abord casser la frame actuelle en deux, aller sur la deuxième qui est vide et lancer l'application), mais je pense qu'il y a moyen d'en faire quelque chose d’automatisé.

    • [^] # Re: Une alternative

      Posté par . Évalué à  1 .

      Comme la fait remarquer rakoo tu peux avoir par exemple 3 cadres et 5 terminaux qui tourne sur un bureau donné, il y a donc 2 terminaux qui ne sont pas visibles. Tu peux alors afficher un des deux terminaux en utilisant une commande "next" ou "previous", le comportement est cyclique sur les toutes les terminaux non visibles + le terminal courant (le focus sur le cadre).

      Si j'ai bien compris ton problème avec tmux, tu voudrait faire un cycle sur les terminaux uniquement (qui occupe alors un cadre). Tu ne peux pas faire une telle chose avec ratpoison, mais il tu peux avoir un telle comportement avec stumpwm ("next-in-frame").

  • # tiling + urxvtd

    Posté par . Évalué à  1 .

    Tout d'abord merci, grâce à ton journal j'ai pu découvrir Autocutsel. Un programme qui je sens va me rendre de nombreux services ! (Non, je ne me rappelle plus le chemin parcouru entre ton journal et cette page mais bon…)

    Sinon j'utilise xmonad + urxvtd, urxvtd pour rxvt-unicode daemon.
    Le démon est lancé au début de la session (urxvtd -q -o -f) et on crée un clients (un terminal) chaque fois que l'on en a besoin d'un.

    Chaque client est une fenêtre différente donc géré par le gestionnaire de fenêtre (donc comme on veut) mais ce comporte comme une seule entité (si un plante méchamment tout plante :-) (ça ne m'est arrivé que très très rarement, et en général je l'avais bien cherché)).

    Après, c'est juste x terminaux faiblement reliés entre eux et qui ne disposent pas de tous les features que j'ai pu voir pour tmux, mais c'est peut-être le début d'une piste…

    • [^] # Re: tiling + urxvtd

      Posté par . Évalué à  2 .

      Clipit ou parcellite avec les bons raccourcis-claviers, c'est pas mal non plus.

      Pour l'objet du journal :
      Perso, c'est awesome + screen / tmux sur un portable en 1400x1050, mais windowmaker sur un double-écran, avec une config bien perso.
      Je trouve que la config idéale dépend vachement de l'espace que tu as sous les yeux.

      Et sinon, pour rajouter au suggestions : il y a aussi dvtm, qui peut rendre pas mal de services quand on est devant une console (un peu évoluée).

  • # idem

    Posté par . Évalué à  2 .

    J'ai eu un problème similaire longtemps avec awesome + screen. Bon screen ne gérait pas vraiment le tiling, juste le split horizontal. Du coup, j'utilisais le tiling d'awesome, tout en récupérant a chaque ouverture de shell, la session screen courante. Il me suffit de switcher ensuite sur le terminal qui m'intéresse ou d'en ouvrir un nouveau.

    Depuis, je suis passer à i3 et je n'utilise plus de multiplexeur de terminaux. ça me manque un peu, mais pas tant que ça. Comme je fais moins d'exploit, je me connecte moins sur 12000 équipements en même temps, et je n'éprouve plus le besoin d'avoir autant de terminaux ouvert. Ça me manque un peu justement quand l'exploit appelle pour débugger un truc à la con sur le réseau.

    La fonctionnalité qui m'a tué dans i3, c'est ce concept de containers imbriqués qui fait que tu peux simplement mettre en place les dispositions les plus tordues avec quelque raccourcis simple.

    • [^] # Re: idem

      Posté par . Évalué à  3 .

      on screen ne gérait pas vraiment le tiling, juste le split horizontal.

      Je vous demande patron, qu'est ce que vous bite?

      ctrl+a et | et hop, une découpe verticale, une!

      • [^] # Re: idem

        Posté par . Évalué à  0 .

        Oui, ça a été intégré depuis la version 4 qui mis une plombe à sortir, mais dans le temps, ça le faisait pas, ou fallait le patcher.

        • [^] # Re: idem

          Posté par . Évalué à  2 .

          Oui, ça a été intégré depuis la version 4 qui mis une plombe à sortir,

          En même temps, ça fait juste que 8 ans qu'elle est dispo.

          Bien avant tmux et bien avant qu'Awesome ne soient nés, donc ta remarque initiale m'étonne 0_0.

          • [^] # Re: idem

            Posté par . Évalué à  1 .

            Bah, ben ça me troue le … mais screen sous arch, qui fourni la version "officielle", n'a toujours pas le spit vertical, ou alors, je ne le trouve pas.

            A priori, faut installer un screen patché depuis aur pour l'avoir.

            Sous debian, ils suivent depuis 2011 la version git http://packages.qa.debian.org/s/screen.html et ils devaient le patcher avant, je suppose.

            "Release early, release often" qu'ils disaient….

            • [^] # Re: idem

              Posté par . Évalué à  0 .

              Bah, ben ça me troue le … mais screen sous arch, qui fourni la version "officielle", n'a toujours pas le spit vertical, ou alors, je ne le trouve pas

              Voici la version que j'utilise sous Ubuntu:
              Screen version 4.00.03jw4 (FAU) 2-May-06

  • # awesome + urxvt

    Posté par . Évalué à  4 .

    Avant j'utilisais l'extension tabbed d'urxvt avec awesome, mais maintenant j'utilise une profusion de terminaux que je manipules avec awesome. Ce que j'aimerais c'est avoir un navigateur du niveau de firefox sans onglets mais avec une « conscience globale ».

    Si tu cherche à n'avoir qu'un seul terminal (comme moi avant avec urxvt) awesome permet de faire un run or raise : http://awesome.naquadah.org/wiki/Run_or_raise C'est très pratique.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: awesome + urxvt

      Posté par . Évalué à  2 .

      Si tu cherche à n'avoir qu'un seul terminal (comme moi avant avec urxvt) awesome permet de faire un run or raise : http://awesome.naquadah.org/wiki/Run_or_raise C'est très pratique.

      ah, comme sous Gnome Shell en fait, avec un coup d'alt+² pour naviguer uniquement parmi les instances/fenêtres d'une même application.

      • [^] # Re: awesome + urxvt

        Posté par . Évalué à  2 .

        Ma formulation n'est pas terrible. Je voulais dire « sous awesome je fais du "run or raise" avec ça » et pas « regarde comme awesome est bien, il permet de faire du run or raise ».

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # le meilleur de chaque

    Posté par . Évalué à  1 .

    J'ai eu a me poser la même question.

    Au final, j'utilise le tilling de tmux pour les connections SSH. En local, je trouve plus efficace et souple d'utiliser les possibilités du gestionnaire de fenêtre (i3). Mais je conserve toujours une session tmux dans chaque terminal ouvert. C'est trés pratique en offrant son copier-coller à multi-buffer, la permanence des sessions, la navigation dans l'historique…

    La combinaison i3 + tmux est excellente pour peu qu'on apprécie le terminal et les applications qui vont avec. J'ai même légèrement patché dmenu_run pour qu'une sélection d'applications texte aient un traitement de faveur : lancement d'un nouveau terminal avec sa propre session tmux nommée ou rappel d'une existante.

  • # déconnexions

    Posté par (page perso) . Évalué à  2 .

    J'utilise awesome et screen. L'intérêt principal et de pouvoir retrouver mes sessions ssh quand ma connexion internet plante ou d'avoir mon environnement prêt quand je dois intervenir de nuit.
    Je lance un urxvt‚ je me connecte a un serveur‚ je récupère mon screen et hop le tour est joué.

    En plus ça m'evite de laisser traîner des nohup.out partout.

  • # On veut une parenthèse 2.0 sur LinuxFr !

    Posté par (page perso) . Évalué à  2 . Dernière modification : le 06/11/12 à 11:09

    un gestionnaire de fenêtre pavant (_tiling_ quoi)

    Encore une victime du couple parenthèse-underscore !

  • # démutiplexeur de terminal

    Posté par (page perso) . Évalué à  2 .

    Je m'étonne que tu aies besoin d'autant de terminaux.

    Il y a trois types d'interfaces sous console:
    - Celles qui utilisent la ligne de commande du shell, et qui rendent la main une fois lancée.
    - Celles qui utilisent une ligne de commande interne, et qui donc ne rendent pas la main une fois lancée.
    - Celles qui n'ont pas d'interface en ligne de commande, et qui utilisent une pseudo interface graphique.

    Je ne connais pas toutes les applications que tu utilises en console, mais j'imagine qu'elles font partie de la seconde ou de la troisième catégorie, et j'imagine aussi que tu dois pouvoir trouver des applications équivalentes dans la première catégorie. Par exemple alsaplayer -q pour la musique.

    Cela allègera d'autant ton espace de travail, et résoudra la problème du démultiplexeur de terminal.

    • [^] # Re: démutiplexeur de terminal

      Posté par (page perso) . Évalué à  2 .

      Je m'étonne que tu aies besoin d'autant de terminaux.

      En fait, déjà, je n'utilise quasiment plus de gestionnaire de fichier. Pour ce que j'en fait ça ne servirait à rien la plupart du temps (il n'y a que quand je dois gérer des images par exemples).

      Ensuite, j'ai en général :

      • une console posé sur les sources git du projet sur lequel je bosse -> diff, commit, historique, etc. Je ne fais pas grand chose de plus dedans, je veux qu'elle soit toujours dispo (ça rentre dans ton 1)
      • une console qui est en ssh sur un serveur, pour voir les logs par exemple
      • à multiplier en général par 2, car je switch parfois un peu trop fréquemment de projet ou j'ai des choses en arrière plan
      • une console qui me permet de gérer mon vagrant (en général, ça n'est pas toujours indispensable)
      • souvent un irssi
      • ncmpcpp
      • htop
      • sous i3 (comme d'autres) c'est tellement facile d'ouvrir une console à la volée, que lorsque je dois faire une action, quelle soit le bureau, en général j'ouvre une console, fait mes 2 3 trucs, édite un fichier dans emacsclient, ferme la console
      • si j'ai besoin, je peux rajouter 2 à 3 consoles supplémentaires en ssh sur des serveurs de préprod/prod

      Cela allègera d'autant ton espace de travail, et résoudra la problème du démultiplexeur de terminal.

      En fait, mon problème n'est pas tellement à ce niveau, mon espace est plutôt léger et organisé, je ne perd que peu de temps à me déplacer dans mes fenêtres.

  • # awesome + tmux bis, ou ter... je sais plus

    Posté par (page perso) . Évalué à  3 . Dernière modification : le 06/11/12 à 14:33

    Salut !
    Je me suis posé à peu prés les mêmes questions que toi, et je crois que j'ai commencé à trouver un équilibre sous awesome.
    Je pense aussi qu'on peut faire de bonnes choses avec d'autres WM, mais je ne les connais pas.
    J'ai aussi quitté les KDE, Gnome et Autres, car moins légers, tout ça tout ça… c'est pas le débat.
    Et le gros avantage que je trouve à Awesome, c'est le "tiling + floating" ou "pavant + flottant". En bref, selon l'application, tu choisis ton mode (voir tu "switch" dynamiquement).

    Pour reprendre les points principaux du journal :

    Tmux/Screen

    • Screen n'est plus que moyennement maintenu et la légende dit que ce n'est plus maintenu du tout.
    • Tmux, ça fait quasiment tout ce que fait screen, si ce n'est le partage de session qui est moins bien géré. La encore ça vient de la blogosphère et forumoshpère, je n'ai pas testé. Tout ça pour dire, que je suis en train de passer de Screen à Tmux et je ne manque d'aucune fonctionnalité utile (tiling, éventuellement imbriqué et sauvegardé, gestion de session). Je dirais même que tmux est infiniment plus simple à scripter que Gnu Screen (Et oui je suis de la génération flemmard !).

    Thunderbird

    Je ne dirais qu'une chose : muttator pour les fans du clavier. J'arrive à utiliser aujourd'hui entièrement Thnuderbird au clavier (rédaction des mails sous emacs) et même le Sunbird, qui malgré tout est resté numéro un dans mon coeur face aux calcurse et autres outils de type console.

    Le flottant

    Personnellement j'utilise aussi Gimp, logiciel type qui n'aime pas le pavant. Et pour ça, sous awesome j'affecte un bureau virtuel particulier à cette application, avec un "layout" (ou mise en page) de type flottant. Et là, c'est le pied.

    Le pavant

    Je ne vais pas faire l'apologie du pavant, mais là où je l'utilise (étant revenu du terminal en fullscreen), c'est pour avoir un emacs d'un côté et un terminal de l'autre (ultra pratique pour les non vimistes ou toute personne qui trouve bien de séparer terminal d'éditeur). Ou pour gérer mes multiples machines virtuelles. J'imagine aussi l'utiliser pour pidgin (irc, xmpp, vidéo tchat, tout ça tout ça), mais je n'y suis pas encore. Et là, la fonctionnalité d'awesome qui tue le mamoute (pour garder un vocabulaire châtié) : c'est la gestion de fenêtre maitre/esclave avec redimensionnement dynamique. En gros : tu as une fenêtre maitresse qui prend la partie gauche de l'écran (avec un tiling gauche, pour l'exemple), et toutes les autres regroupées dans la partie droite. En utilisant un subtil jeu de features, tu peux faire tourner les fenêtres dans la zone maitresse, agrandir ou rétrécir la zone maitresse, et plein d'autres choses (y compris la vaisselle). Ca demande un peu de temps, mais c'est super pratique et ça permet de faire bien plus de choses que le tiling de Tmux ou Screen.

    2/3 fonctionnalité Awesome super sympa (mais probablement dispo sur d'autres WM)

    • légèreté
    • configurabilité (en lua, mais c'est pas mal :))
    • intégration client dbus interne et externe, via l'outil awesome-client. Ca c'est super pour faire ses propres widgets : la partie affichage en lua (ça fait 3 lignes à copier/coller dans ses fichiers de config) et la partie récupération d'info, dans le langage que l'on veut.
    • Les applications Drop Down (une fenêtre "gluante", enfin "sticky" quoi, qu'on fait apparaître/disparaître d'un simple raccourcis clavier) qu'on peut appliquer dynamiquement à toutes les fenêtres.
    • menu contextuel (super+M affiche menu mdp par exemple, ce qui donne super+M + L pour lecture, super+M + P pour pause, …etc)

    Bref, c'est pas mal les WM alternatifs :)

    Et pour ceux qui diraient que tout en console c'est magnifique, dites moi comment vous faites de la vidéo conférence pour montrer votre dernier rejeton à grand mamie en terminal, et alors j'approuverai :)
    Plus sérieusement, il y a quand même des applis non console assez sympa :)

  • # Byobu

    Posté par . Évalué à  1 .

    J'ai découvert récemment, c'est un ensemble cohérent de scripts pour tmux et screen, et c'est assez bien fait pour que je n'ai pas envie de changer toutes les bindkeys par défaut. Avec Tilda, c'est quasiment parfait pour moi.

  • # gestionnaire classique + terminator

    Posté par . Évalué à  2 .

    j'avais essayé WMFS comme tiling manager
    puis j'en suis revenu pour rester sur le gestionnaire de fenetre par defaut.

    je tourne donc avec unity, 4 bureaux (un par "activité" : web/mail/console/divers)
    dans le bureau console j'ai terminator en mode maximisé (pas en plein ecran pour garder le dock en haut et le lanceur à gauche)

    ensuite c'est les raccourcis clavier pour :
    - ouvrir un terminal avec split horizontal (un au dessus de l'autre) : Ctrl+Shift+O
    - ouvrir un terminal avec un split vertical (cote à cote) : Ctrl+Shift+E
    - naviguer dans les terminaux : Ctrl+Tab mais je crois qu'on peut aussi utiliser les fleches
    - mettre le terminal en plein ecran (et en revenir) : Ctrl+Shift+X

    y en a plein d'autres raccourci je suis loin de tous les maitrisés.
    mais on peut faire des groupes de terminaux pour faire l'equivalent de cssh par exemple.

Suivre le flux des commentaires

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