OcLaunch, launch automagically

Posté par (page perso) . Édité par palm123, Benoît Sibaud et tankey. Modéré par Pierre Jarillon. Licence CC by-sa
Tags :
18
22
avr.
2015
Bureautique

J'ai commencé à écrire il y a un an déjà une petit programme en ligne de commande qui répond au besoin suivant : lancer progressivement (tout au long d'une session) des programmes, avec un ajout/retrait de la liste aussi aidé et rapide que possible.

logo

Génèse du projet

L’idée de base était d’afficher régulièrement une liste de tâches avec Taskwarrior.

Après coup, on se rend compte que ça peut servir à programmer des tâches pour un prochain démarrage (finir de télécharger la dernière distribution à la mode, compresser un dossier, planifier une mise à jour…) ou à utiliser aisément un client en ligne de commande (par exemple profanity ou irssi).
L’avantage par rapport au simple ajout de la commande dans le bashrc, c’est qu’on ouvre son terminal une première fois, le client de clavardage (par exemple) s’affiche et au deuxième lancement, pas de nouvel affichage, on peut travailler.

Fonctionnalités actuelles

  • Ajout aisé de programmes (graphiques ou en ligne de commande) par envoi sur l’entrée standard de la commande ou édition du fichier de configuration
  • Liste des programmes actuels
  • Suppression très facile
  • Fichier de configuration alternatif
  • Installation facile avec 0install & simple ajout de la commande oclaunch au bashrc

S’approprier le programme

J'attends vos retours avec impatience ! Je serai ravi d’ajouter des fonctionnalités (il y a déjà une bonne TODO list, si vous voulez participer). Contactez-moi par courriel par exemple leowzukw CHEZ vmail POINT me

Le logiciel est bien entendu libre (licence CeCILL) et hébergé chez Tuxfamily. Merci à eux !

  • # Bien, mais presque « lapin compris ! »

    Posté par (page perso) . Évalué à 10. Dernière modification le 23/04/15 à 09:16.

    Merci pour cette dépêche !

    Un ptit commentaire pour dire qu'il m'a fallu bien 10 minutes, parcourir l'ensemble des liens de journal, regarder tous les exemples, relire la dépêche, pour comprendre ce que faisait OcLaunch. Et encore, j'ai des doutes :)

    Je ne critique pas la présentation, car c'est très dur de présenter un outil qui propose une fonctionnalité nouvelle, c.-à-d. sans pouvoir se comparer à un autre outil.

    Pour résumer (tu me diras si j'ai bien tout compris), OcLaunch :

    • Se lance automatiquement à chaque ouverture de session de terminal.
    • Utilise une liste de « tâches », dont la manipulation (ajout/retrait) est pensée pour être simple et rapide (notamment avec un GUI, si j'ai bien compris).
    • Lance à chaque appel (donc à chaque ouverture de terminal) les « tâches » comprises dans sa liste.

    Question : Est-ce qu'il faut supprimer explicitement une tâche de la liste (tâche persistante), ou est-ce fait automatiquement après son appel (tâche type « run only once ») ?

    • [^] # Re: Bien, mais presque « lapin compris ! »

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

      Si un point en particulier n'est pas clair, je suis naturellement ouvert à toute proposition d'explication.

      Effectivement, OcLaunch lance à chaque ouverture du terminal un des éléments de la liste, dans l'ordre. C'est ainsi que je l'utilise. Comme il s'agit d'un simple appel de la commande, on peut imaginer lancer manuellement (oclaunch) ou utiliser une tâche cron, un script quelconque…

      Pour l'ajout pensé aussi simple que possible, c'est tout à fait ça. (Il n'y a juste pas de GUI en dehors de ton éditeur de texte préféré ;-))

      Il faut pour le moment supprimer explicitement (oclaunch -d <numéro de la tâche, facultatif si on veut retirer la dernière>).

      L'idée est que pour une utilisation quotidienne, on lance toujours un certains nombre de programme, la liste n'évolue pas (tâche persistante).
      On pourrait imaginer cependant qu'une option de la configuration permette à terme de supprimer automatiquement.

      PS : J'ai ajouté la demande de fonctionnalité à la TODO liste

  • # Mercatique et innovation

    Posté par . Évalué à -10. Dernière modification le 23/04/15 à 09:36.

    Salut,

    …Compte crée hier pour publier dans la foulée… Hum. Tu ne t'appellerais pas SamWang des fois ?

    Que d'innovations sur un seul article ! C'est le fait d'avoir programmé en OCaml, Tu t'es lâché ? Du coup, tu nous as plaqué un logo pleine page avec un chameau sur les "starting blocks" son élastique !

    Tu sais que ta solution n'est pas tout à fait optimale en terme de tenue de chameau. Tu aurais pu avantageusement caler l'élastique entre les deux bosses. Ha ! Tu craignais que ledit chameau se mange le support de la fronde au lancement… Monsieur fait dans la sécurité ! On se croirait presque un vendredi…

    Bon, tu as gagné 15 points en mercatique avec la pleine page, c'est mal bien car tu as mis à l'honneur le chameau du logo officiel d'OCaml :

    Logo officiel d'OCaml
    …Et c'est bien mal car je ne vois aucune référence à un paquet logiciel pour GNU/Hurd :-°

    Ok, je t'ai charrié tout le long, avec un humour caustique en première approche, mais c'était amical. Bienvenue dans un monde libre contrôlé, aux effets de bords limités (*), au paradigme fonctionnel :o)

    Bravo pour avoir osé programmer en OCaml, c'est une démarche qui gagne à être dupliquée et merci pour ton partage :D

    (*) Cf les avantages de la programmation fonctionnelle dont celui de s'affranchir de façon radicale des effets secondaires (ou effets de bord), je cite : « Le paradigme fonctionnel n'utilise pas de machine à états pour décrire un programme, mais un emboîtement de fonctions que l'on peut voir comme des « boîtes noires » que l'on peut imbriquer les unes dans les autres. Chaque boîte possédant plusieurs paramètres en entrée mais une seule sortie, elle ne peut sortir qu'une seule valeur possible pour chaque n-uplet de valeurs présentées en entrée ».

    PS : excusez-moi pour toutes les ratures, c'est à force de contribuer peaufiner de la dépêche dans l'espace de rédaction :o)

    • [^] # Re: Mercatique et innovation

      Posté par . Évalué à -10. Dernière modification le 23/04/15 à 11:23.

      Arf ! J'observe la modification de la taille du logo de "OcLaunch", lol. C'était vraiment pleine page (sur un écran de portable) ;) D'ailleurs, franchement, si vous pouvez trouver un juste milieu, pour faire honneur à l'effort de conception sur le logo (qu'on ne voit plus qu'en écarquillant les yeux), ça sera mérité :)

    • [^] # Re: Mercatique et innovation

      Posté par . Évalué à -10.

      Mince, j'ai voulu apporter un peu de pédagogie après une séquence humoristique-sarcastique mais j'ai manqué ma cible. Je corrige le tir ci-après.

      En choisissant mieux les bornes de la citation de wikipédia, on obtient les informations significatives (en gras) suivantes :

      • Il s'agit de « s'affranchir de façon radicale des effets secondaires (ou effets de bord) en interdisant toute opération d'affectation » (il n'y a pas d'affectation dans le corps d'une fonction).

      Ce que j'aurais pu appuyer en rajoutant également le bout de gras suivant :

      • « Le paradigme fonctionnel n'utilise pas de machine à états (…) Chaque boîte possédant plusieurs paramètres en entrée mais une seule sortie, elle ne peut sortir qu'une seule valeur possible pour chaque n-uplet de valeurs présentées en entrée. Ainsi, les fonctions n'introduisent pas d'effets de bord ».
      • [^] # Re: Mercatique et innovation

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

        Je ne vois pas le rapport entre le fait d'avoir une seule valeur en sortie et le fait de ne pas introduire d'effet de bord. QQ'un peut expliquer ?

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: Mercatique et innovation

          Posté par . Évalué à -10. Dernière modification le 23/04/15 à 15:20.

          Il n'y a pas de rapport direct, tel que tu l'énonces, en effet.

          C'est le fait que ne soit pas autorisée une quelconque opération d'affectation (dans le corps d'une fonction) qui annihile tout effet de bord dans le déroulement algorithmique qui mène des paramètres en entrée à la valeur en sortie. Que la valeur en sortie soit unique (au sens de atomique) ou composite n'entre pas en considération, ici. Il pourrait y avoir de multiples valeurs en sortie que ça ne changerait rien. Ce qui importe c'est que la valeur en sortie soit définie de façon unique pour un même n-uplet en entrée.

          Dit plus succinctement : le tout est que pour un même n-uplet de valeurs présentées en entrée, la sortie (quelle soit une valeur ou un n'-uplet (1) de valeurs) soit définie de façon unique, c'est à dire sans qu'il y ait la possibilité d'une interférence par d'autres phénomènes (2) dans le corps de la fonction.

          /* réflexion à voix haute (sur un autre sujet) : nom d'une pipe, je commence à réaliser au fil des années l'ampleur de la tâche consistant à produire un langage naturel contrôlé (LNC) et un bon usage de celui-ci permettant de lever toute ambiguïté, notamment pour obtenir une traduction automatisée de LNC. */

          (1) lire "n prime uplet", pour le distinguer du n-uplet d'entrée
          (2) quoi d'autre qu'une affectation pourrait interférer dans le déroulement déterministe d'une fonction dans le paradigme de la programmation fonctionnelle ? La lecture d'une valeur sur une sonde par exemple ? Ah oui… Peut-elle intervenir sans qu'il y ait affectation ? Ben ça fait trop longtemps que je n'ai pas programmé en OCaml pour savoir répondre :). Peut-être un érudit en OCaml saura répondre ? Peut-être l'auteur de la dépêche ?

          • [^] # Re: Mercatique et innovation

            Posté par . Évalué à -10. Dernière modification le 23/04/15 à 18:07.

            Je propose une courte phrase pour résumer cette classe d'avantages de la programmation fonctionnelle (la stabilité de comportement par l'absence d'effets de bord, la réutilisabilité) :

            A)
            Comme la sortie d'une fonction ne dépend strictement que de ses paramètres d'entrée, alors la réutilisation de cette fonction dans un autre contexte ne peut pas générer d'effets de bord.

            La même phrase plus détaillée :

            B)
            Comme la sortie d'une fonction ne dépend strictement que de ses paramètres d'entrée (parce qu'aucun autre phénomène variable — par le biais d'une affectation — modifiant la sortie n'est autorisé dans le corps d'une fonction, par conception du langage), alors la réutilisation de cette fonction dans un autre contexte ne peut pas générer d'effets de bord pour ce qui concerne le comportement de cette fonction (effets de bord que l'on pourrait imaginer être induits par ce changement de contexte, comme en programmation non fonctionnelle).

            À noter que les deux phrases intègrent cette caractéristique de définition univoque de la valeur de sortie pour un n-uplet donné de valeurs d'entrées (par la formulation "ne dépend strictement que de" qui implique qu'il n'y a pas de dépendance à un autre phénomène, y compris même à un tirage aléatoire au sein de la fonction).

            Ainsi, alors que dès la première phrase on pourrait penser que c'est la réutilisabilité qui est spécifiquement présentée (une fonction étant alors réutilisable sans soucis d'effets de bord dans un autre contexte, c'est à dire dans un programme distinct ou un autre endroit dans le même programme), en fait puisqu'elle précise aussi le caractère strictement univoque de la sortie en fonction de l'entrée, elle témoigne aussi de la stabilité de comportement par l'absence d'effets de bord au sein d'un même programme, alors que le contexte du programme évolue (à l'exécution).

            Hmmm… Je sens que cette voie de l'exercice à titre pédagogique est propice à l'accroissement de la pertinence en atelier constituant :)

          • [^] # Re: Mercatique et innovation

            Posté par . Évalué à -10. Dernière modification le 23/04/15 à 20:09.

            En me relisant je découvre de petites erreurs rendant la compréhension pénible (par le manque d'une virgule et secondairement d'une apostrophe)… Correction :

            Dit plus succinctement : le tout est que, pour un même n-uplet de valeurs présentées en entrée, la sortie (qu'elle soit une valeur ou un n'-uplet (1) de valeurs) soit définie de façon unique, c'est à dire sans qu'il y ait la possibilité d'une interférence par d'autres phénomènes (2) dans le corps de la fonction.

  • # gnein ?

    Posté par . Évalué à 6.

    Pourrais-tu donner d'autres exemples d'utilisation d'OcLaunch en faisant une espèce de comparaison avec un déroulement sans OcLaunch ? Parce que pour le lancement du client de messagerie je ne saisis pas du tout l'intérêt à part économiser une opération de lancement d'un programme…

    L'objectif est-il de ne lancer que des terminaux et finalement ça lance une par une les opérations que tu as planifié ?

    • [^] # Re: gnein ?

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

      C’est tout à fait l’objectif, en tout cas tel que je ne m’en sers actuellement principalement que comme ça. Si tu as d'autres idées, n’hésite pas !

      L’intérêt pour le client de messagerie, dont la commande est assez courte pour être tapé à chaque fois peut effectivement sembler limité.

      Je vais reprendre l’exemple du site avec Taskwarrior, puisque c’est ce programme qui m’a amené à développer le logiciel.

      En ajoutant dans le bashrc la commande task, qui affiche une liste des tâches (j'avais commencé comme ça)

      • À chaque ouverture du terminal, la liste est affichée.
      • C’est assez pénible à l’usage : ça prend la moitié de l’écran, c'est assez long de lancer sans cesse la commande (particulièrement avec d’autres commandes plus longues ou au milieu d'une session avec un tas de choses qui tournent) et surtout lassant (en affichant 100 fois par session la liste de choses à faire, on ne la lis plus dès le deuxième affichage et c’est donc contre-productif)

      Avec OcLaunch

      • On peux ajouter task à la liste d'OcLaunch, la liste de tâches est affichée une fois et aux lancements suivants d'un terminal, rien.
      • On peut bien sûr rappeler la liste par son numéro avec oclaunch 0 (0 puisqu'elle est seule dans notre exemple).
      • On peut en plus afficher par thème (par exemple task +rdv pour afficher les rendez-vous, puis task ls pour afficher une liste minimale) puis… plus rien, on laisse l’utilisateur en paix.
      • C’est plus rapide à l’usage, mais surtout plus efficace : on ajoute autant de programmes que l'on veut alors que on ne peux pas mettre plus d’une commande dans la bashrc au risque de ne pas voir sa sortie et d’aggraver le problème de lenteur.

      PS : J'espère que cet explication rend les choses plus claires. Si tel est le cas, je pourrais l'ajouter au site web, ça en aidera plus d'un.

  • # Intéressant mais quelques limites

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

    Projet intéressant.

    Je vois cependant plusieurs limites :
    - pour lancer une application graphique, tu dois passer par l'ouverture d'un xterm
    - tu es vite limité par la création d'une seule liste de "tâches". Imaginons que tu veuilles préparer des environnements de travail par bureau virtuel, comment fais-tu ?

    Sans parler de difficulté de configuration, je me suis déjà penché sur cette dernière question et j'ai trouvé une solution avec xdotool (exemple). Cependant, Je suis conscience que ce n'est pas tout à fait ce que tu proposes :)

    • [^] # Re: Intéressant mais quelques limites

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

      Comme je l'ai indiqué dans les commentaires précédant, OcLaunch peut-être utilisé à peu près partout, c'est une simple commande, même si le plus pratique semble être une application type xterm.

      Il n'y a pas de limitation de liste de tâche. Je ne l'ai pas indiqué dans la dépêche mais on peu passer un fichier de configuration de la commande en argument oclaunch -c <le fichier>. On peut ainsi avoir plusieurs fichiers de configuration et donc plusieurs listes. C'est une fonctionnalité assez récente qui doit être améliorée mais ça marche à peu près. Par ailleurs, le programme pourrait tirer partit du contexte (bureau virtuel, activités dans KDE…).

      Je ne connaissait pas xdotool mais c'est effectivement beaucoup plus lourd à configurer. Par contre, les possibilités semblent plus importantes.

Suivre le flux des commentaires

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