gnumdk a écrit 7492 commentaires

Je sais pas ce qu'il en est pour Ubuntu.

Par contre, j'étais passé sous Kubuntu avec la hoary (mise à jours de kde régulières) et j'en étais très content.

J'ai testé la breezy, ben machine arrière, retour sous cette bonne vieille Debian.
Pourquoi? Parce que leur Kde est patché, ils ont introduit des bugs non présents dans Kde. J'ai envoyé un mail sur le ml de devel, pas de réponse.

J'ai quitté Mandrake parce que Kde était trop patché à mon gout, j'arrête kubuntu pour la meme raison.

Euh, t'as pas du bien comprendre le principe de pmount ;)

Avec Kde 3.4 + hal + pmount, il ne faut AUCUNE entrée dans ton fstab!
C'est le principe meme de pmount.

Et la tu pourras te foutre royalement de l'ordre de connexion des périphs.
Par contre, pour être sur que ca marche, il faut que tu ne vois pas les périphs dans media:/ avant leur connexion, sinon, c'est que y'a une couille dans ta conf.

Mais les administrateurs Windows 2k* sont souvent des gens pas très sérieux ;)

apt-setup fera l'affaire ;)

sauf dcop et ksyscoca qui sont vitaux pour une appli kde, le premier gérant les messages et le second la conf de kde et du logiciel.

C'est vrai que j'ai du mal à comprendre pourquoi gnome met en avant les serveurs réseau si ca ne fonctionne pas.

Je viens de faire le test avec un serveur sftp, je crée mon "serveur" sur le bureau, je me connecte. Deja, nautilus rame comme un malade(en comparaison avec konqueror), je clic sur la premiere image que je vois, eog se lance et se fige.

C'est vraiment pas classe.

Autre chose, quand je me connect à un serveur distant et que ca rame, le boutton stop ne fonctionne pas :/

Ah, si, le premier qui me dit comment virer le tooltip sur les applis gnome, je, je, euh, nan rien...

Les services sous kde, ils se désactivent, ca aide pour avoir un truc plus rapide à se lancer ;)

Tu peux le faire via kcontrol.

Mwai, c'est bien beau ca, maintenant on va voir les faits.

Retour en arriere, Kde 2.2 par exemple, bon environnement, mais peu de logiciels. De l'autre coté, y'avais Gnome 1.4 avec une orgie de logiciels en gtk plus ou moins intégrés à Gnome.

En clair, sous Kde, t'avais pas trop le choix, 70% de tes applis était en gtk. Ben j'ai pas essayé longtemps l'experience du Kde sur les pc des gens à qui je mettais linux, la premier remarque était: "Mais pourquoi les applications sont pas pareil?", "Pourquoi c'est pas la meme présentation?", "Pourquoi le raccourcis clavier marche pas pareil?".

Resultat, j'ai fini par mettre du gnome à tout les gens chez qui je mettais GNU/Linux.

J'avoue que moi meme, je n'arrivais pas à passer à Kde à cause de ca.

Maintenant, les choses on bient évoluées, Kde a maintenant une appli pour presque tout, Gnome aussi, il y'a donc peu de raison de vouloir faire un mix d'applications, surtout que cela n'apporte que de l'incohérence pour l'utilisateur de base.

>Résultat à peu près équivalent, mais avec moins de code.

C'est vrai que ca doit être ultra violent de faire un menu avec cd, cp , mv, ln et d'envoyer un message via dcop à la konsole.

Désolé de la réponse, c'est juste au cas ou ton "moins de code" était un argument du genre "c'est moins bloated" ;)

Effectivement y'a du mieux, déja, le fait de pouvoir mettre des chansons en attente de lecture, c'est vraiment un truc qui rend amaroK indispensable! :) (surtout en random)

Sinon, je pense que le truc qui me soule dans ce logiciel, c'est de pas avoir une colonne "Morceaux" et que ca soit la playlist qui fasse office de selecteur de morceaux. C'est uniquement ca que je trouve merdique ainsi que le fait de pas pouvoir faire du drag & drop dans la playlist pour aménager l'ordre des morceaux.

Surement que tu as tendances à écouter un album d'un groupe dans un genre particulier, mais pour une gestion de la playlist puissante, me dit pas que rhythmbox est efficace ;)

Il a pas dit ca ;) Il a dit que dans konqueror, quand tu fais "show terminal emulator", il te lance un terminal certe dans le repertoire courant, mais que si tu te déplaces avec konqueror dans l'arbo, le terminal suis tout seul comme un grand et va ou konqueror va.

Sinon, y'a toujours moyen de faire F4 pour ouvrir un terminal dans le rep courant sans que ce dernier soit lié à konqueror.

Mwai, enfin comparer amaroK et Rhythmbox, faut en vouloir quand meme.

J'ai rarement vu un logiciel aussi peu utilisable que Rhythmbox, à l'opposé de tout ce qu'il se fait sous gnome.

La gestion de la playlist est vraiment horrible, shift + click, on pert un temps à vouloir mettre ce que l'on veut écouter, c'est de la folie.

>Je fais un journal sur une astuce pour Firefox, on met parle de la mort de Mr
>Bronson et du TCE

Je pense que le commentaire en question était de l'humour indiquant que ton journal était vraiment d'un grand intéret ;)

Nan, parce que les bookmarks dynamiques, c'est pas du tout le truc dont on a parlé 1500 fois sur ce site ;)

>C'est aussi le gravage qui est payant, tu bosses gratos toi ?

A lille3, j'ai un pote qui le fait gratos :p Bon, c'est ptet parce qu'il est pas encore fonctionnaire :D .
hein benodilo ;)

Bah, j'ai travaillé dans une fac, les postes ont OpenOffice, les salles d'accès libre sont soit sous Linux soit en double boot Windows/Linux, et de plus, les étudiants peuvent amener un cdr/rw afin qu'on leur grave un cd avec OpenOffice, Firefox, Thunderbird, Gimp, ...

Donc bon, rien de bien extraordinaire tout ca ;)

Ah oui, on apprend aussi aux étudiants à installer GNU/Linux ;)
C'est une fac de lettres.

Je ne donnerai pas son nom, je l'ai déja fait un demi douzaine de fois ici ;)

L'interet, c'est d'avoir une abstraction grossiere, de ne plus avoir des hacks immonde dans OpenOffice pour avoir une boite de dialogue d'ouverture de fichier gtk ou kde.

C'est pas de tranformer une appli gtk en une appli kde, juste que l'ouverture/sauvegarde de fichier, impression soit standard dans toutes les applis!

Mais il n'y pas que ca, enfin, il suffit d'aller lire les deux liens, y'a un schema...

Non, le xml, ca sera un truc qui dit d'affichier une boite d'ouverture de fichier standard, c'est tout.

C'est juste demander à un service d'afficher des boites de dialogue et/ou de renvoyer des informations. Mais celui qui sait comment afficher les boites de dialogues, c'est le desktop service.

En clair, on définit des services que doivent implémenté les différents desktop, on les implémente dans un desktop services et on les appelle à travers dbus.

>c'est bien qu'il y a une abstraction.

Il parlais d'abstraction des librairies gnome et kde...

>J'ai furieusement l'impression que tu me prend pour un idiot.

Non, il y'a un grande différence entre être idiot et avoir toujours raison.
Si tu comprends pas que c'est chiant d'expliquer 10 fois la meme chose :(

Pour la AFL, ce que tu dis n'est plus vrai, c'est d'ailleurs pour ca qu'elle a été choisi dans dbus:

COPYING: switch to Academic Free License version 2.1 instead of
2.0, to resolve complaints about patent termination clause.

"AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose whatsoever, including to create derivative works. "

"Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision."

Ensuite, pour tes histoires de protocole, je comprend pas du tout ou tu veux en venir...

>alors ta spécification du protocole seras un travail dérivé, sous GPL.

Jamais rien vu de tel dans la GPL.
Mais bon, ce que tu dis est bidon, l'auteur du soft fait ce qu'il veut du protocole, il en fait une spec avant si il veut. De toute facon ca sera surement un truc freedesktop si ca voit le jour...

>Ce projet là a clairement pour but d'exporter les fonctions de Gnome et de
>KDE

Bon, t'en a pas plein le cul de raconter des conneries comme ca? Va falloir te le dire combien de fois qu'il exporte aucune fonction gnome ou kde? Que le logiciel qui utilisera des fonctions gnome ou kde sera sous GPL! Que envoyer un message à une application ca n'implique aucune licence. Les données envoyées et recus par des applications ne sont pas dépendantes de la licence du logiciel qui les envoie!

Alors une derniere fois, je te la fais en tres clair, genre si je devais expliquer à ma mere.

Application A (linké à libRuDI)
Application B (linké à Kde ou Gnome ou ...)

A veut ouvrir un fichier, A envoie un message aux services du bureau: "Je veux ouvrir un fichier de type pdf!"
B(le desktop services) ouvre une boite de dialogue et laisse l'utilisateur séléctionner un fichier. B envoie à A le path de ce fichier.

Voila, tu comprends bien la que seule B doit etre sous GPL et que le fait d'envoyer 3 lignes de XML à une applications GPL ne force pas à écrire du code GPL!

Ayé, compris?

"Here at openSUSE.org, you'll find a community of developers, end users and other open source enthusiasts who all have the same goal in mind. We work together to create and distribute the world's most usable Linux."

Donc, ton "Du fait que Suse et Novell developpent a rideaux fermes" n'est plus vraiment vrai, je ne sais pas par contre si maintenant opensuse est aussi ouverte qu'une fedora ou une mandriva.

Vous le faites expres :) C'est un complot :)

RuDI ne fera que donner des ordres à un gestionnaire de service. Si j'ai bien compris, c'est au desktop d'implémenter ce dernier.

En clair, ils vont développer une petit lib pour envoyer et recevoir des messages XML via dbus, ils vont définir les différents messages, et apres, le reste sera codé au niveau des différents desktop. Il ne s'agit en aucun cas d'abstraction!

Je retire ce que je viens de dire, j'ai lancé un troll sur #kde-devel.

En fait, il semble que Kde utilise le Qt GPL.

"So if you want to write a non-copylefted application, release it under
the X11 license, and link it with a GPL-covered library, that is
allowed. The linked executable would be covered by the GPL, of
course, but the app source code would be covered by the X11 license
alone."

Voila pourquoi le kicker est sous BSD et kdelibs sous LGPL.

Désolé pour cette explication foireuse(QPL), mais elle était pas de moi :-)

L'AFL et la BSD sont compatibles! Or, dbus laisse le choix entre GPL et AFL.

>Hors la librairie client a été conçue avec le serveur et dans le seul et unique
>but de se connecter à lui.

Non, il n'y aura pas de connexion, juste des échanges de messages à travers d-bus.

>Mais l'auteur de RuDI a reconnu dès le départ que son but était d'exporter les
>fonctions de KDE et Gnome.

Mais ceci est totalement faux! Tu n'auras acces depuis la libRuDI à aucune fonction de gnome ou kde. Tu auras accès à des services :
-Ouvrir fichier
-Sauver fichier
-Imprimer
-Untel est il connecté?

En clair, tu ne feras que donner des ordres à une applications Kde sous GPL et elle te répondra via dbus. Je doute que tous les script DCOP qui donne des ordres à des applis Kde soient sous GPL ;)

Mais bon, de toute facon, meme si libRuDI était linké à Qt, cela ne serait pas un probleme ;)

Tu seras sans doute surpris de voir que les libs de kde sont sous LGPL et le kicker sous BSD!!! Alors qu'ils sont linké à Qt! Raison, la licence utilisé par Kde est la QPL et elle n'est pas copyleft, fin du débat :p