nud a écrit 896 commentaires

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 ?

Oui, c'est cela.

PS. La catégorie théorique de ce ticket de suivi est bien entendu "CSS" et non "Administration"

Toujours en développement, mais les devs ne sont pas très portés sur l'édition et la mise à jour de sites web...

> on se tape toujours des dépendances lourdingues (gnome-vfs2, etc...)

gnomevfs en particulier n'est pas vraiment "lourdingue", il est le pendant "glib" de kioslave... et est donc un plus appréciable pour un programme comme inkscape qui peut dès lors ouvrir des fichiers distants, comme un fichier svg sur un site web. C'est un gros manque de Gimp, imho.

Dans les distributions à base de debian (donc ubuntu compris), y'a un machin pour définir les applis préférées, et sous debian c'est gnome-text-editor qui est appelé (basiquement, c'est un symlink, mais je ne me souviens plus du prog de debian en question...

Bon, à la base, cette phrase était une blague, vu que j'ai écrit le billet sur gedit lié dans l'article.

Mais sinon, je trouve certaines de ces idées intéressantes (notamment la tabulation mixte). 'vais voir ce que je peux faire.

Pour la puissance de la coloration, ça devrait être mieux avec gtksourceview 2, qui devrait être prêt pour 2.16.

Je ne sais pas si ce que tu veux (ne pas utiliser gedit par défaut) est possible en l'état mais tu peux toujours remplir un bug.

Pour supprimer une affectation, tu peux aller dans les propriétés d'un fichier et aller sur l'onglet "open with". Il y a un bouton "remove" qui vient à point nommé (il n'est par contre pas possible de les enlever tous, je n'en connais pas la raison)

Mais, pourquoi ne pas utiliser gedit ? :D