Les principales nouveautés sont:
- Nouveau moteur de thèmes de chat
- Compatible Adium et Gtalk.
- Support de Jabber amélioré.
- Prise en charge expérimentale de la voix avec Jabber en utilisant libjingle.
- Réécriture du protocole Yahoo.
Plus de détails dans la suite de l'article Général:
- L'ancien moteur de thèmes basé sur XSLT, qui avait pour inconvénient d'être lent et lourd, a été remplacé par un moteur XHTML/CSS compatible avec Adium. Les thèmes sont maintenant un ensemble de fichiers HTML et CSS, offrant la possibilité à qui le souhaite de contribuer facilement.
- Get Hot New Stuff est maintenant activé, offrant la possibilité de télécharger/installer des thèmes ou icônes sur kde-look d'un simple click.
Ainsi que:
- Beaucoup de corrections de bugs.
- Des simplifications, et une harmonisation au niveau de l'interface.
- Le message de statut se change différemment et apparaît dans la barre d'état.
Pour les protocoles:
Jabber
Jabber a subit a sérieux coup de fouet avec cette version, concentrant par exemple l'attention de Gof, ancien responsable de MSN. On peut citer :
- Prise en charge de la voix grâce à Jingle (expérimental mais fonctionnel). libjingle, qui contient quelques bugs, n'est pas vraiment adaptée à Kopete. Elle n'est pas non plus compatible avec les spécifications des JEP, mais est compatible avec Google Talk). Pour la prochaine version, le but est un support conforme aux standards (avec sans doute une couche de compatibilité gTalk), et utilisant Phonon.
- Meilleure prise en charge des transports Jabber, chaque transport étant considéré comme un protocole à part entière.
- Liste des salons d'un serveur de conférences, et choix du salon.
- Signets pour rejoindre rapidement des salons. (JEP-0048) Bien qu'il ne soit pas possible d'éditer les signets avec l'interface graphique de Kopete, il faudra utiliser la console XML ou un autre client qui supporte l'édition des signets (rejoindre automatiquement un salon est supporté).
- XHTML-IM : soit la possibilité d'utiliser un formatage pour les messages (JEP-0071).
- Utilisation de la JEP-0085 (Chat State Notification) pour les notifications de frappe, en plus de l'ancienne JEP-0022 déjà supporté dans Kopete. Kopete est compatible sur ce point avec plus de clients (dont Google Talk à ce niveau).
- Prise en charge des avatars stockés dans la vCard (JEP-0153).
- JEP-0162: Best Practices for Roster and Subscription Management.
- Compatibilité avec les thèmes d'émoticons décrit dans la JEP-0038 même si le format des thèmes par défaut reste l'ancien.
- Corrections de nombreux bugs (notamment en ce qui concerne les MUC).
Yahoo
Le support du protocole Yahoo a été complètement réécrit, tout en gardant les les anciennes fonctionnalités, il ajoute :
- Le support de la webcam dans les 2 sens.
- Transfert de fichiers, y compris en provenance de YahooMessenger 7.5 (Kopete serait le seul a ce jour).
- Support des conférences.
- Support complet du carnet d'adresse Yahoo.
MSN
- Notification d'alerte.
- Transfert de fichier dans les 2 sens avec les clients officiels MSN 7.5.
- Quelques corrections sur l'envoi et la réception de la webcam.
Oscar (AIM+ICQ)
- Prise en charge des "Chat Room".
- Meilleur prise en charge des encodages de caractères dans Oscar.
Demain
Pour KDE4, Kopete évoluera bien sûr au niveau des protocoles, VOIP et sur l'interface, mais également sur la possibilité d'une version Windows et Mac.
Vous pouvez contribuer dès aujourd'hui en réalisant des paquets de la 0.12 pour votre distribution favorite, créant ou partant des thèmes en XHTML/css, ou en codant bien sûr.
Aller plus loin
- Kopete (4 clics)
- Icones et thèmes (2 clics)
- Thèmes Adium (1 clic)
# smileys
Posté par Smarter . Évalué à 9.
Parce qu'édité un fichier xml à la main c'est pas très user-friendly...
[^] # Re: smileys
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 10.
Bref, faudrait que quelqu'un se motive pour le faire ;)
[^] # Re: smileys
Posté par Gof (site web personnel) . Évalué à 9.
Ça avais même été inclus dans le SVN
Mais comme il y avais des bugs et d'autres problèmes, et que celui qui avais coder ça ne le maintenais pas, et que personne d'autre ne voulais résoudre les problèmes, ça a été retiré peu avant KDE 3.5.
# Quand ?
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Quand ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 7.
Les distribs aurait par contre tout interet a inclure cette version, elle est bien bien mieux, plus puissante, plus simple à utiliser, et sans régressions connus par rapport à 0.11.x.
[^] # Re: Quand ?
Posté par Gof (site web personnel) . Évalué à 10.
En théorie, la règle chez KDE c'est : "Pas de nouvelle fonctionalité dans une version mineur"
Mais comme la prochaine version majeure (KDE4) est dans longtemps, quelques exceptions sont autorisées.
http://lists.kde.org/?l=kde-core-devel&m=114304642132670(...)
Les conditions pour qu'une fonctionalité soit ajouté à KDE 3.5 sont donc:
a) Ce doit être déjà dans KDE4
b) Il faut que ce soit déjà fini et complet
c) Déjà bien testé
d) Respecter le gel des messages pour les traducteur
e) ça doit être inclus au moins un moi avant la sortie de la version dans laquelle on veut la mettre
f) ça doit apparaître visiblement dans le changelog
g) ça doit être approuver par plusieurs mainteneurs
Dans le cas de Kopete:
a) c'est bon, le code a été fusionné avec kde4
b) et c) ok
d) Il faut espérer que il y ait encore un relâchement du gel des messages
e) et f) pas de problèmes
g) normalement ok sauf si il y a des objections
Mais il faut comprendre que ces règles sont pour des petites fonctionalité, alors que Kopete 0.12 en comporte beaucoup.
Donc en résumé, c'est possible, mais pas sûr et certainement pas dans l'immédiat.
[^] # Re: Quand ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Cette condition n'est franchement pas annodine, quand on connait les monstrueuses différences entre Qt3 et Qt4. Mais je ne sais pas si Kopete s'en soucie ou pas (cad s'il est entièrement au dessus de la libkde, ou même si la libkde4 a vu son API également profondément remaniée).
En tout cas, beau boulot !
[^] # Re: Quand ?
Posté par Gof (site web personnel) . Évalué à 5.
oui, les kdelibs ont vu leur API remaniée (profondément sur certains points) (Et l'API continue de changer)
Mais les merges restent relativement facile, il suffit de compiler et de corriger les erreurs. Surtout que les changement sont incrémentaux.
[^] # Re: Quand ?
Posté par Michaël Larouche . Évalué à 6.
En principe ça reste assez simple comme merge. Mais plus kdelibs4 avance, plus les merges créent des conflits, vu que certaines méthodes ont changé de nom. Celui que je vois le plus souvent c'est à cause de s/kdDebug/kDebug/g.
Donc, on fait un merge, répare les conflits, on compiler et on corrige les erreurs. Durant un bout je faisais les merges en même temps que la mise à jour de kdelibs4_snapshot, mais maintenant je préfère porter vers le nouveau snapshot après merger, surtout quand kdelibs a subit de gros changements (comme cette semaine le passage vers D-BUS)
# Gestion des thèmes Adium et interface
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 1.
Je suis très content de l'utilisation des thèmes Adium, car pour moi ce logiciel est le client de messagerie instantanée possèdant l'interface qui me convient le mieux (et que je crois être la plus agréable à utiliser), mais n'est disponible que pour OS X, ce que je trouve dommage. Mais si Kopete comble ce que j'estime être un manque, alors j'en serai très heureux :)
[^] # Re: Gestion des thèmes Adium et interface
Posté par Unchabin . Évalué à 2.
====>
[^] # Re: Gestion des thèmes Adium et interface
Posté par Michaël Larouche . Évalué à 2.
# Installer dès maintenant ? Klik ?
Posté par Nikoo . Évalué à 9.
http://klik.atekon.de/
http://kopete.klik.atekon.de/
# Multiples clients IM
Posté par HappyPeng . Évalué à 10.
[^] # Re: Multiples clients IM
Posté par billiob . Évalué à 10.
Beaucoup de clients IM vont s'y mettre (kopete, adium, aMSN, ....)
Ce sera basé sur D-Bus, et devrait permettre (en tout cas pour aMSN) d'avoir plus de protocols (ou une meilleure compatibilité avec ceux-ci), ainsi qu'une meilleure intégration de la webcam et de la VoIP grâce au projet Farsight.
[^] # Re: Multiples clients IM
Posté par Nÿco (site web personnel) . Évalué à 1.
http://delta.affinix.com/iris/
Utilisée dans Psi, mais aussi Kopete, et d'autres...
[^] # Re: Multiples clients IM
Posté par Michaël Larouche . Évalué à 4.
[^] # Re: Multiples clients IM
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 6.
Tu aurais pu rajouter que tu es en train de faire une lib équivalent pour MSN, qui s'appelle "papillon", et qui sera utilisé bien sur par kopete.
[^] # Re: Multiples clients IM
Posté par Michaël Larouche . Évalué à 9.
Comme moi par example, je déteste le C alors que j'adore le C++ avec Qt. Je me verrais utiliser et programmer sur une librairie sur lequel je déteste le langage de programmation.
Mais comme souligné, Telepathy est une solution, comme Tapioca, qui sont tous les deux assez similaires.....
Dans le cas de Kopete, je crois qu'on va offrir nos plugins de protocoles dans Telepathy et réutiliser ceux qu'on n'a pas mais offert dans Telepathy (ex: SIP). Note qu'on est pas encore décidé là dessus
[^] # Re: Multiples clients IM
Posté par stephwww . Évalué à 1.
Et le C++ sans QT ?
[^] # Re: Multiples clients IM
Posté par Sebastien Binet . Évalué à 5.
[^] # Re: Multiples clients IM
Posté par TImaniac (site web personnel) . Évalué à 7.
Oué enfin les wrappers ca sert à ca quand même... La plupart des langages modernes sont orientés procédural et objet, permettant de partager le concept d'API d'une manière relativement consensuelle indépendament du langage.
Tu crois que ceux qui développe en pyQt aime le C++ ?
Le langage est un moyen d'expression à l'écriture du code. A l'exécution on partage tous un langage commun : les instructions machines, même si certains patterns liés au langage de plus haut niveau utilisé sont encore visible, les wrappers sont là pour les cacher.
Alors oui, avoir plusieurs implémentation ca peut parfois être utile (différentes approches, émulation, alternative, etc.), mais l'excuse du langage de programmation est bidon à mon sens.
[^] # Re: Multiples clients IM
Posté par kahal (site web personnel) . Évalué à 6.
Perso, jamais je ne participerais au développement d'une bibliothèque écrit en C ou pire... en perl.
[^] # Re: Multiples clients IM
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 5.
Or Michael / DarkShock touche directement à la libiris (Jabber, créé/utilisé aussi par PSI) et développe actuellement une librairie équivalente pour MSN, qui sera utilisé dans Kopete 1.0, et utilisable par d'autres (elle est conçu en ce sens).
[^] # Re: Multiples clients IM
Posté par Gof (site web personnel) . Évalué à 10.
Ça permet d'avoir aussi des client simple protocol. (probablement plus intuitif quand on utilise que un protocole)
(Ou alors des "connectionmanager" dans le modèle télépathy)
De plus, pourquoi vouloir créé 1000 client multi-IM ?
Les client multi IM ne sont qu'une solution transitoire, avant que le seul et unique vrai protocol d'IM ne soit généralisé. (vous aurez deviné de quel protocol je parle :-þ )
[^] # Re: Multiples clients IM
Posté par Aiua . Évalué à 1.
MSN ? :D
PS: désolé, c'était trop tentant :o
[^] # Re: Multiples clients IM
Posté par Thomas Douillard . Évalué à 5.
[^] # Re: Multiples clients IM
Posté par Aiua . Évalué à 2.
[^] # Re: Multiples clients IM
Posté par WH (site web personnel) . Évalué à 8.
Et dans les ténèbres les lier
Au pays de MSN...
Brrr...
[^] # Re: Multiples clients IM
Posté par elviento . Évalué à 4.
Au tout début il y avait ICQ, qui était pour l'époque génial (transfert de fichier, visualisation de la frappe de son correspondant en temps réel, look sympa, moteur de recherche de users, ...).
Il était seul ou presque sur le marché des IM.
Mais il n'a évolué que pour devenir une usine à gaz, trop complexe, les traductions localisées ne sont arrivées que bien trop tard et surtout n'a pas suivi les évolutions simples que demandaient la grande majorité des utilisateurs...
Du coup tout le monde s'est tourné vers MSN qui était plus simple, plus complet, plus fun et surtout livré de base dans windows.
J'ai moi meme du abandonner à regret ICQ, tous mes contacts étant sur MSN.
Pourtant MSN est assez pourri, connexions instables, transfert de fichier impossible à reprendre après une interruption, bouffeur de ressources, message hors lignes inexistants (sauf dans la derniere version je crois) pour protéger hotmail, ...
Si on cherche un protocole simple et efficace Jabber est peut etre idéal mais pour le grand public il est encore loin de pouvoir convaincre une majorité de basculer de MSN vers son protocole...
Meme s'il faut distinguer le client du protocole, le grand public lui ne fait pas la difference.
Donc comme windows, MSN c'est pas terrible, mais faute de mieux et avec les strategies monopolistiques de M$ il est devenu incontournable...
MSN et les clients multiprotocoles ont encore de beaux jours devant eux.
[^] # Re: Multiples clients IM
Posté par oops (site web personnel) . Évalué à 4.
La France ne représente pas le monde :)
MSN n'est pas le leader dur marché et loin de là.
Le marché est très fragmenté entre AIM / MSN / Yahoo / Skype et dans une moindre mesure Jabber ( MacOS / Google ...)
[^] # Re: Multiples clients IM
Posté par lezardbreton . Évalué à 3.
[^] # Re: Multiples clients IM
Posté par oops (site web personnel) . Évalué à 2.
http://news.com.com/Yahoo,+Microsoft+join+IM+hands/2100-1025(...)
http://www.bigblueball.com/forums/general-im-news/34413-im-m(...)
# Je l'ais testé.
Posté par jijin . Évalué à 5.
Il marche tres bien, en plus des améliorations apportée on appréciera tout les petits trucs, les petits détails ici là dont principalement l'ajout de bouton et de menu sur la fenetre principale.
Je ne sais pas si c'est du à la compilation mais j'ai sentit une tres net amélioration de la rapidité du logiciel entre la 0.11 et 0.12.
Pour etre exact les améliorations n'ont rien de spectaculaire en soit mais rendent kopete bien plus pratique.
'fin.. bref... félicitations aux dévellopeurs. ;)
On pourrait peut etre esperer ceci :
-la possibilité de skinner la liste des contacts et/ou de l'integrer davantage à kde (liste de contact transparente et flottante...)
-utilisation automatisé des services en ligne comme image shack ou rapid share pour partager des fichiers (les transferts d'ordinateurs à ordinateurs état souvent lent et les services en ligne autorisant des tailles de fichiers toujours plus grandes).
-...
[^] # Re: Je l'ais testé.
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 5.
:D Oula, merci, content que cela se remarque :)))
Pour la rapidité, je penche pour la réécriture du moteur de theme, qui est beaucoup plus rapide, et prend moins de CPU/mémoire, surtout si tu utilisais un jolie theme graphique sous 0.11. Là, on peut remercier DarkShock (Michael Larouche), ici présent, il le mérite vraiment. Sur les grosses discutions avec un jolie thème et le groupement de messages, y'a pas photo, le jour et la nuit. Le moteur XSLT était le glouton CPU de l'application .
[^] # Re: Je l'ais testé.
Posté par Unchabin . Évalué à -10.
Je m'en fout de comment tu l'as installé, et je dois pas être le seul.
[^] # Re: Je l'ais testé.
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Du coup, je l'ai essayé. Et a priori, ça ne fait rien d'autre qu'un "configure && make && sudo make install" mais dans une fenêtre non ? (et en pouvant régler quelques options).
[^] # Re: Je l'ais testé.
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
(quel dommage qu'on puisse pas éditer ses posts :/)
[^] # Re: Je l'ais testé.
Posté par jijin . Évalué à 6.
A noter qu'un projet concurrent existe : Kompile, plus joli, plus "user friendly" encore.. mais qui a mystérieusement planté sur ma machine. (?)
Si ce genre de logiciel se dévellope ca pourrait etre un plus dans le sens où les logiciels fraichement mis en ligne pourrait être disponible pour tous, y compris ceux qui ne programment pas, n'y connaissent rien, etc. qui souvent doivent attendre les paquets pour leur distribution. Ce que j'en dis apres.. :)
# MSN et proxy
Posté par Ramón Perez (site web personnel) . Évalué à 2.
Alors que le bug est ouvert depuis 3 ans et qu'un patch avait été posté il y a un an (et que gaim le fait sans problème)
C'est dommage.
[^] # Re: MSN et proxy
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Il y a l'option dans la fenêtre des préférences MSN pourtant.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: MSN et proxy
Posté par P.-A. . Évalué à 4.
Le proxy http est configuré au niveau KDE.
[^] # Re: MSN et proxy
Posté par Ramón Perez (site web personnel) . Évalué à 4.
Le proxy http est configuré au niveau KDE.
Je trouve ça bizarre ce que tu dis, parce que j'ai longuement testé et ça ne marche pas chez moi, et sur les forums KDE et mailing-list kopete il y a plusieurs personnes qui ont le même problème :
tu as beau spécifier un proxy dans kcontrol, kopete ne l'utilise pas.
Le bugs est toujours ouvert d'ailleurs :
http://bugs.kde.org/show_bug.cgi?id=117012
[^] # Re: MSN et proxy
Posté par P.-A. . Évalué à 2.
Bizarrement je pensais que ct gaim qui se comportait bizarrement via mon proxy http.
[^] # Re: MSN et proxy
Posté par Gmooron . Évalué à 2.
Je suis en cité U, et on a un proxy http en 8080, et Kopete, à mon grand désarroi n'a jamais fonctionné à travers le proxy
# Paquet pour Dapper
Posté par anakin . Évalué à 1.
http://blog.thelinuxfr.org/index.php?2006/06/03/22-kopete-01(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.