nud a écrit 906 commentaires

Même si ce "truc" marche, il faut quand même le maintenir, le mettre à jour pour supporter les nouvelles APIs, tester voir s'il fonctionne toujours après les modifications apportées à d'autres endroits du programme, etc.

Sinon si on veut garder toutes les API disponibles pendant toute la vie du produit, on arrive à un truc comme OpenOffice qui a vraiment les fesses lourdes (c'est pas pour rien que les petits gars de LibreOffice ont commencé par un nettoyage du code)

And the obligatory example, for inspiration:
http://www.0d.be/2007/07/01/introducing-mrcut/

Avec gstreamer tu dois pouvoir faire ça pas trop difficilement en python.

• tu as filesrc / filesink qui permettent de lire et écriredes fichiers
• tu as 150 décodeurs et encodeurs différents (vorbisenc, oggmux et all)
• tu as le plugin gnlcomposition (de gnonlin) qui permet entre autres de faire des découpes

Y'a pas mal de documentation sur comment utiliser pygst (les bindings python), et y'a du code pour s'inspirer dans jokosher ou pitivi. Y'a aussi man gst-launch qui est bien fait sur comment créer sa pipeline.

Le point négatif évidemment c'est que tu dépends d'une lib en C, mais je doute que tu trouves un équivalent en pur python qui soit un tant soit peu efficace.

Tu peux par ailleurs aussi utiliser gst-launch pour tester ou faire cela en ligne de commande. Mais si tu veux de la ligne de commande brute, tu peux aussi regarder du côté de sox.

Mais pour lire sur un écran, un commentaire, ben je préfère et de loin la première version.

Ben en fait c'est plutôt la CSS qui devrait forcer des largeurs raisonables pour le texte...

C'est le genre de trucs que tu devrais mettre dans le ticket de suivi idoine pour "référence ultérieure" ;-)

Il pourrait vouloir écrire un dialogue.

Que pensez-vous des polices utilisées ?

Trop petites

Je seconde. La taille des polices explose vraiment les yeux actuellement. Surtout que pas mal de gens scotchés plus de 8h par jour à un écran ont des problèmes de vue (moi y compris) donc autant éviter de les empirer... Une police un peu plus grande ne serait pas de refus.

Ben en fait je pense que markdown est relativement bien adapté aux gens qui veulent écrire, dans vim ou emacs, un document à mouliner ensuite pour créer du html. Avec ces éditeurs, on a de l'auto-indent, on peut afficher les "trailing whitespace", et on peut mettre un retour à la ligne après 78 caractères quand on n'aime pas le word-wrap automatique. Et au final ça donne un document dont le source est lisible et compréhensible par tout un chacun.

Ici on n'est (généralement) pas dans vi, donc on n'a pas l'auto-indentation, on n'a pas de coloration, et on a toujours le word-wrap, donc à quoi bon mettre des retours à la ligne partout ? Du coup certaines constructions markdowniennes deviennent un peu compliquées à utiliser correctement.

Les cas et contextes d'utilisation sont très différents entre un moteur de blog statique et une boite de commentaire sur linuxfr...

Je pense qu'il faut quand même différencier le cas d'un document que tu édites avec ton éditeur de texte et celui d'une textarea sur un site comme linuxfr...

Via ton ~/.vimrc tu peux rajouter des choses de ce style:

autocmd BufRead *.tpl set ft=html

L'avantage par rapport à la modeline du commentaire précédent, c'est que tu n'es pas dépendant du mainteneur pour inclure la modeline dans le repo, et tu n'as pas besoin de le faire pour chaque fichier.

Donc en résumé, on a Qt pour Android. Donc, les développeurs qui ont développé des applis pour Symbian grâce à Nokia et qui étaient désespérés de la promesse non tenue de ceux-ci de pouvoir réutiliser leurs applis sur les prochains smartphones de la marque pourront porter leurs applications smartphones sur Android. Mais jamais sous WP7 (le deal l'interdit).

C'est un peu comme cela que j'ai compris les tags au début.

Les tags "privés" seraient une bonne façon de pouvoir "bookmarquer" des trucs au sein de dlfp.

J'ai aussi quelques petits problèmes de stabilités avec nouveau sous Debian, mais apparemment uniquement en utilisant le module gallium3D libdri_nouveau.so qui est marqué EXPÉRIMENTAL partout.

Ça va se stabiliser, juste un peu de patience!

Y'a un ticket de suivi à ce sujet.

Il dit qu'il ne voit pas le rapport.

Ceci dit, un patch pour démontrer mon idée serait peut-être le bienvenu.

Je ne vois pas trop ce qui pourrait pousser quelqu'un à ponctuer son texte de retours à la lignes dans le cas particulier d'un commentaire sur linuxfr... Dans la rédaction d'un document dans un fichier .txt je comprends l'alignement sur 80 caractères, mais ici cela n'aurait pas de sens vu que la textarea est d'office "word-wrappée".

Dans ce cas pourquoi ne pas tout simplement altérer un peu le support de markdown sur ce site afin qu'un retour à la ligne soit un <br> ? Ce ne doit pas être compliqué d'altérer le comportement du parser markdown dans ce cas de figure précis. Je ne connais pas l'implémentation ruby, mais avec python-markdown c'est presque trivial.

Y a-t-il une raison profonde pour rejeter ce changemement autre que "c'est comme ça et pas autrement" ?

Ben le problème, aussi, c'est que de nos jours, le "code" quand on parle de programmes écrits en python, ruby, mono ou autre jit quelconque, ça n'inclut guère que le code de l'interpréteur et les bibliothèques C. Tes modules python seront chargés une fois en RAM pour chaque application.

En plus la dynamicité des langages modernes n'arrange rien de ce niveau. Vu qu'il n'y a (quasiment) rien qui soit read-only, il n'y a rien qui soit partageable entre plusieurs instances.

Ce qui n'empêche pas les gens de se loguer "par mégarde" via la page http://linuxfr.org, même s'ils préfèrent le https.

Par ailleurs, dans ce cas de figure, le mot de passe est-il envoyé via https malgré l'emploi du formulaire en http comme c'est le cas sur la plupart des webmails par exemple ?

Effectivement, il semblerait que ce "saut" soit lié au fait que je me suis logué en http, et ensuite je suis passé en https. Les liens sont alors en http.

J'ai réessayé en me déloguant et en me reloguant, et cela fonctionne sur les liens des dépêches de la page d'accueil.

D'un autre côté, quand je vois la liste des nouveautés du dernier Qt, il n'y a pas grand chose de lié au scope de Gtk+, càd les widgets pour des interfaces graphiques...

Apparemment, Qt recouvre également les domaines de la glib, de gio, de WebkitGtk et plein d'autres (notamment, wrappers autours de libxml et gstreamer) et l'essentiel des nouveautés annoncées dans Qt sont liées à ces autres composants.

Si l'approche de KDE est déjà sans défaut, pourquoi ne pas déjà pousser dans Freedesktop?

Parce que les mainteneurs bossent sur Gnome, que leur employeur est beaucoup plus interesse par des technos qu'ils peuvent controller a 100% et ont donc tendance a "refuser" les trucs dont ils ne veulent pas, genre en demandant quelques petites modifs, et puis encore, et encore et encore, jusqu'a ce que les mecs jettent l'eponge devant tant de mauvaise foi (demande donc a certains devs canonical ce qu'ils en pensent).

Moui bon en pratique, quand on réfléchit deux minutes, on se rend compte de plusieurs choses, notamment:

1. À la manière des éléments HTML (ou XUL, fwiw), Qt et Gtk utilisent les noms des classes. Ce serait pour le moins étrange de styler un GtkButton en utilisant QtButton dans le thème...
2. le fonctionnement de Qt et de Gtk est très différent (et accessoirement très différent de ce qu'un navigateur fait), donc les fonctionnalités supportées ne sont pas identiques et pas toujours complètement identiques avec le résultat qu'on aurait dans un navigateur. Si tu s/Qt/Gtk/ dans un thème Qt, tu peux être sûr que Gtk ne sera pas à même d'offrir un rendu correct "out of the box"
3. Je soupçonne que RedHat et les autres se contrefichent du format utilisé pour les thèmes, qui ont somme toute une portée très limitée (voir point 1). Cela n'a rien de commun avec dbus ou autres éléments plus bas dans la stack.

Pour Firefox et d'autres navigateurs, je croyais que l'objectif des prochaines releases était justement le contraire, avoir une application multi-fenêtre mais avec plusieurs processus, afin de mieux gérer un blocage dans un onglet.

Ben en fait, dans le cas de chromium (et j'imagine que firefox va faire pareil), tu as un processus qui gère toutes les fenêtres et tous les onglets, puis un processus "enfant" pour gérer le contenu de chaque onglet séparément.

Donc j'imagine qu'avec Gtk+ tu pourrais faire pareil, et qu'on pourrait avoir, imaginons, une instance "parent" de gedit pour gérer toutes les fenêtres, puis un processus par document ouvert (pas sûr que ce soit pertinent cependant)

Tu peux aller dans le système de suivi (lien dans le menu en haut à droite) et ajouter un nouveau ticket. Les gestionnaires de notre bon dlfp devraient y regarder à un moment où à un autre...

J'ajouterais même que cela casse le fil de pas mal de journaux et dépèches relativement récents dans lesquels on peut trouver au sein des commentaires des liens vers d'autres commentaires...

Dans ce cas, pourquoi ne pas utiliser un élément block, sachant qu'il s'agit de toute façon des titres des sections du menu de gauche ?