Audacity est un logiciel (GPLv2/C,C++/wxWidget) dédié "à la manipulation de données audio numériques.". Son développement est encore actif (dernière version : septembre 2013) et utilise SVN.
Cette dépêche est consacrée à un retour d'expérience sur un point précis : modifier la manière dont Audacity affiche le temps de début et de fin d'un fragment audio.
A. le problème de départ
Audacity permet de choisir le mode d'affichage du temps : par exemple, "seconds" ou encore "hh:mm:ss". Le mode le plus précis et le plus générique est sans doute "hh:mm:ss + milliseconds", dont voici un exemple :
Ces renseignements apparaissent en bas de la fenêtre principale : on voit ici que la sélection commence à 3 minutes et 291 millisecondes et s'achève à 5 secondes 155 millisecondes.
Le problème qui se pose est le suivant : certains ont comme moi besoin de lire rapidement le temps exprimé en millisecondes. Dans l'exemple ci-dessus, 00:00:03.291 est facile à convertir en 3291 millisecondes. Mais en général, il est bien plus difficile de convertir des nombres plus élevés. Ainsi, 00:57:03.291 vaut par exemple 3 423 291 millisecondes.
Comment obtenir ce résultat ?
B. les solutions
B.1. première solution : regarder ailleurs
Bien sûr il existe sans doute d'autres logiciels mieux adaptés à mes besoins (peut-être comme celui-ci) mais je voulais me faire plaisir en modifiant Audacity pour obtenir l'affichage désiré.
B.2. deuxième solution : faire appel aux membres de la communauté du libre
Il se trouve que quelqu'un a eu la même idée que moi. Comme le montre le lien, il n'y a pas eu de vraie discussion : à cette époque, l'équipe d'Audacity semblait avoir une opinion très ferme de ce qu'elle voulait et surtout de ce qu'elle ne voulait pas !
B.3. troisième solution : modifier Audacity
Je profite de cette dépêche pour reconstituer certaines étapes.
B.3.a. code source
Le code est disponible sur le dépôt SVN d'Audacity
Pour le récupérer :svn checkout http://audacity.googlecode.com/svn/audacity-src/trunk/ audacity
B.3.b. compilation
Attention, grâce au forum dédié à la compilation du projet j'ai appris que sur mon système (Archlinux) un simple ./configure ne suffisait pas, il faut y ajouter l'option --disable-dynamic-loading.
De même, l'installation de wxwidget est obligatoire (comme annoncé par la documentation) mais la bibliothèque webkitgtk2 est également requise.
… puis $./configure --disable-dynamic-loading et $make
B.3.c. lecture du code
Le fichier qui nous intéresse est src/widgets/NumericTextCtrl.cpp; il définit le contenu de const BuiltinFormatString TimeConverterFormats[] et contient donc (j'enlève les commentaires et une partie du code) :
const BuiltinFormatString TimeConverterFormats[] = {
{
_("seconds"),
_("01000,01000 seconds")
},
{
_("hh:mm:ss + milliseconds"),
_("0100 h 060 m 060.01000 s")
},
[...]
}Comme la lecture du fichier l'indique, le contenu de chaînes comme "01000,01000 seconds" est analysé : le nombre est affiché suivant le format ainsi décrit.
B.3.d. modification du code
Mon premier mouvement a été de modifier directement le mode "seconds" pour qu'il affiche en plus les millisecondes. J'écris donc :
const BuiltinFormatString TimeConverterFormats[] = {
{
_("seconds"),
_("01000,01000.01000 seconds")
},… je recompile, et j'obtiens le résultat attendu :
C. et maintenant, que faire ?
J'aimerais partager mon très modeste travail avec la communauté du libre.
C.1. problèmes à prévoir du côté d'Audacity
J'aimerais proposer un diff à l'équipe d'Audacity car la solution que je propose paraît adaptée à mes besoins. Cependant, elle souffre d'un gros inconvénient : elle contredit le nom du mode d'affichage ("seconds") : changer l'un sans changer l'autre me semble impossible pour des questions de cohérence.
L'autre solution serait de proposer un autre mode d'affichage nommé "seconds + milliseconds". Mais je crains, vu la réponse que j'évoquais précédemment, que cette demande ne soit refusée comme étant une proposition inutile.
C.2. problèmes liés à un fork
Forker Audacity et entretenir une branche personnelle ne me plaît qu'à moitié car je n'ai pas envie de devoir gérer la récupération régulière des mises à jours de ce projet.
D. conclusion
Alors, que me reste-t-il à tenter ? Si certains voient ce que je puis faire de mon travail, je suis preneur !
Aller plus loin
- Audacity (97 clics)
# Contribution
Posté par cosmocat . Évalué à 10.
Il me semble que si tu as eu besoin de cette fonctionnalité, d'autres doivent également en éprouver le besoin donc la contribuer upstream me semble une très bonne idée.
Par contre, remplacer tout simplement l'affichage existant ne me semble pas une très bonne idée.
De mon point de vue, il faudrait que tu ajoutes une option (soit dans le menu, soit dans les options d'Audacity) pour choisir le mode d'affichage.
Dans ce cas là, je ne pense pas qu'il y aurait de problème à être inclus dans le projet upstream car ça ne dérangerait personne. Le seul risque c'est que ça satisfasse plus d'utilisateurs ;)
Par contre, j'en conviens, ça demande plus de boulot…
[^] # Re: Contribution
Posté par ganymede . Évalué à 5.
En effet. Je me sers parfois d'Audacity pour éditer la piste son de petites séquences vidéo, et le mode d'affichage que tu proposes me serait utile dans certains cas.
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Bonjour, merci de ta réponse. Je pense de plus en en plus sérieusement écrire aux devs d'Audacity. Pourrais-tu me donner un cas précis où ma fonctionnalité te serait utile ?
Merci !
Trust the Python !
[^] # Re: Contribution
Posté par ganymede . Évalué à 2.
Cas d'utilisation précis :
- tu as un fichier vidéo dans lequel la piste image et la piste son sont désynchronisées
- mais tu peux déterminer exactement le décalage temporel entre les deux pistes (grâce à mediainfo par exemple)
- et tu veux traiter séparément la piste son (par exemple lui appliquer un filtre d'Audacity et l'encoder dans un certain format pour la diffuser)
Admettons que la piste audio "avance" de 1234 millisecondes sur l'image. Il peut être utile dans ce cas-là de couper précisément ces 1234 millisecondes au tout début de la piste audio, avant de l'exporter et de la remultiplexer avec l'image.
(On peut aussi faire ça "au jugé" dans un logiciel de montage, mais c'est moins précis, et le logiciel en question n'offrira probablement pas autant de possibilités pour traiter le son qu'Audacity.)
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Merci pour cet exemple que j'utiliserai en présentant mon patch à l'équipe d'Audacity.
Trust the Python !
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Bonjour, merci pour la réponse.
Avec un peu de chance, ajouter une autre option ne devrait pas être compliqué (je suis en train de regarder comment faire, confer la fin de ce message). Ce que je crains par contre beaucoup, c'est l'explication qui s'ensuivra avec l'équipe de devs d'Audacity. A part la personne que j'évoque dans mon mail et moi-même, nous ne sommes pour le moment que deux à avoir besoin d'une telle fonctionnalité. Ajoute à cela mon médiocre niveau en anglais, le fait que ça serait la première fois que je me permettrais de proposer un patch, que je n'ai pas de réputation particulière… Ceci dit, ça m'intéresserait vraiment d'essayer !
En fait, j'aimerais surtout savoir comment fonctionne ce type de demande : faut-il que j'écrive sur le forum d'Audacity et que j'y propose un diff ?
S'agissant du patch, il me paraît pour le moment assez simple : il consiste à ajouter les lignes suivantes dans la définition de
BuiltinFormatString(dans src/widget/NumericTextCtrl.cpp) :Cela crée un nouveau mode, le numéro 5. Sachant que le mode par défaut est le numéro 4
(src/widget/NumericTextCtrl.cpp::ligne 535)
mDefaultNdx = 4; // Default to "hh:mm:ss + milliseconds".
BuiltinFormatStringn'est utilisé que dans le fichiersrc/widget/NumericTextCtrl.cpp, il est possible que mon travail en c++ s'arrête là.Il resterait encore à traiter le problème de la traduction dans les différentes langues qui apparaissent dans locale/ .
Trust the Python !
[^] # Re: Contribution
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Ceci dit, la première chose à faire est d'en parler avec les développeurs d'Audacity. Tu (pas cosmocat, mais Xavier, l'auteur de la dépêche) sembles te baser entièrement sur une supposition pour ne même pas proposer un patch et t'imaginer qu'il sera rejeté de toutes façons. Alors oui il est tout à fait possible que des choses soient à revoir (ça arrive à tout le monde, dans tous les projets). Peut-être même qu'ils refuseront de but en blanc l'idée même du patch, qui sait! (je connais pas l'équipe d'Audacity ni s'ils sont arrangeants, ou braqués par exemple)
Mais tout ça t'en sauras rien si tu demandes pas. Va y humblement et diplomatiquement avec ton patch, et sois prêt à recevoir les critiques (s'il y a lieu, ça se trouve, ils le trouveront même bien tel quel, qui sait!) et améliorer le patch en conséquence. Et cela ira probablement.
Ceci dit, petit avis perso: ajouter des millisecondes ne me semble pas contredire le nom de la fonction "secondes" à ce point selon moi. Les millisecondes sont une variante (ou une subdvision) de l'unité seconde. Je ne vois pas de contradiction.
Mais peut-être que les dévs d'Audacity verront les choses autrement, j'en sais rien. Et dans ce cas là, ajouter une option peut en effet être une autre possibilité (ou encore changer le nom de la fonction). Et franchement je vois déjà une dizaine d'option pour l'affichage du temps, je doute que les dévs upstream aient un gros problème si tu souhaites en ajouter une avec une bonne raison (et tu en as une). Mais cela, je te conseille de voir cela directement avec les dévs du projet. Pas la peine de perdre ton temps pour du code qui sera pas pris.
Perso ma manière de travailler est la suivante quand je veux une fonctionnalité: je fais la base dans mon coin, car ça me sert de "preuve de concept", donc ça illustre bien mieux ce que je veux que du texte dans une requête de fonctionnalité, et surtout les dévs du projet me tiennent au sérieux dès le début car ils ont un patch à se mettre sous la dent et donc ils répondent beaucoup plus vite. Ça c'est ce que t'as fait et c'est très bien.
La seconde étape est de proposer ton patch de base une fois qu'il est un peu propre. Et à partir de là, la discussion avec upstream peut commencer et c'est le moment où tu fignoles, et où tu auras peut-être des concessions à faire en effet, ou bien du code à ajouter ou changer pour aller dans le sens du projet tout en intégrant ta nouvelle fonctionnalité intégralement.
Et quand c'est fait, le projet upstream est content et intègre ton patch. En général les projets sont contents d'avoir de nouvelles contributions. Ils espèrent même que les contributeurs restent et proposent plus de patchs à l'avenir. Faut pas croire mais la plupart des projets (même certains qui ont l'air gros, car connus à une certaine échelle) ont très peu de contributeurs. Je pense donc que tu as toutes tes chances.
Reste pas là sur linuxfr à piétiner et à te demander si oui ou non ils intègreront. Va direct sur leur logiciel de suivi, et donne ton patch. S'ils répondent pas vite, n'hésite pas à lancer un petit message sur la mailing list par exemple (ou autre de leurs canaux habituels de discussion, par exemple s'ils ont IRC), poliment et gentillement (genre "hey I submitted a patch a few days ago, would someone be kind enough to review it? I'm happy to change things if there are issues", un lien et quelques petits smileys bien placés). Et tout ira bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Merci de tes conseils et du ton très sympathique de ton message.
Je me suis donc lancé en coupant la poire en deux : j'ai posté dans le forum "Adding Features to Audacity" une analyse très semblable à celle que je donne dans linuxfr.
Advienne que pourra !
Trust the Python !
[^] # Re: Contribution
Posté par gasche . Évalué à 9.
Non, ça n'est pas une bonne solution. Les développeurs ne suivent pas forcément tous ce forum, et même s'ils le suivent ils vont vite voir ton message et l'oublier ensuite (s'ils sont un tant soit peu chargés en travail par ailleurs). La seule façon de t'assurer qu'ils traitent ta demande est de suivre le format qu'ils proposent pour leur envoyer des contributions.
(Je suis contributeur occasionnel sur un projet libre et quand des gens postent un patch sur la mailing-list ou un forum X ou Y, on doit passer leur dire qu'il faut le mettre sur le bugtracker comme demandé car sinon on va oublier tout simplement.)
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Merci de ton commentaire, que j'ai "plussoyé". Je me permets de ne pas être totalement d'accord : pour quelqu'un comme moi qui cherche à comprendre l'envers du décor et le processus de décision, le thread que j'ai créé est riche d'enseignements.
Une fois que je comprendrai mieux comment les décisions sont prises par une communauté de développeurs, je passerai directement par l'envoi d'un patch, comme tu le recommandes.
Trust the Python !
[^] # Re: Contribution
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je suis d'accord avec gasche. Je suis de nombreuses mailing list, mais "de très haut", c'est à dire que de temps en temps, je jette un œil et vais répondre à 3/4 messages dans les derniers messages, ceux qui m'ont l'air le plus pertinent. Mais je sais que j'en aurai passé plein. Ce n'est pas grave, c'est le format des mailing lists (et les forums, c'est pareil): des discussions qui passent, s'éteignent, puis à un moment disparaissent dans des archives. D'ailleurs il m'est aussi arrivé très souvent de commencer une discussion à laquelle personne ne répond jamais et elle passe dans l'oubli. Je ne m'offusque pas. C'est le format attendu, comme j'ai dit.
Les outils de suivi, c'est un format totalement différent: un ticket ouvert y a 10 ans, mais que personne n'aura trouvé irraisonnable (mais qui n'a pas eu de résolution dans le code pour autant) sera encore en haut de la liste 10 ans après. Une entrée de suivi n'est oubliée que le jour où on décide soit que c'est une fonctionnalité inutile, soit qu'il y a une résolution (= patch).
Ensuite il y a des projets qui privilégient forums/mailing lists comme lieu de décision, et là c'est différent. Mais ça reste l'exception.
Soit dit en passant, j'ai jeté un œil au fil de discussion que tu donnes (au passage, le bon lien est: http://forum.audacityteam.org/viewtopic.php?f=20&t=82163 L'option finale du lien que tu as donné semble vouloir me forcer à entrer un login). J'ai l'impression qu'aucun des dévs ne t'a répondu, celui qui semble répondre le plus, Edgar, ayant l'air extérieur à l'équipe core d'après les termes qu'il choisit. À le lire, il semblerait qu'il ait lui-même des patchs perso et n'a jamais fait l'effort de les proposer.
Donc je vois pas quel enseignement tu peux en tirer, et surtout comment tu aies pu comprendre quoi que ce soit de "l'envers du décor". Tu restes du côté spectateur. Encore une fois, tu n'obtiens que des "on dit". C'est donc surtout du vent.
À un moment donné, il faut passer dans la cour des grands. Et c'est comme à l'école: une fois que tu y es passé, tu te rends compte que les "grands" ne sont pas différents des "petits" et qu'il n'y avait en fait aucune raison d'avoir peur. Les autres grands (car tu en es devenu un aussi à ce moment là) sont les mêmes, ils ont simplement changé de cour. Donc laisse tomber les "on dit", et essaie de soumettre ton patch plutôt que d'écouter un mec qui vraisemblablement n'a jamais essayé de changer de cour, même s'il avait les bonnes billes pour le faire.
Une fois que tu auras vraiment discuté avec les dévs, acteurs d'Audacity, là tu auras un aperçu de "l'envers du décor".
Au passage, vous pointez dans le fil de discussion la problématique de la longueur du menu quand on ajoute trop d'options. Voilà une bonne problématique en effet. Il n'est proposé qu'un dialogue comme seule alternative. Mais il y a mieux en fait: personnalisation totale du format. Par exemple, une liste assez limitée peut être donnée, mais avec la possibilité de personnaliser exactement le contenu avec une syntaxe custom. Par exemple il est classique d'utiliser une syntaxe dérivée du format de printf. Par exemple %h %m %s pour heure/minute/secondes. %S pour seconde avec décimales (donc on a les ms derrière la virgule), %M pour millisecondes, %f pour les frames en 24fps, etc. Donc l'utilisateur entre le format qu'il souhaite, il peut même avoir un mix de pleins d'infos en même temps s'il le souhaite, pourquoi pas!
Ce type de personnalisation permet simplicité (avec une liste de petite taille des usages les plus courants) + usage avancé (avec un format pour obtenir exactement ce que tu souhaites en tant qu'utilisateur avancé).
Peut-être peux-tu leur proposer quelque chose dans ce sens s'ils refusent ta première version de patch. Mais dans tous les cas, même là on s'avance trop. Dans un premier temps, envoie ton patch et parle avec les intéressés! Plus de "on dit", plus de "et si".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Merci d'avoir regardé le thread que j'ai créé sur le forum d'Audacity.
Tant que je n'aurai pas franchi le pas, je ne pourrai pas en effet connaître l'envers du décor. Mais en attendant, essaie de te mettre à ma place : je découvre peu à peu comment contribuer à des projets libres, rien dans mon environnement de travail ne m'ayant permis de faire ces découvertes. Je pars presque de zéro s'agissant des patchs, des listes de discussions consacrées au développement d'un logiciel. Qui plus est, je n'ai quasiment personne à qui parler de mon intérêt pour le logiciel libre : là où je vis, il y a probablement davantage de vaches que d'êtres humains. Voilà pourquoi j'avance pas à pas.
Le fil de discussion que j'ai initié m'a permis de comprendre que mon patch avait des répercussions imprévues, notamment sur l'UI. Je suis d'ailleurs surpris que personne n'ait abordé dans le thread le problème des fichiers .po (i18n) dont la mise à jour doit être lourde.
Pour conclure, je me range à ton avis et vais proposer un patch "comme un grand", peut-être la semaine prochaine.
Trust the Python !
[^] # Re: Contribution
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Très bien. :-)
Ensuite oui tu peux t'attendre à des rejets parfois (sur ce patch ou un autre), des incompréhensions, etc. Mais règle numéro 1: ne jamais le prendre mal, ni personnellement. Aussi il faut être prêt à revoir ton code.
Il n'y aussi aucun mal à insister un peu, mais toujours poliment et amicalement. Ça m'est déjà arrivé des fois d'avoir des patchs rejetés et le ticket fermé, et je le rouvre avec un commentaire expliquant davantage pourquoi j'estime que c'est important et que je suis prêt à modifier le patch pour m'adapter aux besoins et corriger les problèmes, des fois avec un nouveau patch si je sais déjà quel problème ont les dévs upstream avec mon premier patch. Et des fois, ça marche et ils acceptent l'idée évoluée.
Par exemple dans ton cas, peut-être qu'ils te diront effectivement qu'il faut une nouvelle option. Dans ce cas, tu dis que tu vas rééecrire sous la forme d'une nouvelle option. Peut-être qu'ils te diront que la liste des options est trop longue. Dans ce cas, dirige les vers le lien du forum avec le gars qui pense qu'il faut plein d'options, et tu peux aussi dire que tu as eu des retours d'utilisateurs qui ont dit que ton option particulière serait très utile, cela peut créer une discussion pour revoir la façon dont cette liste est présentée (comme je disais, je vois très bien un système de format pour que tout un chacun puisse créer son timing personnalisé).
Si on te répond pas vite, faut pas prendre mal, tu peux d'ailleurs te permettre de relancer de temps en temps (pas trop, attend quelques semaines entre les relances). Ça veut aussi dire que de ton côté aussi, rien ne presse. Personne ne t'en voudra si tu mets un peu de temps à répondre, et tu peux prendre tout le temps nécessaire pour rechercher le code et écrire proprement tes nouvelles versions de patch.
Au final la contribution au Logiciel Libre, c'est un peu une leçon de zen. Il faut essayer de jamais s'énerver (des fois, c'est dur), de ne rien prendre personnellement, de prendre son temps et être persistant en même temps. Et un jour, tu te rends compte que tout va bien en fait. Ces mecs en face, ils sont comme toi. Ils n'avaient rien contre toi ni ta fonctionnalité, ils avaient juste du mal à la comprendre.
Tout cela dit, peut-être au contraire que ta fonctionnalité va leur plaire et qu'ils l'accepteront d'entrée de jeu sans aucun problème. Je veux juste te préparer au "pire" parce que je sais que les premiers patchs rejetés peuvent être démoralisants quand on ne connaît pas encore. Ça peut arriver. Mais si t'es sûr de ton idée, hésite pas à revenir à la charge en proposant des alternatives. Des fois même après un an ou 2 s'il le faut, il arrive que les dévs revoient leur jugement (et en attendant, tu utilises ta version patchée juste pour toi).
Ou alors si tu te mets à proposer d'autres patchs régulièrement, tu deviendras peut-être toi-même core dév d'Audacity, et dans ce cas tu auras plus de poids pour reproposer ta modif plus tard. :-)
Tout est question de patience.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Contribution
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Super ! Merci de me donner toutes ces précisions.
Trust the Python !
# Faute de frappe
Posté par myahoo . Évalué à 3.
Ah non, plutôt 3 423 291 millisecondes !
Ou effectivement 3 423,291 secondes ;-)
[^] # Re: Faute de frappe
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 3.
Corrigé, merci !
[^] # Re: Faute de frappe
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Oops, merci.
Trust the Python !
[^] # Re: Faute de frappe
Posté par teoB . Évalué à 3.
Autre erreur :
Ça a plutôt l'air d'être 3 secondes et 291 millisecondes.
[^] # Re: Faute de frappe
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Oui, évidemment. Merci d'avoir remarqué l'erreur.
Trust the Python !
# "Demande de feature" et "patch" c'est très différent
Posté par gasche . Évalué à 6.
Mets-toi à la place des développeurs. Une demande de feature, c'est une demande directe qu'ils s'ajoutent un truc à faire. Quand tu es surchargé, le truc naturel est de trouver une raison X ou Y pour justifier que c'est inutile, fermer le rapport d'erreur et voilà, tu as diminué ta charge de travail avec succès.
Un patch, c'est quelqu'un qui a fait l'effort de travail sur ton logiciel et qui, si on est gentil, pourrait même continuer à le faire et devenir un contributeur ou une contributrice occasionelle dans le futur (et diminuer notre charge de travail !). C'est donc à traiter par diplomatie. En particulier, si :
On est très facilement disposé à accéder à sa demande.
Si le point (1) flanche (le code n'est pas comme on veut), on répond un message pour expliquer ce qui est à améliorer. Ça ne veut dire "oui" ni "non", mais "essaie encore".
Le point le plus important est (3): si tu as besoin de voir les millisecondes il faut expliquer pourquoi, si possible en des termes concrets. J'ai besoin de pouvoir m'imaginer l'utilisateur à qui ça rend la vie meilleure pour me convaincre qu'il existe.
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par gasche . Évalué à 4.
J'ai oublié de commenter le point (2): ce n'est pas forcément une bonne idée de modifier une feature existante, à moins de pouvoir s'assurer que tous les utilisateurs de la feature seront satisfaits. Si tu veux que ton changement soit accepté, il me semble beaucoup naturel de faire de ton besoin un mode d'affichage des temps supplémentaire.
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Merci encore une fois de ces commentaires, que je trouve frappés au coin du bon sens. Ce que tu ajoutes sur le point (2) est d'autant plus intéressant que cela rentre en conflit avec l'ergonomie de l'interface : plus l'on ajoute de "formats de temps", plus la liste à tendance à déborder de l'écran (voir à ce sujet le thread que j'ai ouvert ici). Je ne sais donc pas comment convaincre de l'intérêt de "mon" format de temps alors que d'autres pourraient être en effet proposés.
Trust the Python !
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par zurvan . Évalué à 2.
Le point le plus important je pense, c'est de pouvoir rajouter une option pour basculer d'un mode de vue à l'autre. Tel que tu le présentes dans ce journal, ta modification est un changement unilatéral du mode d'affichage dans Audacity.
En tant qu'utilisateur de ce logiciel, ça ne me dérangerait pas d'avoir la possibilité de passer temporairement l'affichage en secondes (je pourrais même l'utiliser), mais ça me dérangerait beaucoup de n'avoir plus que ce mode à la place des heures, minutes, secondes.
Certains logiciels modifient d'un seul coup une manière de faire, par exemple gimp a subitement décidé que la fonction "enregistrer" ne permettait plus d'enregistrer en jpg ou png, il faut "exporter" (pour protéger l'utilisateur de sauvegarder dans un format avec des pertes d'informations), sans possibilité de modifier cela, c'est pénible…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Merci de ton commentaire mais je ne comprends pas pourquoi tu crains
Je propose ou bien de modifier un mode existant (123 seconds -> 123.456 seconds) ou bien d'ajouter un nouveau mode (seconds + milliseconds).
Nulle part je ne veux imposer ce mode
Peut-être ai-je mal exposé ma proposition ?
Trust the Python !
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par zurvan . Évalué à 2.
je ne sais pas, mais dans les copies d'écran que tu proposes, on voit un mode avec h:m:s.ms à l'origine, et un mode avec uniquement des secondes + ms (par ex 115.330) et si parfois on peut souhaiter voir 115 s, souvent on peut préférer lire 1m55s
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par Xavier Faure (site web personnel) . Évalué à 3.
En effet, mais ces captures d'écran sont à replacer dans le contexte de l'UI d'Audacity : en cliquant sur le mode pour le choisir, le logiciel fait apparaître une liste d'une dizaine de modes différents. Je propose ou bien d'étendre l'un de ces modes ("seconds" -> "seconds + milliseconds") ou bien d'en ajouter encore un autre. Dans tous les cas, l'accès aux modes reste identique.
J'espère avoir été plus clair ! A moins que je n'aie pas compris ta remarque ?
Trust the Python !
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par zurvan . Évalué à 2.
aaaah oui, je n'avais pas remarqué. Donc oui, ok en ce cas ton amélioration fait sens.
En 10 ans d'utilisation d'audacity, je n'avais jamais percuté qu'on pouvait changer ça (ou si je l'avais trouvé il y a longtemps, je n'ai jamais eu besoin de le modifier)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Autre solution de patch
Posté par freem . Évalué à 7.
Bon, désolé d'avance si l'affichage est foireux, je ne sais pas comment citer un passage incluant un bout de code.
Perso, quand j'ai vu le code, je me suis dit: "Tiens, des magic values. Et l'OP semble avoir besoin de recompiler pour les altérer? Dommage…".
Je m'explique. Modifier une magic value, ça permettra de satisfaire ton besoin immédiat, mais demain quelqu'un aura peut-être besoin de faire un truc encore différent (j'y connais que dalle en multimédia, alors je peux me tromper). Si à chaque fois il faut recompiler… je trouve ça gênant.
Ne serait-il pas faisable, en revanche, d'aller récupérer les informations dans un fichier de configuration? Dans le cas présent, il s'agit d'un ensemble de paires de string, contenant pour chacune le nom du mode d'affichage, et la description du format qui lui est associé.
Je ne connais pas l'état du source, si c'est propre ou pas, comment est gérée la configuration (base de données lourde? XML? Répertoire contenant divers fichiers de configuration de petite taille? Utilisation de la classe de gestion de la config de wxwidgets?) donc ce n'est peut-être pas aussi trivial que ça, mais si tu hôtes d'un bout de code des constantes magiques, en expliquant ton besoin d'origine et le fait que du coup, cette modification permets de gérer d'une part ton besoin, sans rien détruire, et qu'en plus les éventuels autres besoins liés à cet affichage seront gérés sans modification du source, j'imagine mal le patch être mal reçu par les dev.
En fait, de base, je vois mal des patch améliorant une fonctionnalité déjà présente être rejetés, contrairement à des demandes de fonctionnalités, comme déjà indiqué dans un autre fil par quelqu'un d'autre.
PS: c'est sûr que les dépêches ont une meilleure visibilité, mais, en fait, c'est une entrée de forum que tu nous as fait non?
[^] # Re: Autre solution de patch
Posté par Xavier Faure (site web personnel) . Évalué à 1.
C'est en effet une excellente idée à laquelle je vais réfléchir : le code permet à mon avis de stocker facilement ces formats dans un fichier "à part". Par contre, cela doit poser un problème pour l'internationalisation : comment traduire des strings stockées dans un .xml ? gettext le permet-il ? Je n'ai pas la réponse.
Et oui, au départ il ne s'agissait que d'une entrée de forum : l'équipe de modérateurs s'en est mêlée et m'a demandé d'être plus "ambitieux", pour mon plus grand plaisir.
Trust the Python !
[^] # Re: Autre solution de patch
Posté par freem . Évalué à 4.
Je ne sais pas si gettext permets de gérer ça, par contre il ne me semble pas déconnant d'imaginer d'utiliser gettext pour savoir quelle locale est utilisée, et d'aller piocher dans le bon dossier les fichiers de DATA. C'est peut-être un peu plus manuel, mais je t'avoue, je n'ai jamais utilisé gettext.
Sinon, me semble que l'on peut récupérer la locale avec les fonctions standard en C++ moderne. Je ne m'en suis jamais servi non plus, ceci dit.
# Les pull request de Github
Posté par martindelille . Évalué à 4.
Bonjour Xavier,
Je suis le développeur de Joker que j'avais présenté ici il y a quelques jours. Alors tout d'abord, Joker et Audacity sont deux logiciels au fonctionnalités différentes:
- Audacity permet de lire et d'enregistrer de l'audio en multipiste
- Joker permet d'afficher l'image et le texte (sous forme de bande rythmographique), asservi par unn autre logiciel via un protocole de synchronisation comme le midi timecode par exemple.
Un jour Audacity et Joker pourront fonctionner ensemble mais il faudrait ajouter un protocole de synchronisation à Audacity (le midi timecode dont je parle semble une bonne piste).
Sinon concernant ta contribution, je ne sais pas ce que vous en pensez ici mais je ne saurais que trop te conseiller de passer par Github car le projet est versionné dessus: https://github.com/synergy/synergy
Github intègre un mécanisme de gestion des contributions (pull request) très puissant qui facilite la communication entre le contributeur et le développeur upstream. Voici des exemples de pull request sur Joker: https://github.com/Phonations/Joker/pulls
Comme tu peux voir, cette vue présente l'historique des commits de la contribution, le diff des fichiers, la possibilité de merger automatiquement le code ou la présence de conflits, le status des builds Travis pour l'intégration continue qui permet de vérifier que le projet compile toujours et que les tests unitaires réussissent.
Enfin concernant ta modification, c'est intéressant de modifier l'affichage, car personnellement je trouve qu'il manque une façon d'afficher le timecode dans Audacity quand on travaille avec des éléments vidéos (comme dans le doublage) et la représentation HH:MM:SS:FF manque cruellement.
A ce sujet, cela pourrait être intéressant de développer un module de gestion du timecode commun entre Joker et Audacity, LibLTC et Ardour. J'ai de mon côté implémenté les mécanismes calculatoire des principaux framerate, et je dispose d'une suite de tests unitaires qui pourrait faire une bonne base, mais bon là je m'emporte et je suis un peu hors sujet par rapport à l'objet de cette dépêche :-)
[^] # Re: Les pull request de Github
Posté par Xavier Faure (site web personnel) . Évalué à 1.
Merci de ton commentaire : je note tout ce dont tu parles et je me servirai de ton post quand je proposerai le patch pour appuyer ma demande.
Ce que tu dis sur GitHub est bien sûr très intéressant mais je préfère m'en tenir à la manière officielle de proposer un patch, à savoir la mailing-list (cf le post d'Edgar dans le thread dont je donne l'adresse).
Et bravo pour Joker ! :)
Trust the Python !
[^] # Re: Les pull request de Github
Posté par TML . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.