Ezka a écrit 14 commentaires

oui j'ai posté un peu vite, je ne pensais pas forcément à l'édition, mais par exemple pour les nom de plante j'imaginais des tags un peu plus généraux/globaux "botanique", "Nord", "Amérique", "comestible" pour par exemple te concentrer sur les plantes nord-américaine comestibles =) bon ça suppose peut-être d'avoir un peu trop de données à vouloir se souvenir et ça dépasse le cadre de ce logiciel.

Du coup dans ce cas le graphe te permet de visualiser les tags ou les groupes de cartes sur lesquels tu as répété, et ceux où tu dois répéter, et si tu en as un certain nombre au lieu de le faire aléatoirement tu peux choisir ceux qui sont en relation (et donc t'en souvenir plus facilement).

As-tu pensé à une version web ? je ne connais pas les autres logiciels mais ça peut te permettre de le porter sur les téléphones et autres support mobile pour faire tes répétitions dans le bus, en avion, dans ta-voiture-qui-conduit-à-ta-place, etc … =)

Pour naviguer dans les cartes mémoires tu peux ptêtre te tourner vers des FW de visualisation de graphe basé sur tes tags (par exemple visjs.org mais c'est pour le web) et ainsi mettre en relation l'ensemble de tes cartes ? ça peut permettre de changer un peu ton algo d'apprentissage et quand tu révises un carte tu peux choisir de parcourir le thème associé, l'algo choisissant les cartes à te présenter.

J'avais/J'ai un porte-clef métallique de La.Poste justement avec un numéro gravé qui mentionne le fait que si quelqu'un trouve les clés il peut les poster pour que je puisse les recevoir =)

Bon ça fait des années et je n'ai pas perdu mes clés donc je n'ai jamais vérifié si ça marchait =D

Pour revenir au sujet: tu as la possibilité d'utiliser des tag NFC pour encoder les URLs ; je pense que les téléphones modernes ont des lecteurs NFC (chez Apple c'est verrouillé sauf pour les applications officielles lol) un autocollant et hop tu peux retrouver à qui appartient l'objet. Je sais qu'il est possible d'imprimer des stickers avec un NFC intégré … tu peux ptêtre en re-vendre sur ton site ou faire un prix qui comprend l'abonnement + 10 stickers ?

MPD n'est pas parfait mais c'est pareil sur tout les player audio:

seule la musique en cours sur la radio active est connaissable. À priori: impossible de connaître la piste jouée sur une autre radio sans switcher.

En fait ce serait possible en faisant un poll sur toutes les radio de ta playlist pour récupérer les infos. Mais il faut qu'il y ait des métadata sur le stream, et par exemple pour les streams mp3 il n'y en a pas.

de ce que je sais, il n'est pas possible d'avoir la durée d'un titre joué par une radio. Du coup, si ce titre nous saoule particulièrement (j'en ai plusieurs en tête), il n'est pas possible de savoir quand on "pourra" revenir sur la radio.

De même, ça dépend des metadata sur le stream quelque soit le player si pas de métadata pas possible de savoir le temps restant du morceau joué actuellement.

Si tu as mplayer tu peux tester tes radios avec: mplayer -slave -playlist http://... et voir les metadata qui sont diffusés.

Haha ! non ne perd pas de temps, gmpc n'a pas changé depuis … 2011 =D je pense qu'il va lui aussi disparaître mais c'est pour le moment la seule bouze utilisable que j'ai sous la main. Beaucoup de clients MPD ont l'air de tomber dans les limbes alors que MPD continue son chemin =). Mais comme tout est cotés serveur, je ne m'inquiète pas trop du client. Le concept de MPD est génial, mais les clients sont souvent bien foireux =(

J'ai bien lu et relu la dépêche et j'ai parcouru le site avant de poster. Je te remercie pour ton 2° post, je comprend mieux l’intérêt, surtout dans le cas des user-agents, problème que je n'ai jamais rencontré. Tu as un exemple ? je suis curieux de tester =D

Je sais pertinemment que l'intégration dans les différents wm/desktop est une affaire de détail et requiert beaucoup de travail (surtout quand tu veux en couvrir un maximum). Je ne voulais pas dénigrer ni ce logiciel, ni l'usage.

Quotidiennement j'utilise GMPC & MPD, qui sont probablement packagé dans toutes les distro GNU et BSD, le seul moment où je dois "faire de la technique" c'est récupérer les URL des streams qui m'intéresse pour les ouvrir avec GMPC et les sauver dans la playlist dédié. Et pour le moment le seul reproche que je fais à ce système c'est que les noms des radios sont foireuses mais rien de bien gênant ; et comme il recouvre les fonctionnalité de ce logiciel d'où ma surprise et ma réflexion: "A quoi bon coder un logiciel qui te faudra maintenir et packager pour N distros alors qu'il existe déjà pas mal de logiciel qui permettent facilement de faire la même chose et même plus ?" J'ajouterai même que c'est l'avantage du Libre, s'il manque une fonctionnalité quelque part tu peux proposer un patch pour l'ajouter. Mais comme tu le précises dans ton post, si ça te permet par la suite d'ajouter des fonctionnalités spécifiques aux lecteurs de radio tout l’intérêt du logiciel est là.

Donc Goodvibes s’adresse plutôt aux gens comme moi, qui préfèrent plusieurs applis spécialisées à une grosse appli généraliste. C'est vraiment une question de goût, tu peux pas faire là leçon à qui que ce soit là-dessus.

Oulah, loin de moi ces histoires de leçon, utilise et fait ce qui te plaît l'essentiel c'est d'avoir le libre choix ;-)

NB: j'ai le malheur de parfois me retrouver sous Window$ d'où l'usage de VLC et le dl de ma playlist de radio depuis un gist, dans le meilleur des mondes ça fonctionne aussi =).

Ça a l'air sympa mais ça apporte beaucoup plus qu'une bête playlist m3u balancé sur MPD/VLC/choisi ton player ?

Parce que perso je fonctionne comme ça je met sur github/framagit un gist/repos avec ma playlists de radios que j'ouvre avec mon client MPD ou VLC/Mplayer et quelque soit la machine & plateforme j'ai la radio. Pour peu que le player que j'utilise soit un minimum intégré à la plateforme ça à l'air de faire la même chose.

Je critique pas l'idée mais comme je suis flemmard (sinon j'en serai pas là lol) je trouve quand même que c'est une usine à gaz pour lire un bête stream mp3. Entendre par la que si tu crées un truc qui gère une liste de radio et qui est capable de lire un stream mp3 … t'as refait un lecteur audio. Comme tu utilises GStreamer tu dois pouvoir lire 99% des fichiers audio/vidéo qui existe et si tu fais une UI pour ton lecteur pour gérer ta liste de radio t'es à un pas d'un lecteur multimédia. Ce qui en soit court les rues quand même =) et qui sont eux-même maintenus/packagés/distribués dans toutes les distro possibles.

Bref si je n'étais pas atteint d'une procrastination aïgue et si j'avais besoin d'un player radio dédié ultra léger: j'utiliserai MPD, le binding dans le langage qui me plait pour faire un mini-client qui lui envoie le m3u du groupe de radio que je veux écouter/zapper et, un peu de folie, qui se synchronise avec mon dépôt git qui contient mes playlists =D.

Ha j'ai voulu testé sur une Debian (testing) … il me manque des dépendances et bon je me suis arrêté là ma procrastination à parlé =D bien désolé ! Très sympa comme idée en tout cas, bravo à toi.

Salut,

j'ai rapidement jeter un œil a ton code (le nom m'a fait marrer): bon on est d'accord pour une PoC c'est bien mais ça risque d'en dissuader plus d'un =D.
Mes modestes conseils (qui son mes guidelines, vous aurez surement les votres) qui pourraient t'aider:

• essaie de séparer la partie "lib" de la partie interface GTK et de la partie exécution de script pour commencer. Simplement tu peux faire un package fwomaj/ dans lequel tu crées 3 modules par exemple libfwomaj.py, cmd_scripts.py, gtk_ui.py ; En gros ça te permet si un jour tu veux faire un support en CLI d'ajouter un cli_ui.py qui utilisent tes popen de libfowmaj.py sans tout refaire.

  • libfwomaj.py : tu y mets toute tes fonctions ffmpeg, gstreamer, et mediainfo dans un premier temps, puis essaie de faire des objets et des mixin pour emballer/structurer le tout,
  • cmd_scripts.py : tu y mets la partie pour exécuter la ligne de commande (en gros ce que tu mettrais dans une fonction main (que tu n'as pas fait) ie: tes lignes 769-772) ce qui permet d'ajouter un parser, des options par défauts, bref la partie système,
  • gtk_ui.py : toute ta partie concernant gtk, décorrélée de toute ce que tu as mis dans les autres fichiers.

• pour mediainfo tu peux utiliser le wrapper python PyMediainfo https://pymediainfo.readthedocs.io/en/latest/ ça t'évite d'aller ouvrir un popen pour récupérer les infos ;)

D'une façon générale, j'aurai fait un objet Fwomaj qui lui va réaliser le binding entre la video et ton interface. Par exemple je trouverai sympa d'avoir un truc du style:

class GtkUiFwomaj(...):
    def __init__( ... ):
        ...
        self.mycheese = Fwomaj('my_video.avi')
        # puis tu initialises ton UI avec les fonctions & attributs de ton objet Fwomaj
        ...

La classe Fwomaj te permettant de récupérer les infos via mediainfo, d'initialiser ton pipeline GStreamer, de faire ta waveline le tout sans être dépendant de GTK. Par exemple ça peut donner:

# Par exemple pour charger un nouveau fichier
    ...
    def on_load_file(self, widget, filename):
        """ Load a file, either at startup or later. """
        delete self.mycheese                 # some cleanup
        self.mycheese = Fwomaj(filename)     # our new file
        ...

A vérifier mais ce genre de truc te permet de virer le fichier png de ta waveline quand tu delete l'objet par exemple. Au niveau des UI faire le nettoyage c'est souvent le bordel, même si au départ je n'ai qu'une ligne, je fais une fonction ui_cleanup(…) en prévision du futur (NB: tu peux aussi t'en servir à l'init pour être sur d'avoir quelque chose de cohérent entre les états/variables/éléments de ton UI).

Ou encore ta classe WForm avec cette tête:

class WForm(object):

    @classmethod
    def execute(cls, cheese, wbox, style_provider, spinner, label):
        ## ici cheese est un objet Fwomaj
        ...
        label.set_text(' Generating WaveForm image for {}... '.format(cheese.name)
        unique_file = os.path.join(tempfile.gettempdir(), 'fwomaj-{}.png'.format(time.time()))

        # on fait la waveline
        cheese.do_waveline(unique_file)

        # la suite qui elle dépend des GObject
        ...

C'est simple à comprendre, ça t'évite d'aller mettre en global ta commande, même si tu caches un peu la misère dans une classe =D.

Bref mes 2 copecs si tu as envie d'y re-travailler dessus pour l'améliorer. =)

Salut,

le temps vérifier, j'ai eu un doute sur dash, je me suis souvenu avoir changé et j'ai fait erreur: j'utilise bash + terminology .

Sinon j'avais 15 mn à passer je peux te dire que ça vient du commit 5b1eaf7 ligne 1434:
la boucle du $(sensors -u | sed …) dure environ 1scd sur ma machine ! Le sensors -u prends systématiquement 970ms.

Bref, ça ne vient pas directement de liquidprompt =). La version 1.10, sensors désactivé est à 36ms, la version 1.9 était a 38ms (avec les sensors …) =D !

Depuis quelques temps j'ai des problèmes de lenteur sur la branche master de liquidprompt. Je n'ai pas ce problème avec la version 1.9. J'ai testé en 1.10 … c'est lent ! plus d'1 scd pour afficher le prompt. J'utilise dash dans un xterm, bref rien de très spécial je pense.

J'ai vérifier la configuration, j'ai très peu de fonctionnalités activées. Pour l'instant je suis resté en 1.9.

Pour moi c'est de la 3D, puisque tu as un effet de perspective. La "3D calculée" après la rastérisation c'est une image. Alors que tu ais une image pleine de sprites ou une image calculée ça crée un effet de perspective et c'est ce qu'on appelle "3D".

Donc en résumé à mon sens :
- 2D -> galaxian, pacman, etc
- 3D -> tout le reste avec une perspective même merdique

La 3D de Quake c'est aussi une perspective (et la perspective conique de Doom alors ?!), l'effet de perspective qu'il soit calculé de manière dynamique ou prédéfinie par des glyphes n'est finalement qu'une perspective, et dans OpenTTD c'est une perspective dites "isométrique".

Bref si tu qualifies la perspective je pense que parler de 3D-isométrique c'est pas mal, en 2D-iso c'est un galaxian =D

Vraiment intéressant, dommage qu'il ne soit pas tactile =) ça aurait été une super alternative à une tablette puisque ici on aurait un clavier intégré !

Mais vu le prix ... c'est moitié le prix d'une Archos 10" ! Ça se réfléchis au moment de l'achat.

On peut aussi s'en servir pour procrastiner justement =D : "je ne travaille pas pendant 10mn ... ho ben mince pourquoi s'arrêter de ne rien faire ?!"

Personnellement je suis un peu dans l'autre extrême, quand je commence à bosser je lève la tête quand mon estomac crie pitance ... et j'utilise différent timer sur des tranches de 2h O_o, il faut que je rajoute ce gadget pour ne pas bosser entre mes tranches de travail. Double avantage, ça évite de s'éparpiller et ça repose la tête =D