> Plus de la moitie des specs de freedsktop ont ete proposees par KDE
Exemple ?
> Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Je ne sais plus qui est à l'initiative des fichiers .desktop. Pour le window manager, c'est havoc (développeur Gnome, aussi à l'initiative de freedesktop avec Owen).
> Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
C'est-à-dire ?
KDE fait des propositions pour que des projets hébergés par freedesktop soient utiles à KDE. C'est normal et très bien venu.
Mais quel projet a été initialisé par KDE pour l'intéropérabilité ?
Spécification pour gestionnaire de fenêtre ? Non.
Dbus ? Non.
HAL ? Non.
Un API multimédia pour tous les desktops ? Non.
Quoi alors ? C'est la seconde fois que je pose la question.
> Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Ben les développeurs gtk/gnome proposent et font des choses. Oui parfois ça utilise glib. Du côté de KDE, il n'y a rien a reprocher car il ne propose rien. Fin de la parenthèse.
> Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne.
Tu veux dire que le dbus de KDE n'a pas de dépendance avec glib ?
Ben tu te trompes. Le dbus de KDE est une surcouche du dbus de freedesktop/gnome qui utilise glib (et il n'y a pas de quoi en faire un fromage). Et cette surcouche (la partie binding C++) est hébergée par freedesktop (où c'est d'ailleurs sa place).
Tu vas peut-être maintenant dire que KDE a sa propre implémentation de HAL ?
Je te donne tout de suite la réponse : Non.
> maintenant deux implementations de la partie client.
Non. KDE a fait une surcouche.
Si je me trompe (je n'ai pas vérifié), indique où sont les sources de l'implémentation de dbus par KDE.
> C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants.
C'est vrai mais ça ne change rien au problème. Gnome essai d'avoir et de développer des solutions utilisables par plusieurs desktops et KDE non.
> Gstreamer n'assure pas la compabilite binaire ni source entre version.
Comme tout le monde ?
Il y a compatibilité entre version X.Y.Z et X.Y.Z+1. pour Y pair. Tout les gstreamer 0.8.* sont compatibles avec gstreamer 0.8.0. Tout les gstreamer 0.10.* sont compatibles avec gstreamer 0.10.0.
L'incompatibilité de gstreamer 0.10 avec 0.8 est connue depuis le début de gstreamer 0.9 (la branche de développement de la version 0.10).
Dis moi si je me trompe, mais KDE 4 ne sera pas compatible avec KDE 3.
> C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire.
Puisque tu parles de dbus. Ben dbus n'avait jusqu'au 17/07/06 aucune garantie de compatibilité source et binaire et aussi entre versions mineurs. Cette compatibilité n'était pas leur soucis. Il y a maintenant un freeze de l'API/ABI pour la version 1.0. Tu as des garanties que cette API/ABI va durer toute la vie de KDE 4 ? NON ! Pas plus que pour l'API de gstreamer 0.10 ou 0.12.
Et je te l'annonce tout de suite pour que tu ne fasses pas un fromage la prochaine fois : gstreamer 0.12 sera incompatible gstreamer 0.10. Par contre personne ne sait quand sortir gstreamer 0.12. Dans un an ou 5, personne ne le sait. D'ailleur il n'y a pas de branche de développement de gstreamer 0.12 (pas de branche 0.11).
Pourtant KDE prend dbus mais refuse gstreamer au motif de la non stabilité de l'API.
On n'est pas dans le deux poids deux mesures ?
Et je ne te parle même pas de HAL où la situation est "pire" (notes les guillemets).
> Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien
Et si l'utilisateur passe de KDE 3 à KDE 4 ou Qt 3 à Qt 4 ou dbus 0.89 à 0.90, c'est le même problème. Il n'y a rien de nouveau sous le soleil, mais bizarrement les fans de KDE font une fixation sur gstreamer. On nage en plein troll.
Ces problèmes sont à gérer par les gestionnaires de paquet et ils font ça très bien et ils existent pour ça.
> (note que c'est le comportement a l'heure actuelle).
Absolument pas. Sous rpm (et probablement sous apt), la détection de require pour librairie est automatique. Un programme qui a besoin de gstreamer 0.8 aura automatiquement "require libgst*-0.8.so.0". gstreamer 0.8 a automatiquement "provide libgst*-0.8.so.0". gstreamer 0.10 n'a pas "provide libgst*-0.8.so.0" et donc si tu as un programme qui utilise gstreamer 0.8, la mise à jour vers gstreamer 0.10 sera automatiquement refusée a moins que le gestionnaire trouve un gstreamer 0.10 qu'il peut installer en parallèle avec gstreamer 0.8. Ce qui est exactement ce qui se passe aujourd'hui. Donc sur ta bécane tu peux avoir des programmes qui utilisent gstreamer 0.8, pardon gstreamer 0.8.* et gstreamer 0.10.*.
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Exemple ?
> Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Je ne sais plus qui est à l'initiative des fichiers .desktop. Pour le window manager, c'est havoc (développeur Gnome, aussi à l'initiative de freedesktop avec Owen).
> Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
C'est-à-dire ?
KDE fait des propositions pour que des projets hébergés par freedesktop soient utiles à KDE. C'est normal et très bien venu.
Mais quel projet a été initialisé par KDE pour l'intéropérabilité ?
Spécification pour gestionnaire de fenêtre ? Non.
Dbus ? Non.
HAL ? Non.
Un API multimédia pour tous les desktops ? Non.
Quoi alors ? C'est la seconde fois que je pose la question.
> Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Ben les développeurs gtk/gnome proposent et font des choses. Oui parfois ça utilise glib. Du côté de KDE, il n'y a rien a reprocher car il ne propose rien. Fin de la parenthèse.
> Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne.
Tu veux dire que le dbus de KDE n'a pas de dépendance avec glib ?
Ben tu te trompes. Le dbus de KDE est une surcouche du dbus de freedesktop/gnome qui utilise glib (et il n'y a pas de quoi en faire un fromage). Et cette surcouche (la partie binding C++) est hébergée par freedesktop (où c'est d'ailleurs sa place).
Tu vas peut-être maintenant dire que KDE a sa propre implémentation de HAL ?
Je te donne tout de suite la réponse : Non.
> maintenant deux implementations de la partie client.
Non. KDE a fait une surcouche.
Si je me trompe (je n'ai pas vérifié), indique où sont les sources de l'implémentation de dbus par KDE.
> C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants.
C'est vrai mais ça ne change rien au problème. Gnome essai d'avoir et de développer des solutions utilisables par plusieurs desktops et KDE non.
> Gstreamer n'assure pas la compabilite binaire ni source entre version.
Comme tout le monde ?
Il y a compatibilité entre version X.Y.Z et X.Y.Z+1. pour Y pair. Tout les gstreamer 0.8.* sont compatibles avec gstreamer 0.8.0. Tout les gstreamer 0.10.* sont compatibles avec gstreamer 0.10.0.
L'incompatibilité de gstreamer 0.10 avec 0.8 est connue depuis le début de gstreamer 0.9 (la branche de développement de la version 0.10).
Dis moi si je me trompe, mais KDE 4 ne sera pas compatible avec KDE 3.
> C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire.
Puisque tu parles de dbus. Ben dbus n'avait jusqu'au 17/07/06 aucune garantie de compatibilité source et binaire et aussi entre versions mineurs. Cette compatibilité n'était pas leur soucis. Il y a maintenant un freeze de l'API/ABI pour la version 1.0. Tu as des garanties que cette API/ABI va durer toute la vie de KDE 4 ? NON ! Pas plus que pour l'API de gstreamer 0.10 ou 0.12.
Et je te l'annonce tout de suite pour que tu ne fasses pas un fromage la prochaine fois : gstreamer 0.12 sera incompatible gstreamer 0.10. Par contre personne ne sait quand sortir gstreamer 0.12. Dans un an ou 5, personne ne le sait. D'ailleur il n'y a pas de branche de développement de gstreamer 0.12 (pas de branche 0.11).
Pourtant KDE prend dbus mais refuse gstreamer au motif de la non stabilité de l'API.
On n'est pas dans le deux poids deux mesures ?
Et je ne te parle même pas de HAL où la situation est "pire" (notes les guillemets).
> Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien
Et si l'utilisateur passe de KDE 3 à KDE 4 ou Qt 3 à Qt 4 ou dbus 0.89 à 0.90, c'est le même problème. Il n'y a rien de nouveau sous le soleil, mais bizarrement les fans de KDE font une fixation sur gstreamer. On nage en plein troll.
Ces problèmes sont à gérer par les gestionnaires de paquet et ils font ça très bien et ils existent pour ça.
> (note que c'est le comportement a l'heure actuelle).
Absolument pas. Sous rpm (et probablement sous apt), la détection de require pour librairie est automatique. Un programme qui a besoin de gstreamer 0.8 aura automatiquement "require libgst*-0.8.so.0". gstreamer 0.8 a automatiquement "provide libgst*-0.8.so.0". gstreamer 0.10 n'a pas "provide libgst*-0.8.so.0" et donc si tu as un programme qui utilise gstreamer 0.8, la mise à jour vers gstreamer 0.10 sera automatiquement refusée a moins que le gestionnaire trouve un gstreamer 0.10 qu'il peut installer en parallèle avec gstreamer 0.8. Ce qui est exactement ce qui se passe aujourd'hui. Donc sur ta bécane tu peux avoir des programmes qui utilisent gstreamer 0.8, pardon gstreamer 0.8.* et gstreamer 0.10.*.