Sylpheed-Claws est un client de courriel écrit en GTK, dérivé de Sylpheed. Ses ambitions sont d'être léger, rapide, et riche en fonctionnalités. Il existe depuis plus de quatre ans. Initialement, il s'agissait d'un fork amical de Sylpheed, et se destinait à permettre de tester de nouvelles fonctionnalités en vue d'une intégration éventuelle dans Sylpheed. Quatre ans plus tard, le projet a dévié de ses ambitions initiales et est plus devenu un fork simple. En effet, peu des fonctionnalités développées ont été reversées dans le code de Sylpheed. Par contre, Claws suit toujours le développement de Sylpheed par des synchronisations de code.
Depuis plusieurs années, les utilisateurs demandaient un portage vers GTK2, portage qui a fini par arriver il y a un peu plus d'un mois, avec la sortie conjointe de deux versions - une en GTK1, l'autre en GTK2. Le mode de développement futur n'était pas encore fixé. La version 1.0.4a est la dernière mouture GTK1, tandis que la 1.9.9 est en GTK2. Il s'agit seulement de la deuxième version GTK2, qui corrige donc quelques bugs présents dans la version précédente. En effet, peu de monde avait pu la tester auparavant, lorsqu'elle n'était disponible que via CVS.
Quant à la version GTK1, elle bénéficie de corrections de bugs communs aux deux branches, mais de moins de nouvelles fonctionnalités. En effet, ces sorties officialisent un changement de politique de développement: cette branche est maintenant en mode maintenance; c'est- à-dire que les bugs que nous y trouverons seront corrigés, mais seule la branche GTK2 bénéficiera des nouvelles fonctionnalités.
Ces deux versions corrigent une vingtaine de bugs, et la version GTK2 apporte quelques nouvelles fonctionnalités, telle que l'affichage en ligne des images jointes, le rafraîchissement des paramètres réseau, ou encore l'envoi de plusieurs emails en une seule connexion SMTP (auparavant, une connexion distincte était réalisée pour chaque courriel).
Aller plus loin
- Le site de Sylpheed-Claws (13 clics)
- Le projet sur Sourceforge (1 clic)
- L'annonce de la 1.0.4a (0 clic)
- L'annonce de la 1.9.9 (2 clics)
# et l'essentiel?
Posté par Maclag . Évalué à 5.
Il existe déjà une foultitude de clients mails sous linux, tous plus riches les-uns que les-autres, et (sans vouloir lancer de troll), hormis sa gestion un mail <-> un fichier, ce que j'adore dans sylpheed-claws, c'est justement que ça décape sur mon k6-II sur mon k6-2 surchargé, tout en offrant tout ce que j'attends d'un client mail moderne ;)
[^] # Re: et l'essentiel?
Posté par tgl . Évalué à 6.
> l'ajout de toutes ces fonctionnalités et le passage en gtk2 ne
> risquent-ils pas de faire perdre à sylpheed-claws son âme
Sur l'ajout de fonctionnalités, je ne saurais pas trop dire, parceque c'est un mouvement trop continu depuis les qlqs années que j'utilise ce soft. Faudrait que je retente une 0.7.x un jour pour voir :)
Mais sur le passage à Gtk2, là franchement moi j'ai pas du tout eu l'impression d'une quelconque régression niveau perfs quand j'ai franchi le cap. Au contraire, je pense que j'y ai gagné parceque je n'ai plus qu'une version des libs Gtk en mémoire (le reste du bureau étant en Gtk2, lancer Sylpheed-Claws me faisait charger tout Gtk1, dont au contraire je me passe complètement depuis).
En fait, je le trouve toujours aussi réactif qu'avant, et il s'est même amélioré ces derniers mois je pense (au niveau du cache j'imagine - Colin, tu confirmes ou bien j'ai tripé ?).
La seule petite lenteur que je vois c'est quand j'ouvre un dossier de + de 10.000 ou 20.000 mails, y'a ~2 secondes de "Tri du sommaire" qui me font passagèrement trépigner (enfin je vois pas pourquoi c'est à nouveau trié si je l'ai déjà consulté avec la même présentation plus tôt). Mais c'est vraiment parceque je fais la fine gueule...
Enfin bref, content de voir la branche Gtk2 sortir vraiment officiellement.
[^] # Re: et l'essentiel?
Posté par M . Évalué à 3.
[^] # Re: et l'essentiel?
Posté par Beretta_Vexee . Évalué à 5.
Le fait est que les machines évolue et que beaucoup de soft en profite pour évoluer en conséquence, tous le monde n'a pas en priorité n°1 de faire un logiciel qui tourne sur 12Mo de ram sur un 486 DX2. On peut le regrettait mais peut on le reprocher aux développeurs ?
[^] # Re: et l'essentiel?
Posté par Yusei (Mastodon) . Évalué à 10.
(disclaimer: j'utilise emacs)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: et l'essentiel?
Posté par arnaudus . Évalué à 9.
Au niveau logiciel, aujourd'hui, j'ai 4 bureaux, deux barres d'outils transparentes avec des applets qui rafraichissent tous les quarts de seconde l'usage CPU, cinq ou six logiciels ouverts toute la journée (navigateur, lecteur de mail, messagerie instantanée...), 4 onglets ouverts dans galeon, un fitre anti-spam qui me trie mes messages grâce à un filtre bayesien dans thunderbird... Faut pas rêver, je veux bien qu'on optimise ça, mais ça ne tournera jamais avec 64 Mo de RAM.
Les logiciels libres ne sont pas à l'abri non plus de cette augmentation démesurée du besoin de ressources. Ils sont en général réalisés par des gens dont ce n'est pas forcément le métier, et dont le but est de diffuser un soft sympa, pas un truc moche mais optimisé.
Enfin, l'optimisation se fait toujours aux dépens de la réutilisabilité du code. La programmation générique ou la métaprogrammation sont des techniques surpuissantes, qui nécessitent malheureusement des sacrifices en matière de performance. Or, la force d'un logiciel GPL, c'est d'être réutilisable. La force d'un langage de programmation objet, c'est de faciliter le développement en équipe. Au détriment des performances, c'est sûr. Mais s'il y a des milliers de logiciels libres, c'est aussi parce qu'ils n'ont pas été codés en assembleur.
Pour en revenir sur le problème, par contre, je suis bien d'accord : l'intérêt majeur de sylpheed, c'est sa légèreté (parce qu'à part ça, hein...). Si les dev veulent changer de créneau, ils vont se lancer dans un "marché" déja compètement saturé, et ils courent à leur perte. Mais bon, c'est eux qui décident quoi faire de leur temps...
[^] # Re: et l'essentiel?
Posté par reno . Évalué à 3.
WindowsXP boote plus lentement sur un Athlon64 3200+ que le faisait BeOS sur un Celeron333, et je ne parle pas de Linux qui est pire (je parle du boot jusqu'au desktop, cela inclut le temps de démarrage du kernel et de KDE avec autologin, depuis Grub jusqu'a pouvoir démarrer un kwrite: je n'ai pas chronométré mais c'est long!).
Je trouve les applications sous WindowsXP ou sous Linux moins 'réactive' que le peu qu'il y avait sous BeOS donc sur certains points, le confort d'utilisation a *régressé*.
[^] # Re: et l'essentiel?
Posté par Beretta_Vexee . Évalué à 4.
http://jw.dyndns.org/initng/(...)
P.S. Pour le moment cela ne concerne que les utilisateurs Gentoo, mais avec 5 versions en moins de 7 jours le developpement est plutot rapide ( passage de un dev a cinq ).
[^] # Re: et l'essentiel?
Posté par karteum59 . Évalué à 1.
ça fait longtemps que l'idée de démarrer les services en parallèle existe.
-> http://www-106.ibm.com/developerworks/linux/library/l-boot.html(...)
Une implémentation triviale ne change pas init mais utilise "Make -j" avec un ou des Makefiles ad'hoc à la place de ces immondes liens symboliques dans rc*.d. C'est tellement simple et limpide qu'on se demande pourquoi personne ne l'a utilisé avant... (sans doute parce que tous les wizards comme webmin et linuxconf utilisent ce système, mais à tout problème y'a des solutions, surtout quand le jeu en vaut la chandelle...).
Personnellement je préfère cette approche (ou toute autre qui ne touche qu'aux initscripts et pas à init lui-même) pq init est stable (alors qu'un initng0.0.1 le sera forcément moins) et que c'est un programme important tout de même ! :)
[^] # Re: et l'essentiel?
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 3.
A force de raisonner comme ça, on n'avance plus. Si ces développeurs ont ressenti le besoin de refaire un init, c'est peut-etre que l'actuel ne leur suffit pas, a des lacunes, l'excuse de la stabilité est uniquement une excuse pour figer les choses et ne pas avancer, et se retrouver avec quelques années voie décénies de retard sur le voisin...
Init est assez infame, peu efficace, pourquoi ne pas en changer ?
[^] # Re: et l'essentiel?
Posté par karteum59 . Évalué à 1.
<ma vie>J'utilise régulièrement AtheOS/SyllableOS sur ma machine perso, et on ne va pas dire que c'est du vieil OS qui n'a pas bougé depuis 10 ans ou qui est super stable...</ma vie>
J'ai simplement dit qu'il y avait d'autres solutions à ce problème (parallélisation du lancement des services), directement implémentable dans les distributions "stables" et sans toucher à init. Maintenant peut-être que init a d'autres carences à combler et c'est très bien que des gens s'y attellent, mais c'est un autre débat !
A l'heure actuelle j'imagine mal une distrib "stable" ou grand public utiliser un init expérimental, alors que la solution que j'ai donnée est directement utilisable aujourd'hui et maintenant. Evidemment rien n'empêchera ces mêmes distribs d'utiliser une alternative à init le moment venu et quand elle sera finalisée mais c'est à plus long terme et il n'y a pas besoin d'attendre ça pour paralléliser le lancement des services...
[^] # Re: et l'essentiel?
Posté par fmaz fmaz . Évalué à 3.
système mais bon).
dans le répertoire "ki va bien", il y a des scripts pour différentes tâches.
Un peu comme avec les rc.[1-1000].d et leurs liens symboliques.
Sauf que les fichiers n'ont pas de numéros.
A la place, les premières lignes contiennent des informations.
# provide NFS
# require REZO
Bref, dans les fichiers, on trouve toutes les informations de
dépendances. Au départ, un petit programme calcule les
dépendances et lance les scripts.
En fait, il calcule un tri topologique du DAG et lance les scripts en
séquentiel.
Il est facile de modifier le prog pour lancer les scripts directement
en parallèle.
Et je t'assure que c'est stable.
[^] # Re: et l'essentiel?
Posté par Mathieu Pillard (site web personnel) . Évalué à 4.
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&c(...)
[^] # Re: et l'essentiel?
Posté par reno . Évalué à 1.
C'est bien mais c'est quand meme une regression, j'imagine que la machine est bien superieure a un Celeron 333 avec 128Mo de RAM..
Et aussi je pense que quand on arrive sous gdm, on arrive a la fenetre demandant le login, apres, il y a le demarrage de Gnome/KDE a proprement parler.
Hors sous BeOS, les 14s sur Celeron 333 incluait le temps de demarrage du desktop!
Donc pour comparer des choses comparables, il faut chronometrer jusqu'a avoir la main sur le desktop en passant gdm/kdm/.. en auto-login par exemple, avec un desktop comparable a celui de BeOS: KDE ou Gnome par exemple.
[^] # Re: et l'essentiel?
Posté par briaeros007 . Évalué à 1.
Mais tu n'est aps obliger de prendre kde ; il existe toute une floppée de wm qui peuvent se charger bien plus rapidement
[^] # Re: et l'essentiel?
Posté par karteum59 . Évalué à -1.
KDE n'est pas gros pq codé avec les pieds (m'enfin, j'en connais qui me diraient que le c++/templates...). KDE est gros pq il a beaucoup de fonctionnalités. OK, on ne les utilise pas forcément (WindowMaker me convient personnellement) mais c'est ce qui lui permet de soutenir la comparaison avec windoze (contrairement à icewm ou fluxbox).
[^] # Re: et l'essentiel?
Posté par briaeros007 . Évalué à 2.
kde est lent au demarrage entre autre parce qu'il charge pas mal de librairies au demarrage et pas lors de leurs utilisations (en lancant un programme qui aura besoin de cette librairie).
Et puis question "comparaison avec windows" c'est totalement subjectif.
amiga -> os dedie a quelques configuration materielle (ou a peu pres) rien a voir avec un pc. Je peux aussi dire que l'os de la xbox (2k modifie) boot plus rapidement que beos. Ca nous avance pas a grand chose.
Xp boot rapidement ? ca depend vraiment de la machine ; sur certains portables il met 2 minute montre en main avant de pouvoir faire quelquechose (pourtant celeron 1400 Mhz).
De plus chez moi (linux) a partir du boot proprement dit ; j'ai moins de 30 sec de demarrage (je ne lance pas gdm et,je lance x a la main. de toute facon mon x se lance en moins 15 secondes) Et pourtant j'ai quelques serveur (mail dns cache etc...)
Linux peux booter rapidement ca depend de ta configuration (et materielle, et logicielle) . Si tu veux absolument du bleeding edge qui te pompe 190 Mo rien que pour ton wm ; c'est ton choix. Mais te plains pas apres si c'est lent au demarrage.
[/suite du troll]
[^] # Re: et l'essentiel?
Posté par reno . Évalué à 2.
Pas vraiment, Windows, BeOS sont (enfin étaient pour BeOS) des OS génériques, avec les mêmes fonctionnalités en tant que desktop, c'est toi qui utilise AmigaOS, Win2k sur XBox comme point de comparaison invalide.
Ta conf n'est pas comparable avec Windows ou BeOS donc effectivement la comparaison ne veut rien dire.
Ceci dit, 30s au demarrage, c'est deja plus que BeOS sur un Celeron 333 donc bien plus ancien que ton celeron 1,4 GHz..
[^] # Re: et l'essentiel?
Posté par briaeros007 . Évalué à 2.
je reprenais l'exemple d'amiga qui etait donné par le parent de mon commentaire , et disait que la comparaison etait non pertinente. Et je donnais l'exemple de l'os de la xbox pour montrer la non pertinence.
[^] # Re: et l'essentiel?
Posté par karteum59 . Évalué à 1.
Je trouve juste que à l'heure actuelle Linux+X11+KDE est _vraiment_ lent à booter (sur le même matériel) là où la "concurrence" a fait de gros progrès, et je pense que des modifications simples (démarrages parallèles des services) pourraient changer la donne.
[^] # Re: et l'essentiel?
Posté par reno . Évalué à 1.
C'est sur lancer un X pur est beaucoup plus rapide, mais a ce moment la, on ne mesure pas vraiment un 'progres'.
[^] # Re: et l'essentiel?
Posté par Christophe Fergeau . Évalué à 10.
Je parlerai essentiellement d'une grosse différence entre gtk1 et gtk2, c'est pango, qui permet d'afficher correctement du texte dans la plupart des écritures possibles et imaginables, quel que soit le sens dans lequel elles s'écrivent et tout ça, ce qui n'était pas vraiment le cas avec gtk1. Et forcément, c'est le genre de trucs qui ont un coût...
[^] # Re: et l'essentiel?
Posté par Yusei (Mastodon) . Évalué à 5.
Je me rappelle avoir passé de longues heures à compresser un album en mp3 sur mon vieux p100, et à jongler avec les .wav et l'espace disque limité... je suis d'accord que pour l'usage de tous les jours on n'a pas gagné grand chose mais pour ce genre de tâches qui demande de la puissance, la différence est très sensible: maintenant je peux compresser aussi vite que je rippe, et sans que ça m'empêche de faire autre chose.
[^] # Re: et l'essentiel?
Posté par Beretta_Vexee . Évalué à 9.
Il y a dix ans tu avais des traitements de textes évolués multi-fenetres avec un contenue riche et de solide fonction de mise en page, du XML et lisant plusieurs format ? Moi j'avais MS WORKS.
Il y a dix ans tu avais une carte vidéo en mesure de gérer plusieurs millions de couleurs, plusieurs écran , une accélérations matériel de la 3D et de la vidéo, etc etc ... ? Moi j'avais une carte VGA 256 couleurs.
Il y a dix ans tu était en mesure de faire de la photo numérique ? Sur mon PS/1 386 avec 2Mo de ram ( machine de nantie en 93 ), ouvrir une image de 1,44Mo ( taille maxi d'une disquette ) avec Corel Photo Paint prenait plusieurs minutes.
Tu rippais des CD en MP3 dés la sortie du code, alors que celui-ci n'était pas lisible en temps réel sur les machines de l'époque ( mp3enc et mp3dec sur un Pentium 90Mhz, décodait a même pas 0.75x ) pour les stocker par facilité sur des DD de plusieurs Go ? Moi j'étais bien heureux avec mes quelques centaines de Mo et si j'avais eux acces a un graveurs sut était pour copier directement les Cd plutot que les encoders en MP3.
Il faut arretter un peut remet toi derriére une machine d'il y a dix ans avec les softs d'il y a dix ans la première chose que tu vas te dire c'est comment j'ai fait pour utiliser un trucs pareil a l'époque.
Donc non je ne regrette pas que tous les softs ne soit plus développer au minimum a 60% en assembleur, les systémes mono-tache et les modem 28000 Bauds.
[^] # Re: et l'essentiel?
Posté par gpe . Évalué à 4.
il y avait aussi MacOS, GEM sur Atari, AmigaOS, OS/2, bref plein de trucs mieux qu'un MSDOS...(peut-être pas Windows 95? ;-) )
Il y avait aussi un certains Linux qui grandissait, non?
[^] # Re: et l'essentiel?
Posté par JoeBar . Évalué à 10.
Aïe... J'ai mis plusieurs secondes et au moins trois lectures pour comprendre cette phrase (après un passage en mode phonétique).
On écrit :
"si j'avais eu accès" parce que "eux" ca se prononce pas pareil et ca fait bizarre.
"c'eut été", qui est la contraction de "cela eut été", forme qui me semble correcte jusqu'à ce qu'on me prouve le contraire... Mais d'où sors-tu ce "sut" ? :)
Sans rancune, dis toi que c'est pour mon soulagement !
[^] # Re: et l'essentiel?
Posté par Beretta_Vexee . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: et l'essentiel?
Posté par syntaxerror . Évalué à 4.
Ah non, le Windows 95 n'est qu'un DOS habillé, et le multitâche est coopératif. Dans la série, c'est Win/NT qui a inaugure le multitâche préemptif.
... et il y a 10 ans, je bossais entre autres sous OS/2 qui lui était un vrai multitâche préemptif et le WPS une vraie interface utilisateur orientée objet ...
http://fr.wikipedia.org/wiki/Multit%C3%A2che(...)
http://www.millennium-technology.com/HistoryOfOS2.html(...)
[^] # Re: et l'essentiel?
Posté par Benjamin François (site web personnel) . Évalué à 1.
Il y a dix ans tu avais un systéme multitache preemptif ?
Il y a presque dix ans (à six mois près) j'installais mon premier Linux, une Slackware fournie dans le numéro de novembre de PC Team. Donc oui.
Il y a dix ans tu avais des traitements de textes évolués multi-fenetres avec un contenue riche et de solide fonction de mise en page, du XML et lisant plusieurs format ? Moi j'avais MS WORKS.
Il y a dix ans Word existait déjà depuis un paquet de temps, et faisait déjà tout ce que tu dis sauf XML. Star Office 4.0 n'a été disponible pour Linux que deux ans plus tard, mais la version 3.0 existait déjà pour Windows.
Il y a dix ans tu avais une carte vidéo en mesure de gérer plusieurs millions de couleurs, plusieurs écran , une accélérations matériel de la 3D et de la vidéo, etc etc ... ? Moi j'avais une carte VGA 256 couleurs.
Il y a dix ans, Matrox sortait la Mystique. Il y a huit ans, 3dfx sortait la Voodoo. Moi il y a dix ans, j'avais une S3 Trio qui affichait du 1024x768 en 16 bits.
Il y a dix ans tu était en mesure de faire de la photo numérique ? Sur mon PS/1 386 avec 2Mo de ram ( machine de nantie en 93 ), ouvrir une image de 1,44Mo ( taille maxi d'une disquette ) avec Corel Photo Paint prenait plusieurs minutes.
Un 386, une machine de nanti en 1993 ?? Les deux premiers Pentium (à 60 et 66 MHz) sont sortis en Mars 1993 ! A cette époque, c'était le 486 DX la machine "standard" qu'on trouvait dans les magasins, le Pentium représentant le haut de gamme du "nanti".
Tu rippais des CD en MP3 dés la sortie du code, alors que celui-ci n'était pas lisible en temps réel sur les machines de l'époque ( mp3enc et mp3dec sur un Pentium 90Mhz, décodait a même pas 0.75x ) pour les stocker par facilité sur des DD de plusieurs Go ? Moi j'étais bien heureux avec mes quelques centaines de Mo et si j'avais eux acces a un graveurs sut était pour copier directement les Cd plutot que les encoders en MP3.
Je rippais des CD en mp3 sur mon Pentium 90 acheté fin 95 que j'ai gardé pendant 5 ans alors que le lecteur de CD-Rom de ce PC ne savait même pas faire de DAC. Ça signifiait digitalisation manuelle de chaque piste via l'enregistereur de sons Windows, pour ensuite lancer mp3enc. Compresser une seule chanson me prenait 3 heures. Oui, je l'ai fait.
Donc comme le dit l'autre, la seule chose pour laquelle on devrait nécessiter du CPU (mis à part les jeux) ce sont ces applications spécifiques super consommatrices comme la conversion de CDs en mp3 ou la lecture de vidéos très compressées. Pour lancer une suite bureautique, utiliser un OS multitache préemptif ou avoir une interface graphique "moderne" il ne devrait absolument pas être nécessaire de disposer des bêtes de course que l'on possède actuellement. Quand je vois KDE sur un Athlon à 600 MHz avec 512 Mo de RAM ramer plus que Windows 95 sur un Pentium 90 avec 24 Mo de RAM j'ai quand même un peu mal aux fesses, parce que oui, KDE fait plus de trucs, mais on parle quand même d'une machine cadencée à une vitesse presque 7 fois supérieure et dotée de 25 fois plus de mémoire !
[^] # Re: et l'essentiel?
Posté par briaeros007 . Évalué à 3.
Il y a presque dix ans (à six mois près) j'installais mon premier Linux, une Slackware fournie dans le numéro de novembre de PC Team. Donc oui.
je croyais que le noyau reelement preemptif c'etait le 2.6... on m'aurais mentit ?
[^] # Re: et l'essentiel?
Posté par kd . Évalué à 3.
Linux a toujours été préemptif, au niveau des processus en user-space. Par contre, on ne pouvait pas interrompre un processus qui est en train d'exécuter un appel système. linux-2.6 le permet.
Je ne connais pas les détails, mais en gros c'est ça.
[^] # Re: et l'essentiel?
Posté par Benjamin François (site web personnel) . Évalué à 1.
Faire tourner KDE.
[^] # Re: et l'essentiel?
Posté par DocteurCosmos . Évalué à 6.
Pourquoi vouloir lire ses spams aussi ? C'est du vice !
[^] # Re: et l'essentiel?
Posté par Colin Leroy (site web personnel) . Évalué à 3.
> l'ajout de toutes ces fonctionnalités et le passage en gtk2 ne
> risquent-ils pas de faire perdre à sylpheed-claws son âme
Non, on essaye toujours de faire efficace. La plupart des features ne se mettent pas en travers du chemin d'une utilisation "efficace". De toutes façons cette "âme" n'est pas dûe à des micro-optimisations de ci de là mais surtout à un mode d'utilisation (le plus possible de raccourcis, confirmations "intelligentes", ...)
En fait, je le trouve toujours aussi réactif qu'avant, et il s'est même amélioré ces derniers mois je pense (au niveau du cache j'imagine - Colin, tu confirmes ou bien j'ai tripé ?).
Tu as tripé :-) le cache a été un chouïa optimisé c'est vrai, mais pas de quoi voir la différence. Le plus visible est fait dans l'interface (comme par exemple locker les màj graphiques des arbres avant de déplacer des mails pour éviter N refresh, etc.)
La seule petite lenteur que je vois c'est quand j'ouvre un dossier de + de 10.000 ou 20.000 mails, y'a ~2 secondes de "Tri du sommaire" qui me font passagèrement trépigner
Moi aussi; en même temps, c'est gros 20000 mails :)
(enfin je vois pas pourquoi c'est à nouveau trié si je l'ai déjà consulté avec la même présentation plus tôt)
Pour une raison de place mémoire... Imagine si on gardait le résultat du threading de N dossiers à 10000+ mails :)
[^] # Re: et l'essentiel?
Posté par gpe . Évalué à 2.
Quand j'avais essayé sylpheed-claws (en version 1) ça m'avait agacé et j'étais revenu à sylpheed (non-claws) qui n'a pas ce phénomène.
[^] # Re: et l'essentiel?
Posté par oliv . Évalué à 6.
# [...] le rafraîchissement des paramètres réseau [...]
Posté par tgl . Évalué à 4.
Si oui, alleluia \o/
[^] # Re: [...] le rafraîchissement des paramètres réseau [...]
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: [...] le rafraîchissement des paramètres réseau [...]
Posté par Guillaume Gimenez (site web personnel) . Évalué à 2.
euh... y'a mieux ?
# chapeau
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 4.
A essayer de toute urgence. Personnellement, il ne lui manque que deux features pour que je lache thunderbird : le support de l'IDLE imap4 (que seul thunderbird gere), et le subscribe sur imap4 aussi ;)
En tous cas, bonne continuation au projet et chapeau !
# Très très bien, et félicitation
Posté par Zorro (site web personnel) . Évalué à 4.
Maintenant, le titre de l'actu sens-entend que ce mauvais coucheur, pourtant à l'origine d'un beau projet, serait parti ?... Faut-il toujours tuer le père pour avancer, Herr Freud ?
[^] # Re: Très très bien, et félicitation
Posté par Colin Leroy (site web personnel) . Évalué à 5.
Mais effectivement l'un des initiateurs du projet, par son immobilisme (vis-à-vis de gtk2) et sa manie de réécrire en c++ des trucs qui marchaient , m'a saoûlé très fort, j'ai failli forker, du coup il est parti, du coup ça c'est débloqué.
Pour les amateurs de Santa Barbara du logiciel libre vous pouvez voir l'histoire longue et les deux points de vue sur
http://www.colino.net/wordpress-1.5/archives/2005/02/17/sylpheed-cl(...)
http://www.colino.net/wordpress-1.5/archives/2005/02/17/sylpheed-cl(...)
http://reboot.animeirc.de/sylpheed/(...)
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Liens Sylpheed / Sylpheed Claws
Posté par Colin Leroy (site web personnel) . Évalué à 4.
Est-ce une manière polie de dire que l'auteur principal de Sylpheed a presque ignoré le projet Sylpheed Claws quant à d'éventuelles améliorations/nouveautés ?
C'est un peu l'impression que j'ai, mais comme je n'étais pas là à la création du projet je peux me tromper.
Par exemple, j'utilisais depuis peu Sylpheed 1.9.9 en GTK+2 [1] et j'ai été étonné de constater que le port GTK+2 avait été pris du projet sylpheed-gtk2 [2] - moins connu comparé à Sylpheed Claws - alors que Sylpheed Claws supporte GTK+2. À moins que le support GTK+2 de Sylpheed Claws provient aussi du projet sylpheed-gtk2 ?
Initialement, oui, c'est aussi Takuro Ashie qui a fait le premier (gros) patch gtk2 pour Claws, et qui l'a maintenu pendant 6 mois. Ensuite, il s'est concentré sur sylpheed-gtk2. Reprendre le support gtk2 de Claws aurait représenté plus de travail pour Hiroyuki que reprendre celui de sylpheed-gtk2, vu la divergence des sources :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.