Un autre probleme de la gentoo, c'est qu'elle evolue tres vite et que j'ai parfois des compilations qui foirent, parce que le developpeur a teste avec un systeme parfaitement a jour alors que j'ai quelques versions de retard.
Bon, tout d'abord, il faut preciser que rien n'est C++ friendly. Le C++ est un langage complexe, surtout quand on le taquine un peu.
> De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.
Ah ouai ? Je me demande comment fait KDE pour faire des bindings. Ca doit etre impossible puisqu'il y a besoin du langage C. Va dire ca au mecs qui font PyQt, java for Qt, Qt#, rubyQt, perlQt, il seront content de savoir qu'ils ont besoin de faire du C.
Tu peux interpreter ca comme le fait que je fais expres d'ignorer cet argument parce qu'il me parait plus bancal qu'autre chose.
Pour info, l'approche de KDE comme de Gnome sur les bindings c'est aujourd'hui d'avoir une espece de framework dynamique qui genere automatiquement les bindings. Seul le framework central est a maintenir.
> Le C++ à part être "C++ friendly" est assez limité dans ce domaine [des bindings]
La on rentre dans un debat d'expert. Si tu discutes avec des gens qui font les bindings dans KDE et dans Gnome, tu pourras te faire ta propre opinion. La mienne (suite a ce genre de discussion), c'est que l'apparente facilite de generer des bindings en C cache une grande complexite, notamment au niveau de la maintenance. La syntaxe plus complexe et plus expressive du C++ permet une meilleure approche automatisee, tant au niveau de la generation que de la maintenance.
Ah, je realise qu'il y en effet une grosse confusion de ma part entre glib et gobject. C'est plutot gobject que je critique dans l'absolu.
> Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par
> dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?
C'est trolltech qui rajoute ca. En effet, ca peux sembler un bon argument. Cependant, au moment ou Trolltech a choisi d'ajouter des signaux, des slots et de proprietes aux objets C++, il n'y avait aucun equivalent sur le marche, a part vaguement java, mais qui conservait des performances catastrophiques.
Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.
> Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions »
C'est en etant tres selectif dans les technologies qu'il utilise qu'un projet etablit les bases technologiques de son succes. Ca vaut pour KDE (DCOP aui lieu de orbit), pour Gnome (orbit au lieu de mico), pour mozilla (un framework complet javascript ecrit pendant 3 ans avant de faire quoi que ce soit) et pour les autres.
On peut ne pas etre d'accord avec les choix faits, mais tu ne peux pas reprocher a un projet de choisir ses technologies soigneusement. Surtout quand il s'est deja plante une fois par le passe.
> Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...
Ca ne ressort pas dans mes posts, mais personellement, je suis pour l'utilisation de la glib pour tout projet en C. Parce que si tu ne l'utilises pas, tu vas finir par la recoder tout de meme.
> > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder
> Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...
Je pensais a gobject. Pour la glib, je ne pense pas qu'il y aie de difference. D'ailleurs, quand on regarde sous les QList, on voit des grosses optimisations typiques du C (et vas-y que je te malloc tout ca et que je me deplace avec des additions sur les pointeurs).
> Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser
Un naif qui s'est fait avoir. Honnetement, je pense que le consensus dans KDE est d'avoir du code propre. Apres, ca donnes des interpretations differentes sur les moyens d'arriver a ce but. Ce qui est sur, c'est qu'un mec qui recode glib a la main sera encore moins bien vu (en tout cas pour moi) puisqu'il choisit de code vite fait un truc qui existe deja et est plus stable.
Pour ce qui concerne dbus, il me semble qu'il utilise glib mais qu'il embarque les sources directement. Comme ca, pas de problemes de dependance. Il me semble que c'est aussi ce qui avait ete envisage avec arts.
Je ne penses pas que les conversions glib <-> Qt aient un impact majeur dans ce cas precis. Mais il faut penser au contexte general. Si KDE commence a se lier avec glib, quelles vont etre les consequences. Est-ce que d'autres applications vont l'utliiser aussi, etc.
> Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx =
> developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.
C'est pas tant la glib elle-meme qui est critiquee que le fait qu'elle fasse doublon avec d'une part la stl, d'autre part la QTL.
D'un point de vue personnel, j'admire beaucoup le travail qui a ete fait sur la glib, mais je ne vois pas du tout son interet. Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ? Pourquoi faire du C objet ? Sincerement, j'aime bien coder en C, mais quand je code en C, c'est pas pour faire du C++, c'est pour faire du C. Il y a quand meme une grosse incoherence dans ce choix, qui d'un cote preconise un langage relativement simple et refuse absoluement le C++, et de l'autre cote, s'amuse a refaire un framework objet en C. Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder. On n'en arrive meme a la situation de gtkmm qui wrappe en C++ une lib en C qui emule un comportement objet. Deux niveaux d'indirections !
> Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly
La glib n'est pas du tout C++ friendly. Elle permet en revanche aux programmeurs gnome de programmer dans un style objet, ce qui est tres souhaitable pour une appli graphique ou tu manipules des tonnes d'objets.
> KDE n'est pas C friendly
Non. Et tu sais quoi ? Ca ne manque a personne.
> > toute dependance n'est jamais la bienvenue
J'aurai de preciser toute dependance qui duplique une fonctionnalite existante. En dehors de l'approche gstreamer, quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?
Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.
Oui, enfin la theorie du compilateur, c'est que les options d'optimisations affectent la vitesse d'execution mais pas le resultat en lui-meme. Dans quelques cas, c'est vrai que si tu utilises -fmachin -fbidule -O27 -archoptimise-a-more , tu peux avoir quelques instabilites que n'a pas celui qui compile en -O2, mais ca ne va pas tres loin.
On n'est pas du tout dans la situation que tu as l'air de decirre, ou chaque mec a des options de compile differentes et obtiens un resultat stable differamment.
Personellement, je trouve tes commentaires assez penible a lire, non pas pour leur contenu, mais parce qu'on dirait que tu t'obstines a ne pas vouloir comprendre ce que disent les autres. C'est comme si tu avais pose un jugement sur les opinions de telle ou telle personne et que tu ne puisses pas envisager qu'il pense autre chose.
> Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.
> 2 - Gstreamer à l'origine cible Gnome.
C'est plus du tout le cas. Et il est aussi tres populaire chez KDE. De toute facon, une appli qui marche est toujours plus populaire qu'une appli qui ne marche pas.
> 1 - Gstreamer utilise glib.
J'ai deja explique pourquoi pour des raisons techniques, ca posait des problemes: il faut traduire toutes les structures de donnees echangees entre glib et KDE et ca a un cout CPU.
Ensuite, il faut voir qu'il y a des gens qui n'ont pas glib sur leur PC, tout comme il y a des gens qui n'ont pas Qt sur leur PC. Toute dependance supplementaire n'est _jamais_ bienvenue.
> "j'avance et tu recule, je tourne à droite et je regarde à gauche..
On parle et tu refuses d'ecouter, je pense que tu es aussi tres fort a ce jeu.
Utiliser un langage qui s'execute pour stocker des donnes statiques, c'est tres risque. Tu vas faire tourner l'interpreteur lua juste pour lire ton fichier de conf ? Donc on peut faire un virus lua qu'on glisse dans ton fichier de conf !
Pour ce cas precis, il n'y a aucune raisons pour laquelles les informations confidentielles auxquelles il a eu acces ne le soient plus aujourd'hui. C'est pas comme si il avait eu acces a des informations publiques a l'avance.
En plus, je soupconne que la seule raison pour laquelle philips ne veut pas rendre ce code open source, c'est parce que avec un algo de compression, ils vont se faire attaquer de toute part par des mecs qui ont des brevets sur tout et n'importe quoi. C'est moins risque de garder le code close source.
A mon avis il se goure. J'ai jamais vu de NDA expirer et j'en signe environ un tous les deux mois depuis 18 mois. Ce qui expire, c'est le droit d'echanger des informations confidentielles. Les informations confiendtielles restent confidentielles.
> Oui, mais si on fournit à la communauté le source du pilote, celle-ci (la communauté) s'occupera de le maintenir à jour, nan?
Non!
En fait, si, ca arrive parfois. Mais c'est aleatoire, il faut pas croire que si tu mets un logiciel open source, une horde de programmeur va se jeter dessus pour y contribuer. Il faut un ensemble de conditions complexes pour arriver a recuperer des contributeurs.
Desole, mais t'as rien compris. La partie sous GPL, c'est pwc. La partie close source n'est pas sous GPL (pwcx) et c'est elle qui est le sujet du probleme et sur laquelle il faudra faire de l'inginerie renversee.
J'ai jamais vu de NDA arriver a echeance. A mon avis, il a mal lu le papier. Les dates limites de NDA disent qu'apres la date limite, on ne peut plus s'echanger d'informations confidentielles et qu'il faut renouveler le NDA. Les informations echangees precedemment restent confidentielles.
Bon, l'inconveninent, c'est que c'est pour du python. Par contre, c'est vraiment extremement simple a utiliser (moins d'1h pour faire mon premier programme utile avec).
Sinon, je suis tout a fait de l'avis de Yves plut haut:
- pour un fichier de config, xxx=yyy suffit largement et se parse avec un e regexp. Plus c'est simple, plus ca marche: KISS
- pour un exemple un poil plus elabore, mieux vaut plonger directement dans du xml bien que ce soit un peu verbeux plutot que d'ecrire son propre langage.
J'ajouterai plusieurs choses:
- pour stocker des fichiers de conf, on trouve un certain nombre de lib disponible de nos jours pour faire ca de facon beaucoup plus robuste que ce qu'on obtient en le faisant juste "comme ca"
- les fichiers a la .ini sont a mon avis un modele tres simple a utiliser et tres efficace. C'est ce qui est utilise pour stocker tous les parametres de config de KDE.
Faut voir que ecrire une grammaire reste une operation complexe qui doit etre reservee a des besoins hyper specifiques.
Faut aussi dire que a vue de nez, supporter un driver sous linux demande 3 a 4 fois plus de boulot que sous windows [1]. Non seulement linux est un OS minoritaire, mais en plus il demande plus de resources internes pour s'en occuper. C'est vraiment pas motivant pour les constructeurs. Quand bien meme ils font un effort avec un driver close source, ils se font jeter aussi.
Il faut pas rever, avec une politique comme ca, linux ne sera jamais supporte sur tous les materiels.
[1]: linus pete l'architecture du noyau et des drivers tous les un ou deux ans, mais c'est juste pour l'ameliorer, c'est pas pour faire chier tous les utilisateurs et les mainteneurs qui n'ont que ca a faire.
A mon avis, il y avait d'autres moyens de supporter son decompresseur close source. Mais comme c'est pas sa premiere anicroche avec le noyau, il a jete l'eponge (ou la serviette pour rester plus anglophile). Independamment du super travail qu'il a acompli, il semble quand meme assez bute sur les differents moyens de modifier la facon dont son travail s'integre au noyau.
En fait, c'est pas tout a fait aussi simple. pwc s'etait deja fait allume parce qu'il utilisait une algo de decompression dans le kernel, ce qui etait considere comme un code devant reste en user space. Alan Cox avait a cette epoque fait sauter le driver une premiere fois si je me souviens bien, petant tous les logiciels utilisant une webcam avec un patch de 10 lignes.
Je pense que l'auteur est pas tout a fait objectif mais il n'en reste pas moins le resultat. Un perte nette pour tout utilisateur de linux.
> Maintenant la question est de savoir si il y a les specs complete de la cam
> et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
La reponse est non. Un algorithme de compression proprietaire, je doute que tu arrives a faire de reverse- engineering dessus, surtout quant le mec le plus competent ne peut plus travailler dessus.
Il s'agit donc d'une perte nette de toute webcam utilisant un chipset philips, c'est a dire une tres grosse majorite. Par exemple, j'ai une logitech sur mon bureau qui ne marchera plus.
> Mais ce que tu dis plus haut pour MAS est :
> > une page web de 10 lignes. C'est d'ailleurs comme ca qu'a mon avis, il est arrive la.
Cette derniere phrase est deplacee, je me suis emporte. Quand j'ai vu que c'etait un wiki, j'ai un peu tilte mais MAS est bien un projet qui a ete valide par freedesktop donc sur ce point-la, tu as raison.
> Puisque tu es sur la mailing, demande pourquoi arts (et/ou esd) n'est pas sur freedesktop alors qu'il y a déjà gstreamer/MAS.
Je n'ai pas envie de le faire pour de nombreuses raisons, mais voici les reponses que j'imagine (qui refletent notre point de vue different sur la question):
- parce qu'il n'a pas demande
- parce qu'il n'est plus developpe
- parce arts n'a pas ou n'a plus la vocation d'etre un serveur de son universel
> Et je n'ai toujours pas un exemple de "vrai" doublon sur freedesktop.
Je t'epargne immodule for Qt qui n'a pas l'air redondant avec les precedents.
Je suis curieux de voir ce que tu vas me repondre :-)
Je relis les objectifs de freedesktop et rien ne s'oppose a ce que deux projets concurrents soient heberges:
<<
# Collect existing specifications, standards, and documents related to X desktop interoperability and make them available in a central location;
# Promote the development of new specifications and standards to be shared among multiple X desktops;
# Integrate desktop-specific standards into broader standards efforts, such as Linux Standard Base and the ICCCM;
# Work on the implementation of these standards in specific X desktops;
# Serve as a neutral forum for sharing ideas about X desktop technology;
# Implement technologies that further X desktop interoperability and free X desktops in general;
# Promote X desktops and X desktop standards to application authors, both commercial and volunteer;
# Communicate with the developers of free operating system kernels, the X Window System itself, free OS distributions, and so on to address desktop-related problems;
# Provide CVS, web hosting, mailing lists, and other resources to free software projects that work toward the above goals.
>>
> Tu noteras qu'il n'y a aucun (du moins à ma connaissance) projet
> réellement concurrent sur freedesktop du type.
Certe. Il y a quand meme des projets aux contours concurrents : gsreamer vs mas, scim vs afterchinput.
Ensuite, il y a deux facons d'interpreter cet etat de fait:
- ta version : c'est une volonte deliberee parce que des choix ont ete faits
- ma version : c'est parce que deux projets concurrents promtteurs et utils ne se sont pas encore presentes
> Du moins pour Philippe Fremy :-). En tout cas il est beaucoup plus ambigu.
Desole si je suis ambigu. J'ai beaucoup de respect pour freedesktop en tant que projet puisque c'est a mon sens le futur de linux sur le desktop: il est clair qu'aucun projet de desktop fonctionnera a lui tout seul et que les utilisateurs de KDE/Gnome font tourner des applis Gnome, KDE, OpenOffice, Mozilla et consorts.
J'ai encore plus de respect pour les gens qui y parlent car ce sont des pointures de chacun des projets et ils connaissent bien leur sujet. C'est un plaisir des les voir parler du fonctionnement des desktop.
On voit aussi qu'il reste beaucoup beaucoup de problemes a resoudre pour avoir le niveau d'integration qu'on peut avoir couramment sous windows.
> Tu dis que gstreamer et MAS sont équivalents, ce qui est faux.
J'ai jamais dit une chose pareille. Ce que j'ai dit, c'est que freedesktop etait susceptible d'accepter des projets concurrents.
Je le faisais en reponse a un message qui repondait a un message qui disait que MAS, c'etait la meme chose.
> Plus loin tu dis que gstreamer n'est pas sur freedesktop, ce qui est faux encore.
Je me suis emporte dans mon argumentation et j'ai dit que il y avait pas de gstreamer sur freedesktop, en effet. Comme je suis pas trop familier avec gstreamer, j'ai oublie ca. Donc j'ai dit une connerie sur gstreamer, ok. Par contre, je suis relativement familier avec freedesktop que je suis de pres ou de loin selon les periodes.
> Tu dis qu'être sur freedesktop c'est très facile
Tout a fait. cf gtk-qt-engine qui est rentre en une journee, ou le dernier projet admis, qui est il me semble un systeme pour rentrer du chinois sur X qui a ete admis aussi tres tres rapidement. Je suis la mailing-list donc je sais de quoi je parle.
> si un projet est sur freedesktop ça n'a pas de signification importante.
Ca, c'est ce que je m'evertue a vous faire comprendre que je ne dis pas: ca a beaucoup d'importance, mais pas autant que vous en accordez. La comparaison avec le LSB est pas mal. Quand un choix est fait par le LSB, il a ete tres longuement discute. Sur freedesktop, quand un projet est admis, il y a eu au moins deux ou trois mails pour en discuter, mais il se peut que ce soit tout (ce qui fut le cas du projet de compoisition de caracteres chinois dont je parlais).
<< Note que c'est un wiki, donc quand je veux gstreamer et arts ont le meme niveau de soutien de la part de freedesktop que mas: une page web de 10 lignes. C'est d'ailleurs comme ca qu'a mon avis, il est arrive la. >>
Ce que j'essaye de vous faire comprendre, c'est qu'il est facile de faire admettre un projet sur freedesktop, du moment que ca corresponde vaguement aux buts d'interoperatbilites. L'hebergement est facile a obtenir. Si Stefan Westerfield demandait a faire admettre arts ici en disant qu'il prefere le developper sur le site web de freedesktop, je suis sur que ca passerait.
> btw, j'attends toujours que tu ajoutes arts sur freedesktop ...
Pourquoi faire ? Pour prouver que j'ai raison ? Je n'en vois pas l'interet, surtout que arts a toujours ete un projet de loser.
En ce qui me concerne, je suis quelqu'un avec une opinion differente de la tienne, et je defends cette opionion dans une discussion. C'est tout.
Note que je fonde mon opinion sur freedesktop en etant abonne a la mailnig list depuis a peu pres 1 an, c'est pas comme si je parlais juste en l'air. J'ai ete surpris aussi la premiere fois ou j'ai vu un projet se faire admettre en 3 mails mais il y a eu une discussion depuis sur le sujet sur la ML qui a clarifie ce choix.
[^] # Re: Debian ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
Un autre probleme de la gentoo, c'est qu'elle evolue tres vite et que j'ai parfois des compilations qui foirent, parce que le developpeur a teste avec un systeme parfaitement a jour alors que j'ai quelques versions de retard.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 2.
> De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.
Ah ouai ? Je me demande comment fait KDE pour faire des bindings. Ca doit etre impossible puisqu'il y a besoin du langage C. Va dire ca au mecs qui font PyQt, java for Qt, Qt#, rubyQt, perlQt, il seront content de savoir qu'ils ont besoin de faire du C.
Tu peux interpreter ca comme le fait que je fais expres d'ignorer cet argument parce qu'il me parait plus bancal qu'autre chose.
Pour info, l'approche de KDE comme de Gnome sur les bindings c'est aujourd'hui d'avoir une espece de framework dynamique qui genere automatiquement les bindings. Seul le framework central est a maintenir.
> Le C++ à part être "C++ friendly" est assez limité dans ce domaine [des bindings]
La on rentre dans un debat d'expert. Si tu discutes avec des gens qui font les bindings dans KDE et dans Gnome, tu pourras te faire ta propre opinion. La mienne (suite a ce genre de discussion), c'est que l'apparente facilite de generer des bindings en C cache une grande complexite, notamment au niveau de la maintenance. La syntaxe plus complexe et plus expressive du C++ permet une meilleure approche automatisee, tant au niveau de la generation que de la maintenance.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
> Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par
> dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?
C'est trolltech qui rajoute ca. En effet, ca peux sembler un bon argument. Cependant, au moment ou Trolltech a choisi d'ajouter des signaux, des slots et de proprietes aux objets C++, il n'y avait aucun equivalent sur le marche, a part vaguement java, mais qui conservait des performances catastrophiques.
Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.
> Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions »
C'est en etant tres selectif dans les technologies qu'il utilise qu'un projet etablit les bases technologiques de son succes. Ca vaut pour KDE (DCOP aui lieu de orbit), pour Gnome (orbit au lieu de mico), pour mozilla (un framework complet javascript ecrit pendant 3 ans avant de faire quoi que ce soit) et pour les autres.
On peut ne pas etre d'accord avec les choix faits, mais tu ne peux pas reprocher a un projet de choisir ses technologies soigneusement. Surtout quand il s'est deja plante une fois par le passe.
> Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...
Ca ne ressort pas dans mes posts, mais personellement, je suis pour l'utilisation de la glib pour tout projet en C. Parce que si tu ne l'utilises pas, tu vas finir par la recoder tout de meme.
> > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder
> Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...
Je pensais a gobject. Pour la glib, je ne pense pas qu'il y aie de difference. D'ailleurs, quand on regarde sous les QList, on voit des grosses optimisations typiques du C (et vas-y que je te malloc tout ca et que je me deplace avec des additions sur les pointeurs).
> Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser
Un naif qui s'est fait avoir. Honnetement, je pense que le consensus dans KDE est d'avoir du code propre. Apres, ca donnes des interpretations differentes sur les moyens d'arriver a ce but. Ce qui est sur, c'est qu'un mec qui recode glib a la main sera encore moins bien vu (en tout cas pour moi) puisqu'il choisit de code vite fait un truc qui existe deja et est plus stable.
Pour ce qui concerne dbus, il me semble qu'il utilise glib mais qu'il embarque les sources directement. Comme ca, pas de problemes de dependance. Il me semble que c'est aussi ce qui avait ete envisage avec arts.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 6.
> Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx =
> developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.
C'est pas tant la glib elle-meme qui est critiquee que le fait qu'elle fasse doublon avec d'une part la stl, d'autre part la QTL.
D'un point de vue personnel, j'admire beaucoup le travail qui a ete fait sur la glib, mais je ne vois pas du tout son interet. Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ? Pourquoi faire du C objet ? Sincerement, j'aime bien coder en C, mais quand je code en C, c'est pas pour faire du C++, c'est pour faire du C. Il y a quand meme une grosse incoherence dans ce choix, qui d'un cote preconise un langage relativement simple et refuse absoluement le C++, et de l'autre cote, s'amuse a refaire un framework objet en C. Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder. On n'en arrive meme a la situation de gtkmm qui wrappe en C++ une lib en C qui emule un comportement objet. Deux niveaux d'indirections !
> Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly
La glib n'est pas du tout C++ friendly. Elle permet en revanche aux programmeurs gnome de programmer dans un style objet, ce qui est tres souhaitable pour une appli graphique ou tu manipules des tonnes d'objets.
> KDE n'est pas C friendly
Non. Et tu sais quoi ? Ca ne manque a personne.
> > toute dependance n'est jamais la bienvenue
J'aurai de preciser toute dependance qui duplique une fonctionnalite existante. En dehors de l'approche gstreamer, quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?
Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.
[^] # Re: Debian ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
On n'est pas du tout dans la situation que tu as l'air de decirre, ou chaque mec a des options de compile differentes et obtiens un resultat stable differamment.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
> Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.
> 2 - Gstreamer à l'origine cible Gnome.
C'est plus du tout le cas. Et il est aussi tres populaire chez KDE. De toute facon, une appli qui marche est toujours plus populaire qu'une appli qui ne marche pas.
> 1 - Gstreamer utilise glib.
J'ai deja explique pourquoi pour des raisons techniques, ca posait des problemes: il faut traduire toutes les structures de donnees echangees entre glib et KDE et ca a un cout CPU.
Ensuite, il faut voir qu'il y a des gens qui n'ont pas glib sur leur PC, tout comme il y a des gens qui n'ont pas Qt sur leur PC. Toute dependance supplementaire n'est _jamais_ bienvenue.
> "j'avance et tu recule, je tourne à droite et je regarde à gauche..
On parle et tu refuses d'ecouter, je pense que tu es aussi tres fort a ce jeu.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
[^] # Re: mon avis
Posté par Philippe F (site web personnel) . En réponse à la dépêche Utiliser lex et yacc dans vos programmes C/C++. Évalué à 2.
[^] # Re: mais quel gâchis !!!
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 6.
En plus, je soupconne que la seule raison pour laquelle philips ne veut pas rendre ce code open source, c'est parce que avec un algo de compression, ils vont se faire attaquer de toute part par des mecs qui ont des brevets sur tout et n'importe quoi. C'est moins risque de garder le code close source.
[^] # Re: Le NDA a expiré !!
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
[^] # Re: pas cool :/
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
Non!
En fait, si, ca arrive parfois. Mais c'est aleatoire, il faut pas croire que si tu mets un logiciel open source, une horde de programmeur va se jeter dessus pour y contribuer. Il faut un ensemble de conditions complexes pour arriver a recuperer des contributeurs.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
[^] # Re: mais quel gâchis !!!
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 9.
[^] # Re: Treecc
Posté par Philippe F (site web personnel) . En réponse à la dépêche Utiliser lex et yacc dans vos programmes C/C++. Évalué à 6.
http://theory.stanford.edu/~amitp/Yapps/(...)
Bon, l'inconveninent, c'est que c'est pour du python. Par contre, c'est vraiment extremement simple a utiliser (moins d'1h pour faire mon premier programme utile avec).
Sinon, je suis tout a fait de l'avis de Yves plut haut:
- pour un fichier de config, xxx=yyy suffit largement et se parse avec un e regexp. Plus c'est simple, plus ca marche: KISS
- pour un exemple un poil plus elabore, mieux vaut plonger directement dans du xml bien que ce soit un peu verbeux plutot que d'ecrire son propre langage.
J'ajouterai plusieurs choses:
- pour stocker des fichiers de conf, on trouve un certain nombre de lib disponible de nos jours pour faire ca de facon beaucoup plus robuste que ce qu'on obtient en le faisant juste "comme ca"
- les fichiers a la .ini sont a mon avis un modele tres simple a utiliser et tres efficace. C'est ce qui est utilise pour stocker tous les parametres de config de KDE.
Faut voir que ecrire une grammaire reste une operation complexe qui doit etre reservee a des besoins hyper specifiques.
[^] # Re: pas cool :/
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 5.
Il faut pas rever, avec une politique comme ca, linux ne sera jamais supporte sur tous les materiels.
[1]: linus pete l'architecture du noyau et des drivers tous les un ou deux ans, mais c'est juste pour l'ameliorer, c'est pas pour faire chier tous les utilisateurs et les mainteneurs qui n'ont que ca a faire.
[^] # Re: Autre solution: hors kernel ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
Je pense que l'auteur est pas tout a fait objectif mais il n'en reste pas moins le resultat. Un perte nette pour tout utilisateur de linux.
[^] # Re: pwc vs pwcx
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 6.
> et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
La reponse est non. Un algorithme de compression proprietaire, je doute que tu arrives a faire de reverse- engineering dessus, surtout quant le mec le plus competent ne peut plus travailler dessus.
Il s'agit donc d'une perte nette de toute webcam utilisant un chipset philips, c'est a dire une tres grosse majorite. Par exemple, j'ai une logitech sur mon bureau qui ne marchera plus.
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 2.
On remettra ca une prochaine fois.
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 2.
> > une page web de 10 lignes. C'est d'ailleurs comme ca qu'a mon avis, il est arrive la.
Cette derniere phrase est deplacee, je me suis emporte. Quand j'ai vu que c'etait un wiki, j'ai un peu tilte mais MAS est bien un projet qui a ete valide par freedesktop donc sur ce point-la, tu as raison.
> Puisque tu es sur la mailing, demande pourquoi arts (et/ou esd) n'est pas sur freedesktop alors qu'il y a déjà gstreamer/MAS.
Je n'ai pas envie de le faire pour de nombreuses raisons, mais voici les reponses que j'imagine (qui refletent notre point de vue different sur la question):
- parce qu'il n'a pas demande
- parce qu'il n'est plus developpe
- parce arts n'a pas ou n'a plus la vocation d'etre un serveur de son universel
> Et je n'ai toujours pas un exemple de "vrai" doublon sur freedesktop.
J'aimerai alors avoir ton opinion eclairee sur les projets suivants:
- uim : projet pour rentrer differents caracteres sous X, comme le coreen, le chinois, le japonais, ... : http://www.freedesktop.org/Software/uim(...)
- ChiX : projet rentrer des caracteres chinois sous X : http://www.freedesktop.org/Software/ChIX(...)
- scim : projet pour rentrer des caracteres dans n'importe quelle langue comlexe (chinois, coreen, ....) http://www.freedesktop.org/Software/ScimIntroduction(...)
Je t'epargne immodule for Qt qui n'a pas l'air redondant avec les precedents.
Je suis curieux de voir ce que tu vas me repondre :-)
Je relis les objectifs de freedesktop et rien ne s'oppose a ce que deux projets concurrents soient heberges:
<<
# Collect existing specifications, standards, and documents related to X desktop interoperability and make them available in a central location;
# Promote the development of new specifications and standards to be shared among multiple X desktops;
# Integrate desktop-specific standards into broader standards efforts, such as Linux Standard Base and the ICCCM;
# Work on the implementation of these standards in specific X desktops;
# Serve as a neutral forum for sharing ideas about X desktop technology;
# Implement technologies that further X desktop interoperability and free X desktops in general;
# Promote X desktops and X desktop standards to application authors, both commercial and volunteer;
# Communicate with the developers of free operating system kernels, the X Window System itself, free OS distributions, and so on to address desktop-related problems;
# Provide CVS, web hosting, mailing lists, and other resources to free software projects that work toward the above goals.
>>
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 2.
> réellement concurrent sur freedesktop du type.
Certe. Il y a quand meme des projets aux contours concurrents : gsreamer vs mas, scim vs afterchinput.
Ensuite, il y a deux facons d'interpreter cet etat de fait:
- ta version : c'est une volonte deliberee parce que des choix ont ete faits
- ma version : c'est parce que deux projets concurrents promtteurs et utils ne se sont pas encore presentes
> Du moins pour Philippe Fremy :-). En tout cas il est beaucoup plus ambigu.
Desole si je suis ambigu. J'ai beaucoup de respect pour freedesktop en tant que projet puisque c'est a mon sens le futur de linux sur le desktop: il est clair qu'aucun projet de desktop fonctionnera a lui tout seul et que les utilisateurs de KDE/Gnome font tourner des applis Gnome, KDE, OpenOffice, Mozilla et consorts.
J'ai encore plus de respect pour les gens qui y parlent car ce sont des pointures de chacun des projets et ils connaissent bien leur sujet. C'est un plaisir des les voir parler du fonctionnement des desktop.
On voit aussi qu'il reste beaucoup beaucoup de problemes a resoudre pour avoir le niveau d'integration qu'on peut avoir couramment sous windows.
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 3.
J'ai jamais dit une chose pareille. Ce que j'ai dit, c'est que freedesktop etait susceptible d'accepter des projets concurrents.
Je le faisais en reponse a un message qui repondait a un message qui disait que MAS, c'etait la meme chose.
> Plus loin tu dis que gstreamer n'est pas sur freedesktop, ce qui est faux encore.
Je me suis emporte dans mon argumentation et j'ai dit que il y avait pas de gstreamer sur freedesktop, en effet. Comme je suis pas trop familier avec gstreamer, j'ai oublie ca. Donc j'ai dit une connerie sur gstreamer, ok. Par contre, je suis relativement familier avec freedesktop que je suis de pres ou de loin selon les periodes.
> Tu dis qu'être sur freedesktop c'est très facile
Tout a fait. cf gtk-qt-engine qui est rentre en une journee, ou le dernier projet admis, qui est il me semble un systeme pour rentrer du chinois sur X qui a ete admis aussi tres tres rapidement. Je suis la mailing-list donc je sais de quoi je parle.
> si un projet est sur freedesktop ça n'a pas de signification importante.
Ca, c'est ce que je m'evertue a vous faire comprendre que je ne dis pas: ca a beaucoup d'importance, mais pas autant que vous en accordez. La comparaison avec le LSB est pas mal. Quand un choix est fait par le LSB, il a ete tres longuement discute. Sur freedesktop, quand un projet est admis, il y a eu au moins deux ou trois mails pour en discuter, mais il se peut que ce soit tout (ce qui fut le cas du projet de compoisition de caracteres chinois dont je parlais).
<< Note que c'est un wiki, donc quand je veux gstreamer et arts ont le meme niveau de soutien de la part de freedesktop que mas: une page web de 10 lignes. C'est d'ailleurs comme ca qu'a mon avis, il est arrive la. >>
Ce que j'essaye de vous faire comprendre, c'est qu'il est facile de faire admettre un projet sur freedesktop, du moment que ca corresponde vaguement aux buts d'interoperatbilites. L'hebergement est facile a obtenir. Si Stefan Westerfield demandait a faire admettre arts ici en disant qu'il prefere le developper sur le site web de freedesktop, je suis sur que ca passerait.
> btw, j'attends toujours que tu ajoutes arts sur freedesktop ...
Pourquoi faire ? Pour prouver que j'ai raison ? Je n'en vois pas l'interet, surtout que arts a toujours ete un projet de loser.
> T'es un trolleur de première.
Je t'encourage a chercher ce qu'est un troll sur le web:
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oi=defm(...)
En ce qui me concerne, je suis quelqu'un avec une opinion differente de la tienne, et je defends cette opionion dans une discussion. C'est tout.
Note que je fonde mon opinion sur freedesktop en etant abonne a la mailnig list depuis a peu pres 1 an, c'est pas comme si je parlais juste en l'air. J'ai ete surpris aussi la premiere fois ou j'ai vu un projet se faire admettre en 3 mails mais il y a eu une discussion depuis sur le sujet sur la ML qui a clarifie ce choix.
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 2.