tgl a écrit 1743 commentaires

Bah je propose pas de le faire sur tout l'historique de GTK2 non plus, mais disons que juste sur ce qui est nouveau dans la 2.x par rapport à la 2.x-1, ça n'aurait rien d'immonde. Je viens de faire un diff entre les headers 2.6.10 et 2.8.3, et si tu ignores les changements cosmétiques style en-têtes ou nouvelles macros pour remplacer des vieux copier-coller, il te reste en moyenne en gros un, parfois deux, chunks par fichier où tu as les vraies nouveautés de l'API. Mettre ces chunks là dans des "#ifndef PRETEND_TO_BE_GTK26", je pense pas que ça tuerait la lisibilité...

Ce qu'il faudrait en fait, ça serait des #ifndef un peu partout dans les headers de GTK qui permettrait de masquer les nouvelles fonctions de chaque version, histoire de pouvoir sur un système avec Gtk 2.6 vérifier qu'on a bien codé en compatible 2.4 par exemple.

Ici (GNU tar 1.15.1) c'est stdin/stdout par défaut, sans "-f -". Par exemple, je peux copier un fichier toto.txt vers /tmp comme ça :
% tar -c toto.txt | tar -x -C /tmp
(et puis c'est aussi ce que me dit la page man)

J'ajouterais que :
- si tu compiles toi même tes noyaux, alors il faut vérifier que c'est activé, ici : File systems --> Ext3 journalling file system support --> Ext3 extended attributes. (pareil pour ext2 d'ailleurs) ;
- si tu utilises un kernel de distrib, il est extrêmement probable que ce soit déjà activé ;
- dans tous les cas, il faut passer dans ta fstab l'option qui va bien, "user_xattr", pour ta partition /home (ou carrement / si tu n'as pas de /home).

Tiens, un petit coup de Google me donne des éléments supplémentaires sur la typo, que je ne connaissais pas : la longueur de l'acronyme d'une part, et son usage comme un nom commun d'autre part.
http://correcteurs.blog.lemonde.fr/correcteurs/2004/12/sigles_et_ac(...)

Ainsi, Le Monde écrira « SUD » pour le syndicat (acronyme de moins de 5 lettres), mais « Unesco » (plus de 5 lettres). Ils écriraient donc aussi « Gnome » a priori.
D'autre part, ils écriront « sida » ou « ovni » sans capitale au début, parce que c'est devenu de véritables noms communs.

Bon après, je sais pas trop là dedans ce qui est de l'ordre de la règle typographique, et ce qui est de l'ordre de la convention propre à ce journal.

> les acronymes qui se prononcent

Je peux dire une bêtise, mais il me semble que « acronyme qui se prononce » est un pléonasme. Je crois que le termes générique pour désigner ces machins à bases d'initiales, c'est « sigle », et que les acronymes eux sont justement les sigles qui se prononcent. Bref, GNOME serait bien un acronyme, et KDE juste un sigle.

Après, sur la typo, les seules règles formelles, il me semble, sont qu'on ne met pas de point entre les lettres d'un acronyme, et qu'on n'utilise que des capitales pour les sigles qui s'épellent. Mais l'utilisation de minuscules dans les acronymes, comme celles des points pour les sigles non prononçable, est plus une question de goût (la tendance moderne étant à « Gnome et KDE », et celle un peu désuette mais toujours correcte à « GNOME et K.D.E. »).

Enfin bref, à confirmer tout ça...

> C'est encore et toujours le principal défaut d'Ubuntu...

C'est à dire ? Elle le supporte mal, ou bien au contraire elle l'impose ?

> je ne connais pas le titre français

"Conversation secrète" si ma mémoire est bonne.

Bêta ? Nan, quand même pas... La quasi totalité des paquets sont maintenant en 2.12.x, et les quelques uns restant sont au pire ceux de la dernière RC. Pour suivre l'activité autour de cette release, tu peux surveiller ce meta-bug :
https://bugs.gentoo.org/show_bug.cgi?id=103197(...)
Tu verras qu'il n'y a pas franchement de problème majeur d'ailleur, c'est vraiment juste des petites choses à paufiner.

Ceci dit, ça ne veut pas dire que ça va arriver tout de suite en ~arch... Le gros problème, c'est que Gnome-2.12 nécéssite des mises à jours sur quelques paquets importants qui ont changé d'API dans leurs versions récentes (dbus et hal principalement, et puis cairo aussi), et que d'autres paquets non-Gnome en ont encore besoin dans leur vieille version. Donc en un peu violemment résumé, Gnome-2.12 sera démasqué quand KDE y sera prêt...

"find /ton/répertoire -mtime 28 -exec rm -f {} \;" devrait effacer tes fichier vieux de plus de 4 semaines.

Sinon, tu peut toujours regarder du côté de tmpwatch ou tmpreaper, qui sont deux programmes spécialisés dans ce genre de nettoyage (enfin, ça devient intérressant surtout pour nettoyer une arborescence, y compris les sous-répertoires, mais dans ton cas find fera bien l'affaire).

Merci, ce "smeg" fait parfaitement ce qui me manquait. J'ai patché gnome-panel pour qu'il l'utilise plutôt au lieu de gmenu-simple-editor, et tout de suite cette action "Edit menus" devient bien plus utile.

Mon utilisation est en effet principalement d'enchainer simplement des albums ou des bouts d'albums, oui. Pour les trouver, je trouve l'interface de RB vraiment efficace et légère à utiliser, et très confortable parce que parfaitement statique. C'est souvent "1 clic genre, puis 1 clic artiste, puis je drag l'album sur le bouton de ma playlist en cours". Ou bien la même chose en ne draguant qu'une partie des pistes. Alors c'est vrai que si ça va si bien, c'est parce que je me contente d'enfiler des trucs sur la liste en cours de lecture, et que je ne quitte en fait jamais le mode browser. La liste, elle, reste tranquille à se jouer en arrière, mais je n'y touche que très rarement.

Maintenant, effectivement, si je voulais faire des manip' plus fines, genre insérer des trucs à un endroit précis de la liste, bah ça serait plus chiant, parce que le drop sur le bouton de d'une liste ajoute à la fin, et qu'il faudrait donc ensuite que je change de vue, que je descende chercher mes morceaux, et que je les remonte. Un moyen simple de régler ça ceci dit ça serait que quand on drag qqch sur le bouton d'une liste et qu'on attend un peu, la vue passe à la liste, et que du coup on puisse directement aller faire le drop au bon endroit.

Ah ? Bah perso, j'avais été convaincu d'essayer amaroK suite à une discussion dans un de tes journaux :
http://linuxfr.org/~gnumdk/15249.html(...)
...et en fait après quelques temps je suis revenu à Rhythmbox, parceque j'ai l'impression que c'est là que j'ai l'accès le plus rapide à ce que j'ai envie d'écouter parmi une grosse collection musicale. On doit pas avoir les même modes d'utilisation je suppose, je sais pas trop...

Perso, j'aime plutôt bien aussi, mais idéalement j'aurais préfèré que la liste des bookmarks de dossiers soient fonction de l'application (enfin, qu'il y ait une liste globale et une liste spécifique).

> Non je crois que le reste c'est par menu contextuel.

Ici (gnome-menus-2.11.92) j'ai pas de menu contextuel ou quoi que ce soit d'autre que la checkbox d'actif :/

> Tu peux éditer en user pour toi, ou en temps que root pour
> root ou pour tout le monde.

Hmm, cool. Bah sous Gentoo, il manque un outil dans ce genre là.

> Gnome VFS est une horreur.

D'ailleurs son auteur lui même n'en parle pas avec un enthousiasme débordant :
http://www.fosdem.org/2005/index/interviews/interviews_larsson(...)
Ceci dit, je pense qu'à l'idée de s'en débarrasser au profit des translateurs hurd, il aurait fait un peu la même réponse qu'à ma question (qui portait elle sur FUSE). Au contraire, lui son regret est que justement gnome-vfs colle trop à l'interface POSIX d'accès à des fichiers, alors qu'il aurait voulu un modèle plus générique et extensible d'accès à des documents.

> http://www.gnome.org/start/2.12/notes/fr/figures/figure-menueditor.(...)

Ouais, mais tout ce que tu peux faire c'est désactiver des entrées. Or ce que l'utilisateur, même assez lambda, voudrait probablement, c'est pouvoir aussi ajouter ou en modifier (genre mettre un icone quand y'en a pas), bref gérer une espèce d'overlay au /usr/share/applications.

> Bon de toute façon j'utilisais menudrake

Ça marche en simple user ou bien c'est un truc d'admin ?

> Amarock <--> heu je connais pas je n'utilise que beep

Ça serait plutôt Rhythmbox l'équivalent de amaroK chez Gnome.

> Est-ce qu'il sera toujours possible de compiler Totem en activant le backend Xine

C'est toujours possible oui.

> une des règles d'or est "ne jamais modifier le fichier d'origine du mail".

Ok, merci pour la confirmation. Je me doutais un peu en fait que c'était pas une idée très catholique, c'est pour ça que je préfèrais en discuter avant de polluer votre bugzilla.

> [...] que j'avais réussi à justifier par le fait que le fichier modifié
> n'était pas celui du vrai mail (complet)...

De l'importance de la réthorique en matière de développement logiciel... :)

> e17 est vraiment beaucoup plus rapide que kde ou gnome

Tiens c'est bizarre, parce que chez moi c'est plutôt Crack-Attack qui est plus fluide que OpenOffice.

Depuis qlqs temps, j'utilise deux "actions" dans sylpheed-claws, pour lutter contre les boulets sur les mailing-lists :
- ceux qui font des Reply-To pour créer de nouveaux fils de discussion, et donc mélangent dans l'affichage en arbre des trucs qui n'ont rien à voir ;
- ceux qui au contraire se débrouillent je ne sais trop comment pour répondre sans "In-Reply-To" et séparent donc dans l'interface des choses qui devraient aller ensemble.

Pour le premier, c'est simple, mon action est :
sed -i -e '/^In-Reply-To:/d' -e '/^References:/,/^[^[:blank:]]/{/^References:/d;/^[^[:blank:]]/b;d}' "%f"
(bref un truc qui supprime les headers In-Reply-To et References dans le message.)

Pour le second, c'est un peu plus tordu : je sélectionne deux messages, et je lance via une action un script qui ajoute à l'un un In-Reply-to avec l'ID de l'autre :
http://tdegreni.free.fr/temp/fix_reply_to.sh(...)
avec comme action :
/path/to/fix_reply_to.sh %F
Bon, ça marche pas de façon parfaitement systématique, m'enfin sur mes quelques essais en général ça l'a fait.

Ah oui, à noter que ce genre de modifs sur les messages ne sont prises en compte dans l'interface que quand sylpheed-claws repasse sur le contenu du dossier, genre après un relève du courrier.


Et bon, maintenant, la feature request (enfin plutôt le petit tatage de terrain pour savoir si ça vaudrait le coup d'ouvrir une RFE sur le bugzilla pour ça) : est-ce que ça serait jouable d'avoir des fonctionnalités équivalentes à ces deux actions directement dans sylpheed-claws, genre codées pour de vrai et intégrées dans l'interface (menu contextuel par exemple) ?

> 1. dillo est tout petit

Dillo est tout petit si tu as d'autres bonnes raisons d'avoir de toute façon les bibliothèques GTK+-1.2 chargées en mémoire, mais sinon, Dillo est plutôt énorme...

> Par contre à ce que je sache Sylpheed-Claws ne supporte pas les mails en HTML

En lecture, il les supporte... à sa façon (qui perso me convient bien). Disons qu'ils sont en général parfaitement lisibles, mais qu'ils ressemblent visuellement à des mails en texte. Tu ne te rends compte que c'est du HTML qu'à quelques détails (genre des hyperliens plutôt que des URLs). Jusque ici, j'ai jamais eu de problème à lire les messages qu'on m'envoyait en pur HTML, sinon des spams volontairement cryptiques.

Exemple :
http://tdegreni.free.fr/temp/sylpheed-claws-html.png(...)
pour un source qui ressemblait à ça :
http://tdegreni.free.fr/temp/sylpheed-claws-html-sources.png(...)

...donne ça:
http://en.wikipedia.org/wiki/CRLF#History(...)