> il a dit que c'était caché dans gconf, et toi tu lui réponds que c'est pas caché parce que gconf est fourni en standard... Je suis désolé mais gconf est pour moi une cachette, au même niveau que le about:config de mozilla !
Désolé mais tu n'y comprends rien.
Si c'est ~/.kde je ne vais pas dire que c'est caché.
Si c'est stocké dans une base de donnée je ne vais pas dire que c'est caché.
GConf est une abstraction pour stocker des informations. Rien de plus.
GConf est connu et n'est pas confidentiel. Si tu as un cachette, tu vas faire en sorte qu'elle ne soit pas connue et tu ne vas pas communiquer sur cette cachette.
GConf n'est pas là pour cacher des choses. Gconf est utilisé pour _toutes_ les options. Aussi bien pour celles que le développeur veut rendre visible à l'utilisateur et celles qui sont utiles à quelques utilisateurs mais qu'on ne veut pas rendre visible à tout le monde pour éviter d'inutiles confusions. C'est l'appli qui masque des options et JAMAIS gconf. Donc on ne cache rien dans GConf.
GConf n'a _aucune_ notion de la visibilité d'une option. GConf retourne TOUTES les options et point barre.
La visibilité (pour l'utilisateur final) est défini par le développeur de l'appli et n'a rien à voir avec gconf.
Tu peux stocker ta configuration dans un fichier .ini et n'afficher qu'une partie des options du fichier .ini. Ça n'a rien à voir avec gconf ou les fichier .ini.
C'est une pratique courrante qui n'a rien à voir avec GConf. Lorsque tu utilises une interface graphique pour configurer le réseau et qui forcément ne te donne pas toutes les possibilités réseaux de Linux tu dis que les options réseaux de Linux sont cachée dans /etc ?
Pas moi.
Toutes les options sont visibles dans /etc. Et comme ce n'est pas une cachette je peux le dire et propager cette information.
> Je te laisse expliquer à un ami qui utilise firefox sous linux pourquoi Outils > Options s'est barré là dedans
Tu le fais exprès ?
Firefox n'est pas une appli Gnome !
T'imprimes ou pas ?
Sinon expliques nous aussi comment Firefox est mal intégré à KDE pour être complet.
> gnome avait un équivalent à gstreamer ? Non
> à DBUS ? Non
> à HAL ? Non
KDE n'a pas d'équivalent à gstreamer. gstreamer gère la video et arts non. Gstreamer peut lire tous type de flux (mp3, ogg, mpeg, etc) arts n'est qu'un serveur de son (+ un peu de processing). Gnome a aussi un serveur de son et depuis très longtemps.
KDE n'a pas d'équivalent à DBUS. DBUS est niveau système (il y a un daemon) et KDE n'a pas de communication niveau système.
KDE n'a pas d'équivalent à HAL.
> KDE avait tous les outils remplissant ces tâches plus ou moins bien.
Framework multimedia sous KDE (je ne parle pas d'un serveur de son) ? => Non
Bus de communication système ? => Non
Gestionnaire de périphérique et configuration à la volé du système ? => Non
> aller hop, on remballe tout et on recode tout avec les nouvelles technos, et adieu la compatibilité" ?
Qui demande ça ? Personne. Gnome utilise DBus/etc pour des domaines où il y avait une plusvalue. DBus/etc n'a rien remplacé dans Gnome même si ça peut remplacé des éléments de Gnome (Orbit notamment). Et Gnome ne se sent pas obligé de remplacer des éléments par Dbus uniquement pour ...
Tiens au fait pourquoi ?
Alors si Gnome ne vois pas pourquoi le faire, pourquoi tu veux que KDE se sente obligé de le faire ?
Que KDE implément Dbus uniquement pour les qualités spécifiques de DBus. Ça sera parfait.
> HAL sera utilisé dans KDE 3.4
Es-ce que ça remplacera quelque chose de KDE ?
Je ne crois pas et je n'y vois aucun problème. Au fait pour utiliser HAL il faut Dbus.
> DBUS sera utilisé dans KDE 4 car ils vont pouvoir briser la compatibilité binaire, ce qui n'est pas "permis" lors du passage kde 3.3 -> 3.4 par exemple.
T'es veut bien m'expliquer ça ?
Je veux dire la compatibilité binaire.
Gnome utilise DBus dans Gnome 2.8 et il y a compatibilité source et binaire pour tous les gnome 2.x.
Si KDE a pris la décision d'utiliser DBus pour remplacer leur propre fonctionnalité (donc incompatibilité binaire) ça les regarde et j'ai rien contre (ni pour).
[^] # Re: Avis d'un kdeiste
Posté par morgendorffer . En réponse au journal KDE ou Gnome? (pas de troll). Évalué à -2.
Désolé mais tu n'y comprends rien.
Si c'est ~/.kde je ne vais pas dire que c'est caché.
Si c'est stocké dans une base de donnée je ne vais pas dire que c'est caché.
GConf est une abstraction pour stocker des informations. Rien de plus.
GConf est connu et n'est pas confidentiel. Si tu as un cachette, tu vas faire en sorte qu'elle ne soit pas connue et tu ne vas pas communiquer sur cette cachette.
GConf n'est pas là pour cacher des choses. Gconf est utilisé pour _toutes_ les options. Aussi bien pour celles que le développeur veut rendre visible à l'utilisateur et celles qui sont utiles à quelques utilisateurs mais qu'on ne veut pas rendre visible à tout le monde pour éviter d'inutiles confusions. C'est l'appli qui masque des options et JAMAIS gconf. Donc on ne cache rien dans GConf.
GConf n'a _aucune_ notion de la visibilité d'une option. GConf retourne TOUTES les options et point barre.
La visibilité (pour l'utilisateur final) est défini par le développeur de l'appli et n'a rien à voir avec gconf.
Tu peux stocker ta configuration dans un fichier .ini et n'afficher qu'une partie des options du fichier .ini. Ça n'a rien à voir avec gconf ou les fichier .ini.
C'est une pratique courrante qui n'a rien à voir avec GConf. Lorsque tu utilises une interface graphique pour configurer le réseau et qui forcément ne te donne pas toutes les possibilités réseaux de Linux tu dis que les options réseaux de Linux sont cachée dans /etc ?
Pas moi.
Toutes les options sont visibles dans /etc. Et comme ce n'est pas une cachette je peux le dire et propager cette information.
> Je te laisse expliquer à un ami qui utilise firefox sous linux pourquoi Outils > Options s'est barré là dedans
Tu le fais exprès ?
Firefox n'est pas une appli Gnome !
T'imprimes ou pas ?
Sinon expliques nous aussi comment Firefox est mal intégré à KDE pour être complet.
> gnome avait un équivalent à gstreamer ? Non
> à DBUS ? Non
> à HAL ? Non
KDE n'a pas d'équivalent à gstreamer. gstreamer gère la video et arts non. Gstreamer peut lire tous type de flux (mp3, ogg, mpeg, etc) arts n'est qu'un serveur de son (+ un peu de processing). Gnome a aussi un serveur de son et depuis très longtemps.
KDE n'a pas d'équivalent à DBUS. DBUS est niveau système (il y a un daemon) et KDE n'a pas de communication niveau système.
KDE n'a pas d'équivalent à HAL.
> KDE avait tous les outils remplissant ces tâches plus ou moins bien.
Framework multimedia sous KDE (je ne parle pas d'un serveur de son) ? => Non
Bus de communication système ? => Non
Gestionnaire de périphérique et configuration à la volé du système ? => Non
> aller hop, on remballe tout et on recode tout avec les nouvelles technos, et adieu la compatibilité" ?
Qui demande ça ? Personne. Gnome utilise DBus/etc pour des domaines où il y avait une plusvalue. DBus/etc n'a rien remplacé dans Gnome même si ça peut remplacé des éléments de Gnome (Orbit notamment). Et Gnome ne se sent pas obligé de remplacer des éléments par Dbus uniquement pour ...
Tiens au fait pourquoi ?
Alors si Gnome ne vois pas pourquoi le faire, pourquoi tu veux que KDE se sente obligé de le faire ?
Que KDE implément Dbus uniquement pour les qualités spécifiques de DBus. Ça sera parfait.
> HAL sera utilisé dans KDE 3.4
Es-ce que ça remplacera quelque chose de KDE ?
Je ne crois pas et je n'y vois aucun problème. Au fait pour utiliser HAL il faut Dbus.
> DBUS sera utilisé dans KDE 4 car ils vont pouvoir briser la compatibilité binaire, ce qui n'est pas "permis" lors du passage kde 3.3 -> 3.4 par exemple.
T'es veut bien m'expliquer ça ?
Je veux dire la compatibilité binaire.
Gnome utilise DBus dans Gnome 2.8 et il y a compatibilité source et binaire pour tous les gnome 2.x.
Si KDE a pris la décision d'utiliser DBus pour remplacer leur propre fonctionnalité (donc incompatibilité binaire) ça les regarde et j'ai rien contre (ni pour).