yazgoo a écrit 59 commentaires

… et donne moi la recette du cassoulet

Dans mon cas c'est pour mémoriser un texte de théatre

j'ai mis du temps à comprendre ce qu'était NXI, pas du tout clair pour moi, j'ai bon ?

skim: https://github.com/lotabout/skim/

pour tester tu peux lancer vim -c terminal puis sauter quelques lignes et lancer choose.

Après l'autre choose est dans pas mal de gestionnaires de packet malheureusement :(

Sympa ce petit outil.

Perso pour ce genre de chose j'utilise fzf ou mieux, skim .

Tu prévois d'ajouter un support de fuzzy finding ?

Je ne sais pas pourquoi, mais dans le terminal de vim/neovim le choix se place mal (en haut au lieu du niveau de la sortie de la commande) :

   choose.1
    examples
❯ echo

❯ echo

❯ ls | ./choose
    choose
    choose.1
    examples
    README.md
    TODO

autre remarque, il existe déjà une commande du même nom, ça pourrait préter à confusion

https://github.com/theryangeary/choose

effectivement, je suis tombé sur ce projet en faisant mes recherches, ça a l'air très cool :)

Merci, Je vais regarder ça, je ne suis pas très au fait de comment faire pour rendre l'app compatible avec firefox pour Android

C'est bien d'avoir du typage explicite (on peut notamment imaginer d'utiliser ça dans un language server/IDE pour avoir de meilleures suggestions, et ça peut permettre de faire des vérifications à la compilation JIT ou via un outil dédié j'imagine? et donc d'avoir de meilleures garanties sur ce que fait le programme).

Dommage d'avoir les déclarations de type dans un fichier séparé, je trouve ça particuliérement pas pratique.
Ça aurait été mieux de l'avoir directement dans les méthodes/classes.
Un peu l'impression que sur ça (notamment) ruby a un train de retard.

Merci !

Si un modérateur passe par là, je me suis trompé sur la langue du lien (français au lieu d'anglais) et je n'ai pas l'impression qu'on puisse l'éditer.

Merci d'avance

Non, je n'ai pas implémenté de logique de MRU car je n'en ai pas encore eu besoin.

Au niveau ergonomie, c'est un gestionnaire de fenêtre en tuile basique.

En résumé, j'utilise XCB pour suivre des évenements (création et destruction de fenêtre, bouton pressé, …)
et en fonction je redimensionne, affiche ou cache les fenêtres.

Un bon moyen pour comprendre comment un WM marche (même si xlib est utilisé au lieu d'xcb qui est plus récente) est de regarder le code source de
tinywm.

Merci.
Oui, c'est effectivement plus une barre de status. Après je n'exclue pas de rajouter un peu d'interactivité dans le futur mais ce n'est pas la priorité.

Merci beaucoup :) !

Merci pour ton retour, c'est fait !

En ce qui me concerne, je comparereai plutot ça à du home brewing :)
À savoir que je fais ma bière (mon wm) d'abord pour moi, et que je la partage avec des gens parceque je pense qu'elle peut les intéresser.
De plus si j'ai des gens qui me donnent des conseils pour l'améliorer, voir qui participent à l'améliorer, elle ne peut que devenir meilleure.

Merci

En fait c'est ce que je propose aussi pour umberwm :)
(à savoir que umberwm est une lib (crate) qu'on appelle dans un main :) (par exemple main.rs )

Excellente idée, je vais peut-être faire ça !

J'ai commencé à me documenter sur le sujet, et de ce que j'ai compris c'est pas du tout évident de faire un WM pour wayland.
À savoir que dans wayland, il n'y a pas de distinction entre le compositor et le WM.
Du coup si tu veux implémenter l'un il faut implémenter l'autre, ou réutiliser une lib qui fait la partie compositing pour toi.
et il n'y a malheureusement pas de binding pour wlroot en rust.

Salut, le main.rs est dans un répo séparé, celui dans le README, à savoir:

https://github.com/yazgoo/myumberwm

Si tu es adepte de la ligne de commande, j'ai fait un outil qui utilise youtube-dl et qui peut-etre pourrait aider:

https://github.com/yazgoo/youtube-subscriptions

Je ne tappe pas vite mais à un moment j'utilisais iterm2 que je trouvais très désagréable et dès que je suis passé à kitty je me suis mieux senti, c.f:
https://danluu.com/term-latency/

Perso j'avais besoin d'un emulateur terminal rapide (ne pas ressentir de lenteur à la frappe).
Avant j'utilisais kitty qui fait ausssi du rendu GPU.
Je ne pense pas que ce soit vraiment nécessaire néamoins (st est très rapide sans GPU).
Pour plus d'explications sur les motivations du truc:
https://jwilm.io/blog/announcing-alacritty/

Un des autres avantages que je voit est qu'il est en rust => moins de leaks, moins de segfaults

Je suis d'accord, surtout que l'async se stabilise de plus en plus

Merci pour la correction !

Merci pour ton retour.

Pour ma part j'utilise alacritty et ça tourne correctement, je n'ai pas vraiment essayé avec d'autres emulateurs de terminaux.
J'imagine que selon comment le terminal flush ou bufferise la sortie standard c'est plus ou moins rapide (blockish, lui, ne flush qu'une fois l'image complète écrite).

Il y a encore des optimisations à faire, notamment celle que tu proposes, je vais m'y pencher.