Gof a écrit 2224 commentaires

Moi aussi, j'ai utilisé tous mes votes de hier et d'aujourd'hui sur ce journal.
5.6 c'est une note exceptionelle pour un journal avec autant de commentaires.

Bon, plus que 1 après moi.
Et gare à celui qui dépasse :-þ !

Et GNU/Hurd...

Ou alors il avais pas envie de se rappeler le nombre de n ou de m, ou s'il faut mettre un a ou un e

(Bien s'il utilisais Konqueror et son correcteur orthographique, il aurais pas eu ce problème)

Moi je préfère le système une bibliothèque par protocole

Ç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 :-þ )

Mais alors il va être très difficile d'avoir une moyenne de 6.6

allez, plus que 6 !

Désolé pour le raccourci
Merci pour la précision

gnome se penche sur d-bus ?

petit historique:

Au commencement, il y avait Corba qui était utilisé pour la communication inter applications sous unix

Mais chez KDE, ils trouvaient CORBA bcp trop compliqué et lourd. Alors pour KDE2, il firent DCOP, une toute nouvelle technologie, avec beaucoup moins de fonctionalité que CORBA, mais beaucoup plus simple d'emploi.

Chez Gnome par contre il s'obstinèrent à vouloir utiliser Corba et firent donc Bonobo (une sur-couche à Corba si j'ai bien compris)

Plusieurs années plus tard les utilisateur et développeur de KDE sont très satisfait de DCOP. Quand à ceux de gnome, je pense qu'il regrettent le choix

Mais voilà, Gnome ne peut pas utiliser DCOP, car, par construction, il est limité à KDE et pas interopérable.
Et les développeurs (à la fois ceux de Gnome et KDE) qui discutaient à propos de freedesktop, ont eu l'idée de créé DBus, le successeur de DCOP.
https://listman.redhat.com/archives/xdg-list/2003-January/ms(...)
https://www.redhat.com/archives/message-bus-list/2002-Novemb(...)

A partir de là, le développement à commencé, mais KDE ne pouvait pas remplacer DCOP immédiatement, car D-BUS n'était pas encore stable comparé à DCOP, et que il ne pouvais pas cassé la compatibilité au long de la vie de KDE 3.

Retardé par rapport à quoi ?
Aucune date de sortie n'a encore été prévue pour KDE4

Et ce sera pas en 2006, ça c'est quasi sur.

On va tous crever, on va tous crever,
L'apocalypse nous attend et nous on fait la fête tout l'temps!

oui, Kopete est basé entièrement sur les kdelibs.
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.

Surtout que D-Bus a vraiment été construit et pensé par rapport à DCOP, c'est son digne successeur.

Il a été pensé en se basant sur l'expérience de DCOP, càd pas à partir de rien.
Et ils sont vraiment similaire, l'apprentissage sera aisé

Pour la pluspart des programme, les fonctions DCOP ont simplement été transformées en fonctions D-Bus

Quelqu'un avais déjà coder ça,
Ç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.

Probablement pas. Pas cette version en tout cas, mais peut être la version 0.12.1 ou 0.12.2

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.

N'ait donc pas peur,
on t'as dis que KDE4 ce sera mieux :-)

Le http://www. est auto-completé (flèche bas+enter) (uniquement si il n'y a pas d'url récente)

Et puis, tout les sites ne commencent pas par www : http://no-www.org/

Et la pluspart des sites que je visite sont en .org et pas en .com

Et quand on a "google j'ai de la chance" comme moteur par défaut, en général il y a plus besoin.

Mais pourquoi ne pas tout simplement utiliser Konqueror ?

Le projet reçoit 500$ que l'étudiant réussisse ou rate.
(si ils ont tout de même essayé de travailler avec l'étudient)
http://code.google.com/soc/mentorfaq.html#fails_final_code

Donc non: Si le mentor trouve que l'étudiant est un glandeur, voire un bon à rien, il n'a aucune raison de dire que ça a été bien fait. (autre la pitié pour l'étudiant)

Il me semble que ça n'a pas été préciser, mais erlang est libre , contrairement à Java (troll inside)

http://www.erlang.org/faq/x213.html#AEN235

À ce propos: Kopete peut rajouter lui aussi cet en-tête (mais n'en tient pas compte)

pyMSNt rajoute une en-tête JabberID: au messages MSN, et quand deux personnes se parlent au travers des transports, pyMSNt envoi un message avec le JabberID de notre correspondant.

C'est pas exactement ce que tu demande, mais ça résoud déjà le « ca permettrait de reconnaitre qui de nos contacts MSN a migré sur un compte Jabber »

Oui, KDE 3.5 devrais encore supporter gcc 2.95 et gcc 3.0
(mais gcc 3.3 est requis pour compiler KDE4)

De plus, il est en général assez facile de corriger les erreurs de compilation dû a une incompatibilité des compilateurs.

Par contre, faire compiler un programme écrit pour gstreamer 0.8 avec gstreamer 0.10 demande un réel travail (je pense)

d'abord, GCC c'est "GNU Compiler Collection" et le O et avant M dans GNOME.

Ensuite, KDE n'a rien à voir avec GNU. Bien que KDE tourne sous GNU/Linux et compile avec, il fonctionne aussi sur d'autre UNIX, et compile avec d'autres compilateurs.

Et puis, le G de GTK vient aussi (indirectement) de GNU, cela signifie-t-il que KDE devrais aussi utiliser GTK.
C'est le même G, à une indirection prêt qui fait que ton raisonnement tient plus ;)

tu voulais dire le contraire
kdelibs 3.5.2 (mars 2006) avec kdemdemultimedia 3.0.0 (avril 2002)


Et puis, dans le monde du logiciel libre, il y a aussi la compatibilité des sources.

Le principe est que un gars qui à écrit une petite appli kde pour KDE 3.0 en 2002 fonctionnera encore en 2006 sous KDE 3.5 sans devoir changer une ligne de code.

Par contre, une application écrite en 1999 pour KDE1.1 nécessitera de grosse modification pour fonctionner aujourd'hui. La solution est d'installer les kdelibs 1.1.1.
Il est tout à fait possible d'avoir plusieurs version des kdelibs installée simultanément, et c'est ce qui sera fait lors de la transition de kde3 vers kde4

Depuis KDE3.0 la compatibilité ascendante n'a pas été rompue
Le binaire d'une application compilée en 2002 pour KDE 3.0 fonctionne encore aujourd'hui avec les libraries de KDE 3.5, 4 ans plus tard

Si aRts avait été abandonné avant, une application KDE3.0 susceptible d'utiliser aRts n'aurait plus fonctionné.


Alors que la durée de vie des versions majeure de gstreamer est beaucoup plus courte (normale, on est au début, même pas encore en version 1.0)

- Oxygen est juste un thème d'icône (pas encore fini) qui est un candidat pour devenir le thème d'icône par défaut de KDE4.
Il n'y a là aucun objectif d'unification entre les différent desktop, mais le but est au contraire d'arriver à une charte graphique spécifique à KDE

- Certaines parties de Telepathy (protocole DBUS) seront utilisée dans KDE pour remplacer l'actuel KIMProxy (protocole DCOP), utilisé pour l'intégration entre KMail et Kopete par exemple.
(il n'est par contre pas question d'utiliser galago dans KDE, à priori)