Raphael Junqueira a écrit 337 commentaires

Mais c'est "vous" qui polluez systématiquement dlfp avec "gnagna le patch de redhat".

Perso je "pollue" a ce sujet car je pense que la facon dont a ete fait ce patch n'est pas la voie a suivre (au sens integration). Si le libre veut devenir realiste il faut qu'il travaille uni et non avec justement ce genre gueguerre.

Sur Linux c'est courament fait. Il y a des tonnes de trucs que refusent Linus Torvalds qui sont "joyeusement" intégré. Mandrake a demandé l'avis des "core devs" avant d'ajouter supermount qui semble-t-il n'a jamais bien marché et n'a jamais été intégré à Linux ?

Est ce que j'ait dit que j'appreciait aussi ce que je faisait mdk a ce sujet ? Non car pour moi c presque la meme chose qu'a fait RH (l'aspect commercial du "premier qui l'a fait" en moins). Et je pense que si Linus refuse d'integrer des patchs comme celui de supermount c qu'il a ses raisons que seul des core devs peuvent evalues (et c pas des dev classiques qui maitrisent a peine le sujet qui peuvent l'evaluer). Pour preciser, bien que je pense que souvent Linus a tendance a refuser pas mal d'innovations pour vraiment pas grand chose et que RH comme mdk ont des kernels devs bien connus qui peuvent bien integrer "proprement" des patchs non officiels, le principe est pourri car peut facilement entrainer de la part des users (example a la con): "g essaye RH est c'etait tou pourri car y avait pas la detection auto, je suis retourner sous win..."

NON. RedHat et plein d'autres font de même et personne se plaint.

FAUX, je me plaint et je suis pas le seul, les devs kde se plaignent souvent des packages modifies par les distribs (comme de nombreux autres projets: mplayer, ...)

Je ne suis pas d'accord dans le cas d'un distributeur qui n'est pas impliqué dans un projet. Sinon les core devs vont être arselé par suse, mandrake, redhat, debian, slackware, etc... et ils ont autre chose à foutre que de répondre à des besoins spécifiques des distributeurs.

A la base, les distribs n'ont pas a harceler (avec un h) les devs.
Si elles le font, c qu'elles ne doivent pas etre d'accord avec les devs , qui sont normalement les architecte de leurs propres develloppements. Les distribs ne devraient pouvoir que demander des features ou engages des devs impliques dans le projet afin de devellopper leurs besoins. (ce que RH et mdk font generalement et en cela je les respecte)

Redhat a utilisé xft2 et fontconfig pour gnome 2.0 aussi dans la RH8.0 et ce n'était pas dispo officiellement dans Gnome. Ils n'ont pas demandé au projet gnome de bosser sur leur distribe.

Si je me souvient bien, de nombreux core devs gnome bossent chez RH. D'apres toi qui a fait ce (fort bien fait) developpement qui a finit d'ailleurs par etre integre ?

Que dirais-tu si redhat profitait de son influence sur Linux pour changer les orientations du projet ?

Ils l'ont fait au moins pour la libc, gnome et gcc. Maintenant je ne pense pas que cela a ete negatif pour les deux projets.

Que dirais-tu si Alan Cox disait : "mon employeur me dit que pour la prochaine RH10 il faut bosser sur ça et ça.".

Il le dit, de nombreux developpement au niveau noyau qu'il a effectue sont influences par les orientations de RH.

Alsa a fait ses preuves hors de Linux et maintenant Alsa est intégré à Linux 2.6 par exemple. Suse (le principale contributeur alsa et de très loin) n'a pas demandé "svp intégrez Alsa".

hmmm tu devrait relire la lkml alors. Alsa (dont les principaux devs sont payes par suse) a fait cette demande il a y a peu, lorsque le produit etait stable, cela appuye par plusiseurs distribs (suse et mdk en tete) comme gage de stabilite.

Y a-t-il quelqu'un pour dire "scandale suse bosse sur alsa, distribue alsa, alors qu'alsa n'est pas dans le noyau officiel" ? Non, il y a personne pour faire ce reproche.

Heureusement que personne ne se plaint sinon on avancerait pas.
Enfin si tu pense que c ce genre de choses que je pense qu sujet de RH tu te plante bien et tu devrais relire mes commentaires.

Quelle remarque puante. Les sources étaient dispos et il y avait des centaines de testeurs.

Penses-tu que les autres distribs ont le temps de lire les ml de devs des autres ? De plus les sources n'ont etes dispos reeleement qu'a partir d'un certain stade proche de la beta.
Autre chose savait tu que mdk faisait la meme chose dans son coin au meme moment avant que l'on t'en parle ? non, car toi non plus tu ne list pas la ml cooker donc tu n'aurais ete au courant que lors de la livraison de la beta et ce encore si mdk s'en vantait dans l'annonce (ce que RH a fait)

J'ai l'impression que vous avez trouvé un os à rongé car vous n'aimez par redhat.

C faux, je respect bcp RH surtout pour leurs nombreux apports au libre, maintenant je suis realiste sur le fait que c'est une des rares distribs qui montre un aspect commercial aggressif envers les autres (c leur droit, si ils pensent que c comme ca qu'ils vont creuser, maintenant moi je n'aime pas trop leurs methodes)

Mais tout les reproches que tu fais ici sont grotesques.

Relis ce que je dit, au lieu d'interpreter de facon basique ce que je dis. Et evite ce genre de remarques.

Regarde plus particuliairement kdelibs et kdebase . Le plus gros patch spécifique pour l'intégration dans BlueCurve fait 286 lignes ...

Tout ce bruit, ces articles, pour moins de 300 lignes de patch ...

tu vois quand tu veux ;)
Imagine que les distribs se mettent a patcher le coeur des projets (en parrallele des projets) comme KDE sans l'aval des devs et SURTOUT sans l'aide de core devs (n'ayant de plus pas de personnel maitrisant un tant soit peu la chose) ... ca donnera une bien triste image du libre

De memoire le patch originel etait plus gros. Mais le plus triste c'est que s'ils avaient oser demander l'aide ne serait-ce que d'un core dev (comme le font les autres distribs) le code reelement utile aurait pu integrer a KDE et surtout ils auraient vu que la majorite de ce qu'ils voulaient faire etait dispo via les fichiers de conf.
Malheureusement, ils ont voulus faire ca, en cachette, pour soi-disant etre les premiers (et eviter tout fuite) ... donc necessairement quand ca commence comme ca

Me faites pas rire sans déconner. L'initiative de redhat a été un succès (au moins médiatiquement),

Normal RH a tout fait pour que ca fasse grand bruit, histoire de montrer a tous l'innovation.

sauf ici, et maintenant c'est mandrake qui a eu l'idée alors qu'il n'ont rien dit lors de la sortie de Redhat 8.0, qu'il n'y avait rien dans cooker avant le début des travaux sur 9.1.

hmm, mdk avait depuis pas mal de temps un pseudo-theme unifie juste qu'avant c'etait pas bo (ressemblait a du gtk de base). Et je vois pas en quoi ils avaient l'intention de dire qquechose. Tu aurait prefere qu'ils cirent au plagiat: "copiteur" ? Le libre s'enrichit des idees des uns ameliorer par d'autres.

Mandrake n'est pas le centre de l'innovation du logiciel libre et il peut leur arriver, comme à tout le monde, d'être débordé par les autres.

Le mot "deborder" est un peu fort, je qualifierait plutot que les travaux de mdk ont servis de base aux "nouveaux" travaux sur l'utilisation desktop chez RH.

Surtout que même pour la 9.0 kde et gnome était livré avec les thèmes par défaut alors que mandrake savait, et tout le monde le savait, que redhat allait sortir BlueCurve.

Hmmm, a mon souvenir RH a bien garder cela secret jusqu'a la beta (sachant que le dev de la distrib RH est assez ferme c'etait facile). Sinon les devs KDE auraient pus contribue a corriger le tir.
Maintenant je vois pas ce que veux sous-entendre, que si mdk savait (depuis la beta) qu'ils auraient du jouer a la gueguerre avec RH (donc jouer le jeu de RH qui fanfarronait bien que "leurs innovations" pour les users).
Je pense que le libre a deja trop souffert de gueguerres debiles.

Qui est gratuit pour le mode demo de rhn (un machine par adresse mail).
L'ancien système manuel est toujours dispo. Donc pas de régression. Par exemple pour RH8.0 :
https://rhn.redhat.com/errata/rh8-errata.html(...)
Si tu installes apt4rpm, il suffit d'un "apt-get upgrade".

Si je me rappelle bien le mode demo de RHN est limite enfin bon, tjs est il qu'il aut que tu t'inscrive (meme si c gratuit) a leur RHN pour pouvoir en profiter (je ne ferait pas de parrallele hasardeux avec le MSN mais dans l'absolu les methodes employees sont les memes bien que MS a du revenir en arriere)

> Galaxy fournissant bien plus de chose que BlueCurve qui n'est qu'un theme
C'est pas ce qu'on m'a dit dans cette news :
http://linuxfr.org/2003/03/14/11713.html(...)

themes + icones + menu
Maintenant je pense que ca n'est pas encore complet (surtout niveau des icones specifiques)

Ceux qui on payé pour être clubber, vont se demander à quoi cette page sert : http://www.mandrakeclub.com/modules.php?name=RP(...)
- "Only Club members are allowed to vote for RPMs."

D'ou la nuance entre un vote (club) et une requete (cooker): la requete ne sera potentiellement pas suivi d'un acte alors que le vote sous-entend une priorite dans les actions.

Lorsque je dis "RedHat fait payer les mises à jour automatique", c'est principalement pour les entreprises. Pour un particulier le mode demo suffit et il y a aussi apt4rpm.
J'espère que tu as noté le "Ce n'est pas un reproche. RedHat fait payer les mises à jour automatique, Mandrake a choisi une autre voix."

Mdk a une distrib (la CS) pour le meme principe, maintenant la distribe de base pour les users reste identique. RH a prefere "l'orientation entreprise" donc abonnement.

Moi je trouve les propos un peu incohérent. Mandrake avait annoncé qu'il "favoriserait" les clubbers pour la sortie de la 9.1 et personne pour se plaindre. D'ailleur il n'y a pas lieu de se plaindre pour ça. Maintenant, c'est RedHat qui le fait et les gens font :
- bouh, c'est vilain.

Faut arrêté de vous opposer systématiquement, car vous vous retrouvé souvent le cul entre deux chaises.

Je confirme le mot "favoriser" != "leser". Relis ce que je dit plus haut:
RH a "retirer" du support pour le rendre uniquement accessible via son "club", mdk a creer des nouveautes pour le club en laissant ce qui etait deja acquis pour les non-clubbers acquis! (exception faite du campus mais ca c un cas tres special que je n'argumenterait pas)

Pour ton pseudo argumentation sur la pseudo-battaille locale a DLFP entre les partisans de RH et mdk je ne dirait que:
- je ne critique ni le RHN ni le club qui dans le principe sont equivalents
mais je voulait juste te montrer la grosse difference de pensee entre RH et mdk au sujet des services dispo club/pas club
- je n'ai jamais apprecier l'idee de gcc2.96 (ca na cause que des probs que ca soit chez RH ou mdk)
- je n'aime pas du tout l'ext3 car ca n'apporte rien au niveau integrite et stabilite des donnees par rapport a l'ext2 (je ne l'utilise que sur le /boot pour que grub et lilo fonctionne correctement)
- je n'a pas trop aimer le fait que RH apparaisse subitement (plutot fasse en sorte avec bcp de pub) comme le "revolutionnaire" de l'homogeneisation des DE (alors que peu de temps avant c'etait du jemenfoutisme complet) alors que mdk et connectiva bossent depuis plus de 2 ans la dessus: en gros RH n'a fait que "s'inspirer" de la majorite des bonnes idees, coder un truc vite fait (techniquement ca se voit), et ont sortie la fanfare. Pour ca je ne supporte pas le fait de mettre BlueCurve devant tous les efforts de mdk (Galaxy fournissant bien plus de chose que BlueCurve qui n'est qu'un theme).

* Les membres du Club peuvent réclammer et voter pour bénéficier de nouveaux paquetages de logiciels avec le système de vote RPM. Des centaines d'applications sont d'ores et déjà disponibles pour les versions 8.2 et 9.0 de Mandrake Linux.

Avant tout le monde pouvait réclamer un paquetage.


tu le peut tjs, il suffit de faire comme avant: passer par la ml cooker (je l'ait encore fait y a qques semaines)

* Des réductions spéciales sur les produits et services disponibles sur MandrakeStore, la boutique en ligne de MandrakeSoft

Avant il n'y avait pas cette distinction entre clubbers ou non.


Ben avant y avait pas de reduction. C'est tout a fait normal que des gens qui payent une sorte d'abonnement aient le droit a des reducs. Ca correspond a une nouveaute et non une regression.

* Une méga-base de tous les logiciels disponibles pour Mandrake-Linux au format RPM. Plus de 50 000 paquetages - plus de 100 GO de programmes - sont maintenant disponible pour toutes les versions de Mandrake Linux !

Avant toutes les applis étaient disponibles.

NB : Ce n'est pas un reproche. RedHat fait payer les mises à jour automatique, Mandrake a choisi une autre voix.


urpmi est ton ami, tout est dispo il suffit de chercher sur le site web comment on fait. (ce n'est pas directement accessible mais c dispo)

maiieuu pourquoi féliciter mandrake de rendre disponible les isos alors que presque tous le font ? Tout devient une exclu quand c'est mandrake qui le fait ?

Pcque ils auraient largement pu etre tente de suivre RH avec le club (histoire de faire plus de pepette) et que malgre les problemes financiers ils ne l'ont pas fait.

Q : pourquoi avez vous copié BlueCurve ?

Je ne qualifierait pas Galaxy de copie de BlueCurve car deja ca couvre plus de choses et que si l'on suit la l'evolution de l'interface mdk depuis 2 ans c'est clairement vers cela que ca convergeait (il y avait deja des pseudo-themes pour homogeneiser l'ensemble depuis pas mal de temps). Du cote de RH, l'idee BlueCurve est apparue d'un coup (qd ils ont enfin decide de s'attquer a l'interface de la distrib).

Donc dans l'absolue, BlueCurve est la premiere vrai implementation (en ce sens que l'interface etait presque homogene entre les 2 grands DE) d'une idee venant de mdk (user friendly). Maintenant sur l'aspect purement technique je ne ferait aucun commentaire, par contre sur l'aspect utilisateur mdk va largement plus loin (menus homogenes, ...)

Mandrake fait payer un club, il faut bien qu'il y ait une diffirence avec ceux qui ne payent rien. C'est totalement normal.

On est d'accord, maintenant il ne faudrait pas aussi leser ses utilsateurs n'ayant pas souscrit au "club" comme le fait RH.

Pquoi je parle de "leser", car historiquement la distrib RH a tjs ete dispo a l'ensemble des users en meme temps, alors que depuis la creation du club tout ceux qui n'ont pas souscrit on du attendre. Cela correspond clairement a une "regression de support" des users pour les forcer a souscrir au club. Ca ressemble bcp a du redmond, en "limitant" (meme tres partielement) les droit de l'user commun au fur a mesure pour les forcer a payer un peu plus (microsoft avait commencer tres leger aussi au debut).

Pour mdk, le principe du club est different: le support classique et toutes les choses deja acquises historiquement aux users normaux le reste, les adherants au club ayant droit qu'a des nouvelles choses en plus du support classique. (mise a part l'histoire du mdk campus mais la chose se basant a l'origine sur le l'argent c comprehensible)



100 % pure troll garantit. Windows n'est pas gratuit, redhat n'utilise pas de formats propriétaires, redhat fourni tout les sources, on peut copier les distribes, les modifiers, microsoft ne bosse pas massivement sur des projets LL, redhat respecte tous les standards, etc, etc, etc...

Féliciano tu t'avance un petit peu trop la, faut pas s'embaler comme ca :)

Pcque, RH respecter tous les standards, y a encore du boulot (precision: je parle au niveau distrib pas au niveaux des applications libres qui la composent qui generalement respectent les standards)

Bon ca risque de partir en troll mais il existe bien de nombreux projets qui ont un processus de developpement et 'ouverture permettant facilement a quiconque le voudrait de contribuer. Parmis les plus gros et les plus connus on peut citer: les DE gnome et kde, wine, ... Maintenant chacun a ses legers defauts mais dans l'absolu ils fonctionnent (en terme de developpement) tres bien et je te conseille d'essayer pour voir. Personnellement, je suis tjs autant impressioner par la qualite de gestion du projet kde: tous les groupes (core devs, traducteurs, testeurs, applis devs, ...) contribuants au projet peuvent facilement communiquer entre eux et travailler entre eux sans trop "d'effets de bords".

huhuhu un lancement de troll

Mais bon on va y repondre clairement!

navigateurs/explorateurs impossible à enlever (autant konkeror que nautilus)

Archi faux, ce ne sont que des composants commes les autres qui peuvent etre facilement efface ou desactives dans leurs environnements respectifs. D'ailleurs konqueror ne correspond qu'a l'explorateur de fichiers toutes les autres fonctionnalites sont des composants kparts fournies par des libs ou des applis (ex: kthml).

Et si je préfère mozilla? C'est possible de mettre mozilla comme navigateur /explorateur de fichier par défaut?

Pour le navigateur sans probleme par contre utiliser mozilla en tant qu'explorateur de fichiers faut aimer souffrir enfin si c ce que tu veux tu peut le faire aussi.

C'est un des trucs qui me déplaisaient sousn windows: impossible de se séparer de ce fichu Internet Explorer.

bouhhh, c faux aussi, tu peut facilement mettre mozilla comme navitateur par defaut. (pour l'explorateur de fichier c plus complique)

Amicalement

... malgrès le fait qu'il soit pas en Français (bon, c'est pas extremement important) ...

les applis kdenonbeta (dont fait parti kopete actuellement) sont traduites qu'en dernier recours (plus primordial les autres parties de kde) maintenant des qu'il sera dans kdenetwork (enfin plutot kdepim) il sera traduit en priorite.

... qu'il est "planté" a deux reprise lors de la configuration au début, ...

Ca doit etre le probleme de chargement/dechargement de module :( Il y a encore qques problemes la dessus ...

Il m'a impressionné en retrouvant toute ma liste de contacte icq directement depuis leur serveur alors que j'avais pas souvenir l'avoir enregistré sur leur serveurs. Bref, pour un passage windows/Linux sans avoir à ce refarcir la liste des contactes icq, kopete est parfait.

En fait il pourra meme la mettre a jour bientot (qd les bugs seront fixes) ;)

ben normallement qd t'on kopete crash il t'ouvre une fenetre pour dire que ton application a "crashee" (le gestionnaire de plantage). Tu clique alors sur l'onglet "Pile d'appels", tu attend patiement que ton pc arrete de mouliner le temps que la piles des appels apparaissent (y aura marque termine en dessous qd finit). Puis copier, coller dans un mail et zouuuh

Jabber unifie tous les protocoles dans un seul. Pourquoi encore faire des connections directes aux autres alors que c'est transparent ? <snip> Jabber unifie tous les protocoles dans un seul. Pourquoi encore faire des connections directes aux autres alors que c'est transparent ? Peut etre pcque comme tu le dit si bien le but de jabber n'est pas d'emuler les autres protocoles (et se brider au passage pour fondre dans le moule) mais plutot d'etre un protocole d'IM autonome. Pour moi c'est une heresie cette emulation, ca ne fait qu'empecher la propagation de jabber (pour un user lambda: pkoi l'installer si trillian "fait" la meme chose) car le limite a etre generique tout en ne pouvant gerer pleinement les autres protocoles (donc encore plus de raison pour pas utiliser jabber pour le user lambda) Maintenant libre de toi d'utiliser cette couche, mais perso je prefere utiliser kopete qui lui gere, par example, presque completement le protocole icq (contact list sur server, ...)

ben si pouviez renvoyer des infos pour que cela puisse etre analyser ca pourrait aller plus vite a stabiliser ;) Par exemple la call stack du ksysguard ca pourrait aider

y a de ces autistes sur terre ...

enfin bon si certains ont du mal, pkoi pas mais alors qu'ils laissent l'option pour reactiver cette fonctionnalite facilement, pas via un patch a appliquer (y a pas moyen que je recompile mozilla) :(

heuresement que sous konqueror elle est encore la ...

je pense que le mieux c de leur dire directement: kde-devel@kde.org

enfin kopete est pas encore officielement dans kde, ca sera pour la version 3.2 (version 1.0 de kopete) et vu ce qui est prevu en terme d'integration (pensez utilisation de kressources/kabc dans tout kde, ...) ca va faire mal (surtout la periode de convergence ... mais soyons fous)

un des plus mauvais programmes de MS

c'est toi qui parle d'argumentation ...
"retire" juste vieux ajouts a la con de microsoft et regarde le fond de l'appli: un moteur multimedia comme celui de media player ca se fait pas en claquant des doigts, ca demande une grosse maitrise technique d'autant plus qu'il peut gerer a peu pres n'importe quoi comme codecs. Pour ton info mediaplayer correspond, en fait, a une grosse partie de l'api mulitmedia de windows. (utilisee entre autre par netmeeting, etc...)

Maintenant si on veut la meme chose sous linux va falloir pousser sur un veritable framework multimedia digne de ce nom donc booster soit gstreamer, soit mplayer, soit xine (ma preference allant a gstreamer: bien qu'il y ait pas de resultat visible ca doit etre le plus avance)

je suis tout a fait d'accord sur le fait que l'on doit passer a un protocole ouvert et independant d'une societe.

Maintenant je ne trouve jabber encore assez limiter actuellement, mais bien sur rien n'empeche de l'etendre.
Sinon je ne trouve pas l'idee de passerelle dans jabber tres intelligente, car cela limite actuellement jabber au plus petit denominateur communs entre tous les IM alors qu'un principe a la kopete qui gere separement chaque protocole permettrait que jabber se developpe sans peroccupation des supports des autres protocoles.

Son principe de fonctionnement est beaucoup plus souple, chacun pouvant installer un serveur Jabber a la manière d'un serveur de mail : Il n'y a pas de dépendances avec un organisme central, ce qui me paraît très important pour pouvoir garder une certaine liberté (contrairement à icq, aim, etc..).

c'est d ailleurs le principal interet de jabber actuellement (meme si je trouve que l'idee des contacts lists "nomades" devrait etre gere, mais bon techniquement ca va etre chaud)

<parenthese>
Une webcam ce n'est pas de l'instant messaging ;-) C'est simplement des choses différentes que MS a intégré à la même application. C'est du video conferencing... Les protocoles sont bien standardisés dans le domaine et netmeeting n'arrive pas à la cheville de gnomemeeting de plus est.
</parenthese>

je suis d'accord sur le fait que gnomemeeting est tres bon, maitenant sur tes autres idees ... ca frole lafermeture d'esprit
Le fait que des applis tres specialisees existent pour gerer les differents types de "contacts/transfert" que tu puisse faire sur le net n'empeche pas que l'integration dans ton logiciel de IM est plus qu'apreciable (un transfert de fichier a un ami sans te prendre la tete a creer/connecter un serveur, ...). Rien n'empeche alors le protocole IM de deleguer cette tache a un protocole plus adapte (generalement lors de transferts de fichiers ils font un simili-transfert ftp a la dcc send d'irc)

Il faut etre realiste: quand on voit la simplicite avec laquelle tu peut ouvrir un "meeting" entre plusieurs de tes contacts msn (juste en 2-3 clics) sous win, c utilisable par n'importe qui. De ce cote la passer par {gnome,net}meeting n'est interressant que pas des "utilisateurs confirmes" qui veulent avoir un controle pointu de la chose et qui se sont mis d'accords avec tous les participants.
Je pense qu'un principe similaire avec kopete qui pilote gnomemeeting doit etre rapidement faisable.

De plus il ne faut pas oublie les personnes "handicapees" pour qui ce genre de fonctionnalites sont vitales pour pouvoir communiquer

Sinon, ne t'inquiete pas le nombre de protocoles d'IM evoluera surement une infinite moins que tous les differents protocoles p2p et autres cochonneries que l'on decouvre tous les jours :)

Jabber a le grand mérite d'unifier tous ces protocoles. De plus je ne pense pas que le nombre de fonctionnalités offertes par le protocole est figée. Le protocole est ouvert et des évolutions sont plus qu'envisageables.

Je ne pense pas que passer par un "huge" protocole qui inclus toutes les possibilites soit la solution car, comme je le sous-entend ci-dessus, la majorite des protocoles "deleguent" leurs traitement (par exemple la gestion webcam a netmeeting) ce qui permet d'etre assez souple au nivo des protocoles.
Alors que la, tu devrait gerer cette possibilite directement au niveau du protocole meme (afin de gerer toutes les specificites) ...

bizarre ... il a juste un bug facheux lors du quit en pleine tentative de connection connu

tu a une stack ?

Pourquoi ne pas améliorer la couche ICQ/MSN/... de jabber, c'est ça ma question ?

pcque la principale diff entre jabber et kopete vient du fait que jabber se base sur la meme couche intermediaire donc limite au fonctionnalites communes alors que kopete lui tente d'implementer pleinement toutes les fonctionnalites des protocoles malgre le fait que certains protocoles soient assez brider.

Maintenant rien n'empeche jabber d'utilser les "libs de protocoles" de kopete: chaque protocole utilise une lib disctincte de kopete (kopete ne faisant apres qu'une couche d'intergration par-desssus) qui est soit developpee specialement par les devs kopete (libicq_new) soit une lib partagee avec un autre projet (par example je pense que la lib oscar est partagee avec gaim)


Tous ces protocoles font la même chose et sont incompatibles...

faux, cf le thread ou on demande si la webcam msn sera integree
ils font majoritairement la meme chose (mis a part irc qui est assez special comme support pour un IM) mais ils ont tous des petits bonus qui font toutes leur differences (au final assez grande)

Je suis moi-meme en train de dev un protocole sous kopete, et j'avait voulu le porter pour jabber. j'ai vite dechante quand j'ai vu que le protocole que j'avait implemente qui ne gere quasiment rien mais qui permettait du broadcast/multicast ne pouvait etre gerer facilement avec jabber

kopete ne supporte actuellement que le transfert de fichier et le chat.
maintenant rien ne t'empeche de faire un plugin conversation vocale ou pour gerer la webcam (je pense que cela est prevu mais pas assez de devs) surtout que c assez simple a dev des plugins kopete (bon pour la webcam y a qd meme pas mal de difficulte car je voit pas comment integrer dedans enfin bon c faisable)

enfin c pas pour dire mais trillian il est pas terrible apres que tu ait essaye kopete :)
pcque l'idee des meta-contacts c de la folie ce que tu peut faire avec,
manquerait plus que des transferts de fichiers "pipes" (tu le recoit d'un contact par icq tout en le redirigant par dcc sur irc) et ca sera la fete :)
(bon c'est ce que j'essaye de coder actuellement et ca marche pas glop)

essaye deja kopete et un client jabber separement,
tu verra que, par exemple, le support icq de kopete est largement superieur que l'emulation jabber/icq (bon le prob c que sur la version release de kopete tu peut po sauver ta contact list sur le serveur icq because ca marche pas tres bien). Meme chose pour AIM
De plus chaque protocole gere tres differement les transferts de fichiers donc ...

enfin le fun c de pouvoir avoir des meta-contacts icq, irc, msn pour la meme personne meme si il se cache (par exmple uniquement present sur irc), kopete va te le trouver :)

non tu ne te trompes pas
j'essaye d'ailleurs de trouver l'option dans la config pour le remettre, si qqu'un sait ou ca se trouve ...