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.
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.
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.
>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!
"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.
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
J'en rajoute une couche, la meme chose expliqué par Martin Konold.
The small RuDI lib which will be available for each platform (Qt/Java/KDE/gtk/Mono) shall be available with a no strings attached BSD style license in order to facilitate wide spread use.
As the coupling of a RuDI enabled application with the desktop services does neither create a derivative work nor uses any kind of linking the license used for the desktop services don't affect the RuDI enabled application.
>Hors ce logiciel est clairement dérivé de KDE et Gnome (et tout ce qui s'en
>suit), et ne s'en cache pas .
Rah! Soit tu ne comprends pas le principe, soit tu ne comprends pas la GPL ;)
Si j'utilise RuDI dans mon logiciel proprio, il n'y aura pas UNE SEULE LIGNE DE CODE GPL dedans, il ne sera LIE AVEC AUCUNE LIBRAIRIE GPL (RuDI sera BSD), il ne fera qu'envoyer des messages XML à une autre entité qui elle sera sous la licence qui s'impose: GPL.
Que je sache, il est pas interdit à un soft sous licence BSD d'envoyer un message via dbus à un soft GPL?
C'est du client serveur, un client sous BSD, un serveur sous GPL.
Bon, tu vas le lire l'article ou tu le fais expres?
La librairie RuDI avec laquelle seront linkés les programmes n'aura AUCUN liens avec Qt! Les messages en XML seront gérés à travers d-bus.
Par exemple, et je dois beaucoup simplifier, Acrobat Reader dira via libRuDI: "Je veux ouvrir un fichier", un message sera envoyé via dbus et une boite de dialogue d'ouverture de fichier apparaitra.
Voila, si j'ai bien compris le principe est la, comment ca va marchait techniquement derriere, je n'en sais rien.
>Même si on unifiait la tête des boites de dialogues (qui personellement ne me
>perturbent pas), ça changerais pas grand chose.
Ben, non, c'est vrai que c'est pas du tout perturbant pour un utilisateur d'aller dans /media dans tel application, media:/ dans une autre, le tout avec 15 boites de dialogues différentes...
Après non, ca va pas transformer une appli Gnome en une appli Kde, le but est juste de garder une certaine cohérence entre les applis au sein d'un environnement particulier.
Mais une fois le look et les boites de dialogues unifiés, je peux te dire que les utilisateurs ne se poseront pas trop de question. D'ailleurs, pour l'unification du look, il y'a ce projet: http://kdelook.org/content/show.php?content=13010(...)
>Et même dans ce cas, si on utilise les boites de dialogues on utilise KIO, donc
>kio_kded et par là même hal, qui est sous GPL...
T'aurais pu aller lire l'article avant de tirer des conclusions... L'application proprio peut être écrit en Qt commercial, en Gtk, en Motif, on s'en fout, elle ne sera linké qu'avec RuDI(coté client) donc pas de problème de licence! RuDI sera lui sous licence BSD.
[^] # Re: Gnome s'améliore certes mais....
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 2.
Tu peux le faire via kcontrol.
[^] # Re: Gnome s'améliore certes mais....
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 5.
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.
[^] # Re: Affichage - > Afficher le terminal
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 4.
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" ;)
[^] # Re: Gnome s'améliore certes mais....
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 1.
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.
[^] # Re: Gnome s'améliore certes mais....
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 2.
[^] # Re: Affichage - > Afficher le terminal
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 4.
Sinon, y'a toujours moyen de faire F4 pour ouvrir un terminal dans le rep courant sans que ce dernier soit lié à konqueror.
[^] # Re: Gnome s'améliore certes mais....
Posté par gnumdk (site web personnel) . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 1.
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.
[^] # Re: RIP
Posté par gnumdk (site web personnel) . En réponse au journal Le saviez-vous ? les bookmarks dynamiques avec Firefox. Évalué à 6.
>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 ;)
[^] # Re: Acheter, c'est gratuit
Posté par gnumdk (site web personnel) . En réponse à la dépêche L'Université de Lausanne encourage les logiciels libres. Évalué à 2.
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 ;)
# En retard
Posté par gnumdk (site web personnel) . En réponse à la dépêche L'Université de Lausanne encourage les logiciels libres. Évalué à 6.
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 ;)
[^] # Re: à voir
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
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...
[^] # Re: à voir
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
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.
[^] # Re: à voir
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
Il parlais d'abstraction des librairies gnome et kde...
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 3.
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...
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 8.
>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?
# mwai
Posté par gnumdk (site web personnel) . En réponse au journal Test de la Suse 10.0 beta 4. Évalué à 3.
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.
[^] # Re: à voir
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 3.
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!
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
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 :-)
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
>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
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
The small RuDI lib which will be available for each platform (Qt/Java/KDE/gtk/Mono) shall be available with a no strings attached BSD style license in order to facilitate wide spread use.
As the coupling of a RuDI enabled application with the desktop services does neither create a derivative work nor uses any kind of linking the license used for the desktop services don't affect the RuDI enabled application.
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
>suit), et ne s'en cache pas .
Rah! Soit tu ne comprends pas le principe, soit tu ne comprends pas la GPL ;)
Si j'utilise RuDI dans mon logiciel proprio, il n'y aura pas UNE SEULE LIGNE DE CODE GPL dedans, il ne sera LIE AVEC AUCUNE LIBRAIRIE GPL (RuDI sera BSD), il ne fera qu'envoyer des messages XML à une autre entité qui elle sera sous la licence qui s'impose: GPL.
Que je sache, il est pas interdit à un soft sous licence BSD d'envoyer un message via dbus à un soft GPL?
C'est du client serveur, un client sous BSD, un serveur sous GPL.
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 1.
La librairie RuDI avec laquelle seront linkés les programmes n'aura AUCUN liens avec Qt! Les messages en XML seront gérés à travers d-bus.
Par exemple, et je dois beaucoup simplifier, Acrobat Reader dira via libRuDI: "Je veux ouvrir un fichier", un message sera envoyé via dbus et une boite de dialogue d'ouverture de fichier apparaitra.
Voila, si j'ai bien compris le principe est la, comment ca va marchait techniquement derriere, je n'en sais rien.
[^] # Re: Trop bien
Posté par gnumdk (site web personnel) . En réponse à la dépêche Balazar -- Arkanae II, les sceptres reforgés version 0.2. Évalué à 5.
Tu as essayé de contacter les gens qui avaient bossé sur le graphisme du premier voir si ils seraient motivés?
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . En réponse au journal RuDI, Intégration avec n'importe quel Bureau?. Évalué à 2.
>perturbent pas), ça changerais pas grand chose.
Ben, non, c'est vrai que c'est pas du tout perturbant pour un utilisateur d'aller dans /media dans tel application, media:/ dans une autre, le tout avec 15 boites de dialogues différentes...
Après non, ca va pas transformer une appli Gnome en une appli Kde, le but est juste de garder une certaine cohérence entre les applis au sein d'un environnement particulier.
Mais une fois le look et les boites de dialogues unifiés, je peux te dire que les utilisateurs ne se poseront pas trop de question. D'ailleurs, pour l'unification du look, il y'a ce projet: http://kdelook.org/content/show.php?content=13010(...)
>Et même dans ce cas, si on utilise les boites de dialogues on utilise KIO, donc
>kio_kded et par là même hal, qui est sous GPL...
T'aurais pu aller lire l'article avant de tirer des conclusions... L'application proprio peut être écrit en Qt commercial, en Gtk, en Motif, on s'en fout, elle ne sera linké qu'avec RuDI(coté client) donc pas de problème de licence! RuDI sera lui sous licence BSD.
# Trop bien
Posté par gnumdk (site web personnel) . En réponse à la dépêche Balazar -- Arkanae II, les sceptres reforgés version 0.2. Évalué à 4.
Content de voir que la nouvelle version est utilisable avec du logiciel libre uniquement!
Bonne continuation aux développeurs, le premier était un très bon jeu, je vais testé ca!
Y'a quand même un truc qui me choque, les graphismes étaient bien meilleurs dans le premier que dans celui ci!
http://www.linux-user.de/ausgabe/2001/10/012-software/arkanae.jpg(...)
http://home.gna.org/oomadness/images/balazar18.jpeg(...)