Rentrée des classes pour GNOME 2.16 - LinuxFr.org\nPosté par tuiu pol le 07/09/06 à 10:31 . Évalué à 8.\nA noter aussi un journal sur le sujet avec qq autres liens : https://linuxfr.org/~plagiats/22587.html\nPosté par patrick_g (page perso) le 07/09/06 à 11:08 . Évalué à 6.\n>> On notera au passage l'arrivée d'une application en C# (Tomboy), qui officialise la dépendance de GNOME sur Mono et sur le binding GTK#\nTomboy est un utilitaire pour prendre des notes (une sorte de post-it electronique). Les versions précédentes de Gnome avaient pourtant l'utilitaire Sticky Notes qui répondait exactement au même besoin alors pourquoi changer ? Si Tomboy a une ou deux fonctions en plus alors pourquoi ne pas améliorer plutôt Sticky Notes ?\nLe résultat c'est une dépendance à Mono. C'est très lourdingue et en plus juridiquement j'ai pas confiance.\nEt tout ça n'est visiblement que le début d'une déferlante d'applications Mono : On parle déjà de l'arrivée de F-Spot dans la prochaine Ubuntu alors que GThumb (déjà présent) est une appli extraordinaire !\nC'était bien la peine que les devs de Gnome du début bavent sur Qt et KDE et affirment que le C c'était ce qu'il y a de mieux.\nInutile de dire que je vais sérieusement tester le liveCD de la prochaine Kubuntu pour voir si je ne pourrais pas me faire à KDE et pouvoir ainsi switcher.\nPatrick_g, un probable futur ex-gnomiste.\nPosté par zerbro le 07/09/06 à 11:13 . Évalué à 8.\nTu sais, personne ne t'oblige a utiliser tomboy. Si sticky Notes te convient, il est encore la.\nJ'utilise tomboy que je trouve extremement pratique contrairement a sticky note. Les developpeurs de tomboy utilisent le langage de leur choix, si C# avec mono leur permet de developper plus vite, tant mieux pour eux.\nEnsuite, comparer F-spot a gthumb, c'est osé. Ce n'est *pas du tout* le meme type d'application. Et gthumb continue d'exister.\nBref, le seul truc qui change, c'est que tomboy et mono font officiellement parti de gnome.\nEnfin si tu veux passer à KDE, libre a toi.\nPosté par patrick_g (page perso) le 07/09/06 à 11:42 . Évalué à 0.\n>> comparer F-spot a gthumb, c'est osé. Ce n'est *pas du tout* le meme type d'application\nC'est _exactement_ le même type d'application.\nBien sur il y a certaines fonctions présentes chez l'un et pas chez l'autre et inversement mais rien de fondamental.\nSinon plus généralement : bien evidemment je peux toujours modifier Gnome pour avoir ce que je veux mais à la longue ça va vite devenir lourd surtout si la tendance se poursuit. Virer Tomboy pour avoir Sticky Notes à la place; Remplacer F-Spot par GThumb; Enlever Banshee et mettre Rhythmbox; Arreter Beagle...etc etc\nKDE 4 arrive et il n'y aucune incertitude juridique qui assombrit son code, il va y avoir un HIG officiel pour l'uniformité, le look sera terrible et la technologie au top. A mon avis les devs de Gnome ont fait une grosse erreur avec cet ajout de Mono controversé.\nPosté par TImaniac (page perso) le 07/09/06 à 11:57 . Évalué à 10.\nKDE 4 arrive et il n'y aucune incertitude juridique qui assombrit son code\nDire sans cesse qu'il y a des incertitudes avec Mono, on peut voir ca comme ca d'après Wikipedia :\n"Un FUD (de l'anglais Fear Uncertainty and Doubt, c'est-à-dire peur, incertitude et doute) est une technique classique de désinformation basée sur le schéma suivant :\nInstaller le doute,\nen s'appuyant sur la peur\nau moyen d'informations non vérifiables (incertitude)."\nBon alors moi je vais faire pareil : je suis sûr que KDE viole de nombreux brevets, il y a clairement là un risque juridique. Voilà, je ne te donne aucune information vérifiable.\nPar contre je peux te donner une information vérifiable : Mono est protégé par l'OpenInventiveNetwork qui est soutenu par des petits acteurs comme Novell, RedHat ou encore IBM et Philips.\nMoinssez moi si vous voulez vu que ca fait 100 fois que je me répète, mais bon, y'en a qui FUD pour la 100ème fois, c'est de bonne guerre :)\nPosté par boubou (page perso) le 07/09/06 à 12:11 . Évalué à 10.\nAh, ah, je suis de retour de vacances, on va pouvoir troller !\nCe que j'adore avec toi, Timaniac, c'est que tu ne fais que répéter servillement la propagande de De Icaza. Jamais aucune investigation personnelle... Pourtant, chercher des brevets sur le site de l'USPTO, c'est facile http://www.uspto.gov/\nJe peux donc te donner moi aussi une information vérifiable : Microsoft possède au moins trois brevets sur l'API de .NET et quatre brevets sur le coeur de .NET (aspect multi-langage, représentation des types fondamentaux, gestion de version, delegates). Deux autres brevets sur l'API de .NET sont en cours d'acceptation (il ne reste plus à MS que de payer les frais) et MS à des dizaines de demandes en cours d'examen (15 demandes avec Hejlsberg, le créateur de C#, dans les auteurs). Ces brevets sont vraisemblablement incontournables, vue leur formulation très générale.\nJe termine par un peu de pub (honte à moi) : j'ai écris un nouveau pavé sur la situation juridique de Mono (et de Java) qui devrait paraître dans le numéro d'Octobre de Linux Magazine (sauf contre ordre ou manque de place, vue la longueur du bousin). Résumé de l'article : la situation de .NET et de Java est maintenant plus claire. On sait que .NET (et donc Mono) est couvert par des brevets dans tous les sens, mais qu'il est relativement peu probable que Microsoft attaque Novell pour des raisons politiques et gràce à l'OIN. On sait aussi que Sun va mettre son JDK sous une licence open source, ce qui clôt le débat.\nPosté par nolius le 07/09/06 à 13:11 . Évalué à 3.\nl'histoire des 283 brevets dans le noyau linux (dont 27 de microsoft) concerne plus de monde. http://linuxfr.org/2004/08/02/16957.html\ndans une distribution linux, il doit y avoir des milliers de brevets violés, non?\nc'est ce qui arrive quand on accepte des brevets comme le double click\nPosté par boubou (page perso) le 07/09/06 à 13:17 . Évalué à 2.\nCertes, certes, on compte aussi plus de 500 brevets portant directement sur Java. La question cruciale est qui possède ces brevets, quelle est leur portée, de quels autres brevets dépendent-ils, etc. Concernant .NET, on sait que les brevets de MS ont été déposés pour assurer le contrôle de la plateforme et qu'ils sont cruciaux pour son implémentation. En gros, ils sont incontournables. Il faudrait faire une analyse précise des brevets qui couvrent le noyau linux pour en savoir plus. Pour prendre un exemple, le format gif a longtemps été protégé par un brevet, ce qui ne posait pas vraiment de problème car ce format est pourri. Par contre, le format mp3 est protégé par des brevets (incontournables) ce qui pose problème jusqu'à leur disparition (en 2010). Il y a donc brevet et brevet. Ceux dont je parle pour .NET sont potentiellement dangereux.\nPosté par zerbro le 07/09/06 à 13:38 . Évalué à 4.\nLe format gif (codage LZW pour etre precis) n'a rien de pourri pour la compression d'une image sur 256 niveau de gris, sans perte. Mais tout le monde l'utilisait pour la couleur, ce qui avait donc pour effet de dégrader l'image (vu que c'etait pas vraiment prevu pour la couleur).\nLe MP3 est aussi un format pourri, et pourtant tout le monde l'utilise. Alors que tous les autres sont beaucoup mieux (notament le mpeg2-layer 3 AAC pour rester dans la norme mpeg).\nTout ceci sans tenir compte des brevets.\nPosté par boubou (page perso) le 07/09/06 à 13:52 . Évalué à 2.\nAu temps pour moi. En fait, ce que je voulais dire c'est que gif était extrêmement populaire, mais que jpeg (pour lequel il n'y a pas de brevet payant) puis le png (pas de brevet à ma connaissance) ont rapidement constitué des alternatives viables. Le cas du mp3 est moins évident car son support par de nombreux hardware fait que son concurrent ogg s'impose beaucoup moins vite que jpeg et png n'ont "remplacé" gif.\nDésolé pour ce jugement de valeur sans grand fondement...\nPosté par Gmooron le 07/09/06 à 18:10 . Évalué à 4.\nLe Gif a été populaire principalement pour sa "fonctionnalité" (je sais pas si c'est le terme à utiliser) d'animation, fonctionnalité inexistante dans le jpg et le png.\nEt si je ne me trompe pas il y a un équivalent libre le MNG, mais implémenté quasiment nulle part ... (j'entends par là logiciels de dessins, navigateurs, ...)\nPosté par yeKcim (page perso) le 08/09/06 à 09:01 . Évalué à 4.\nJ'ajouterais surtout visionneuse a ta liste car très peu lise ce type d'animation. Ce format est pourtant très pratique et l'image d'une qualité qui ne se compare meme pas au gif\nPosté par Antoine le 10/09/06 à 00:18 . Évalué à 3.\nLe MP3 est aussi un format pourri, et pourtant tout le monde l'utilise.\nRaté. Par exemple, dans ce test effectué en VBR aux alentours de 130kbps, Lame fait quasi jeu égal avec Vorbis et AAC.\n« LAME offers to MP3 the chance to stay competitive against AAC and Vorbis. Not fully competitive, but the efficiency of this format forces the respect. »\nEt, au cas où ce ne serait pas clair, ce genre de tests très poussés sont effectués par des gens très entraînés capables de se concentrer sur de micro-détails de la restitution. A peu près aucun auditeur lambda n'entendrait une différence.\nPosté par TImaniac (page perso) le 07/09/06 à 13:30 . Évalué à 2.\nCe que j'adore avec toi, Timaniac, c'est que tu ne fais que répéter servillement la propagande de De Icaza.\nJe n'ai jamais lu de texte où Icaza parlait de l'OpenInitiativeNetwork. Juste suivi (par pure investigation personnelle) l'actualité autour des brevets de Mono, et notamment la création de l'OIN qui a finalement décider RedHat (le dernier à ne pas inclure Mono) a l'accepter. Si toutes les distributions Linux soutenus par des entreprises ayant un service juridique ont inclu Mono (alors que certaines distri n'incluent pas certains softs pour des raisons de brevet), c'est bien qu'il n'y a pas plus de danger qu'avec un autre soft (je dis pas que y'a aucun danger !)\nJe peux donc te donner moi aussi une information vérifiable : Microsoft possède au moins trois brevets sur l'API de .NET\nEt ? Moi j'ai pointé des informations également vérifiable : l'OIN a toutes les cartes pour défendre Mono, notamment des brevets clés sur les web-services.\nOn sait aussi que Sun va mettre son JDK sous une licence open source, ce qui clôt le débat.\nOué ca fait 10 ans qu'ont a des rumeurs comme ca. On attend toujours de savoir sous quelle licence et quand. En attendant Wait&See. De toute façon je n'ai absolument rien contre Java, et des bindings pour Java dans Gnome ne me gène pas le moindre du monde, au contraire ! (Loin de moi l'idée de vouloir lancer un troll Mono vs Java ici)\nJe termine par un peu de pub (honte à moi) : j'ai écris un nouveau pavé sur la situation juridique de Mono (et de Java)\nJe suis heureux de l'apprendre ! Je trouvais vraiment dommage que ton article servait toujours de référence alors qu'ils manquaient les principales informations (plus récentes que l'article) qui changeaient complètement la donne.\nEnfin tout ca pour dire que l'OIN protège Mono, mais protège aussi de nombreuses parties de Linux (et les softs libres qui gravitent autour comme Python), comme quoi eux aussi pose(aient?) de nombreux problème liés aux brevets. Bref Mono n'est pas un cas particulier et est autant en danger/sécurité que la plupart des technos/softs libres.\nEnfin au final j'ai du mal à capter ce que tu me reproches vu que je ne trouves aucune contradiction avec ce que tu dis.\nPosté par boubou (page perso) le 07/09/06 à 13:59 . Évalué à 2.\nqu'il n'y a pas plus de danger qu'avec un autre soft\nNon, c'est que le risque est acceptable, c'est-à-dire en dessous d'un certain seuil. En dessous de ce seuil, il existe toujours des risques différents.\nl'OIN a toutes les cartes pour défendre Mono, notamment des brevets clés sur les web-services.\nOn n'en sait rien, en fait. L'OIN a des brevets gênants pour tout le monde, mais Microsoft a beaucoup beaucoup d'argent et des brevets très emmerdants pour tout le monde aussi. C'est la dissuasion nucléaire...\nOué ca fait 10 ans qu'ont a des rumeurs comme ca.\nHum, c'est annoncé officiellement par Sun depuis le 14 août 2006, la licence sera approuvée par l'OSI, les premiers morceaux sortiront en octobre 2006, avec un jdk complet avant juin 2007. C'est assez précis, non ? Comme roi du FUD, tu te poses bien là.\nBref Mono n'est pas un cas particulier et est autant en danger/sécurité que la plupart des technos/softs libres.\nLes risques liés à Mono me semblent maintenant acceptables, ça ne veut pas dire qu'ils sont au même niveau que ceux posés par Java ou Python, par exemple.\nPosté par TImaniac (page perso) le 07/09/06 à 14:10 . Évalué à 5.\nNon, c'est que le risque est acceptable, c'est-à-dire en dessous d'un certain seuil.\nVi je suis bien d'accord. Mais je trouve allucinant de décider de changer de plateforme pour une autre alors qu'on a pas plus de certitude juridique sur l'autre (en l'occurence KDE).\nL'OIN a des brevets gênants pour tout le monde, mais Microsoft a beaucoup beaucoup d'argent et des brevets très emmerdants pour tout le monde aussi.\nOué enfin Novell + RedHat + Philips + IBM + Sony, ca fait une force juridique bien plus conséquente à mon avis, MS à côté c'est un petit challenger question brevets ! Je suis bien d'accord que ca ressemble à de la dissuasion, mais tu proposes quoi de mieux comme alternatives ? Je n'en vois qu'une : supprimer ces foutus brevets logiciels. En attendant, si l'OIN peut apporter une certaine garantie...\nComme roi du FUD, tu te poses bien là.\nBen en attendant on sait toujours pas à quoi ressemble la licence, y'a des licences OSI qui n'empêche en rien les brevets logiciels hein ;-) J'essai pas de FUDer en disant que je préfère aller voir ailleur, je dis juste Wait&See, et en attendant j'ai GCJ + Eclipse qui me convient très bien niveau libertés.\n(Quand à l'annonce du 14 août, désolé, j'étais en vacances, j'en étais encore aux rumeurs insistantes et déclarations officieuses).\nSi tu veux, mais as-tu fais la même investigation de l'intégral des brevets déposés pour pouvoir juger de manière objective ? Pour moi les brevets logiciels sont une véritable plaie pour l'ensemble des logiciels (libre ou non). La seule réponse qu'est trouvé certains acteur, c'est de faire un panier comme de brevet pour défendre une éventuelle attaque.\nEnfin tout ca pour dire que de toute façon, le débat côté Gnome n'a globalement pas tourné sur la légalité de Mono où tout le monde est globalement aujourd'hui d'accord, mais plutôt sur des points techniques (rapidité, techno, etc.). Je ne remet pas du tout en question le fait que Mono puisse soulever des problèmes juridiques, mais dire qu'on change de plateforme à cause de ca alors qu'on a pertinement aucune idée de la légalité de l'autre plateforme relève vraiment du FUD (vouloir faire peur en semant le doute).\nPosté par boubou (page perso) le 07/09/06 à 14:28 . Évalué à 0.\nMais je trouve allucinant de décider de changer de plateforme pour une autre alors qu'on a pas plus de certitude juridique sur l'autre (en l'occurence KDE).\nEst-ce que tu peux donner des références de brevets qui s'appliquent de façon bloquante à KDE et pas à Gnome ? Parce qu'aujourd'hui je peux faire cet exercice sans difficulté dans l'autre sens grâce à l'inclusion de Mono dans Gnome. Si tu ne comprends pas la différence, je ne peux rien pour toi.\nOué enfin Novell + RedHat + Philips + IBM + Sony, ca fait une force juridique bien plus conséquente à mon avis, MS à côté c'est un petit challenger question brevets !\nSauf que l'OIN n'a pas vocation à utiliser les brevets de ses membres fondateurs pour attaquer quelqu'un qui s'attaquerait à Mono (ou à d'autres applications protégées). l'OIN utilisera pour ça les brevets qu'elle possède, c'est à dire 13 seulement (ils ont une portée très large, ceci dit).\nJe suis bien d'accord que ca ressemble à de la dissuasion, mais tu proposes quoi de mieux comme alternatives ? Je n'en vois qu'une : supprimer ces foutus brevets logiciels. En attendant, si l'OIN peut apporter une certaine garantie...\nTu déplaces toujours la discussion. Je trouve que l'OIN est une initiative géniale, d'autant que ça va me permettre de coder en Mono sans prendre trop de risque. Ca ne règle pas magiquement les problèmes de Mono, ça les réduit, c'est tout.\nPosté par patrick_g (page perso) le 07/09/06 à 14:44 . Évalué à 8.\nOk je e réponds ici pour ce post et aussi pour celui plus bas sur la lourdeur.\n>> dire qu'on change de plateforme à cause de ca alors qu'on a pertinement aucune idée de la légalité de l'autre plateforme relève vraiment du FUD\nSi j'envisage éventuellement de changer de plateforme c'est que je pense vraiment que Gnome a rompu un contrat moral.\nC'est quoi un desktop ? C'est un framework de développement (GTK+ ou Qt) et un ensemble cohérent d'applications par défaut qui se basent sur ce framework (Gnome ou KDE).\nC'est ça un desktop, ni plus ni moins.\nOuvrir la possibilité à d'autres développeurs d'utiliser le framework dans le langage de leur choix (par des bindings) cela ne pose pas de problème. Mais FORCER les utilisateurs du desktop à utiliser ces applications Mono en remplacant les applis par défaut c'est une rupure du contrat moral d'origine.\nLes applis par défaut de Gnome doivent se baser sur GTK+ et être en C. Si un langage de haut niveau se révèle vraiment indispensable alors il faut en choisir un (et un seul) et s'y tenir. Encore une fois cela n'interdit pas les bindings mais le applis qui reposent sur ces bindings ne doivent pas faire partie des applis par défaut de Gnome.\nC'est une question de cohérence technique et c'est typiquement le genre de décision que l'on attends d'une core-team ou d'un fondation board. Ils doivent CHOISIR et s'y tenir.\nAu lieu de ça on voit quoi ? On remplace une appli par défaut par une application qui dépend de Mono...et tout le monde sent bien que ce n'est que le début.\nMoi ça m'énerve. J'aime Gnome, j'aime son interface simple et son HIG. Mais visiblement dans Gnome il n'y a pas de direction claire et de choix qui est fait. KDE a une vision claire de son futur alors que Gnome tatonne et empile les couches de logiciel sans choisir.\nPosté par j (page perso) le 07/09/06 à 15:00 . Évalué à 7.\nMais FORCER les utilisateurs du desktop à utiliser ces applications Mono en remplacant les applis par défaut\nCe n'est pas le cas. StickyNotes est toujours une applet du tableau de bord de GNOME. C'est à l'utilisateur de choisir puisquepar défaut ni l'in ni l'autre ne sont chargés. (Et ceux qui n'ont pas installé Mono n'ont pas TomBoy)\nPosté par TImaniac (page perso) le 07/09/06 à 15:07 . Évalué à 5.\nLes applis par défaut de Gnome doivent se baser sur GTK+ et être en C.\nY'a longtemps que Gnome a rompu ton contrat moral en utilisant Python...\nSi un langage de haut niveau se révèle vraiment indispensable alors il faut en choisir un (et un seul) et s'y tenir.\nJustement non, le contrat de Gnome, au cas où tu l'aurais pas compris, c'est de proposer un framework en C et un ensemble de bindings pour avoir des applis dans des langages sans discriminiation et sans choix à priori.\nIls doivent CHOISIR et s'y tenir.\nOué ben ils ont choisient de laisser le développeur sa liberté pour la partie desktop. Le fait de développer des bindings depuis des années va entièrement dans ce sens, et refuser GTK# auraient clairement été un changement de "contrat moral" comme tu dis.\nOn remplace une appli par défaut par une application qui dépend de Mono...et tout le monde sent bien que ce n'est que le début.\nBah oué, ben t'avais qu'à améliorer Sticky au lieu de râler. Y'en a qui codent, d'autre qui râlent, essai au moins de comprendre que certains préfèrent des outils qui ne te plaisent pas forcement sans que celà constitue une "rupture de contrat moral". Y'a des gens qui essaient de faire évoluer le bureau Gnome, qui est avant tout destiné aux utilisateurs, qui n'en a rien d'autre à faire des détails techniques : ce qu'il voit c'est une appli plus "cool" qu'avant. S'il a fallut changer de techno et utiliser un nouveau soft, c'est parcque personne n'a voulu faire évoluer l'autre.\nJ'aime Gnome, j'aime son interface simple et son HIG\nCa correspond beaucoup plus au contrat "moral" de Gnome ca. Et tu devrais t'enthousiasmer que de nouvelles applis sortent en respectant justement ces goûts d'ergonomie.\nMais visiblement dans Gnome il n'y a pas de direction claire et de choix qui est fait.\nLes HIG sont écritent noires sur blanc, ils essaient de s'y tenir, y'a une roadmap technique sur live.gnome.org, et la roadmap philosophique est toujours la même.\nPosté par mobutu le 07/09/06 à 15:09 . Évalué à 2.\nY'a longtemps que Gnome a rompu ton contrat moral en utilisant Python..."\nY'a quoi comme truc en python à part la rigolote mais inutile deskbar ?\nPosté par liberforce (page perso) le 07/09/06 à 16:32 . Évalué à 5.\nles plugins gedit, pessulus et sabayon pour l'administration, jhbuild pour compiler GNOME... j'imagine que j'en oublie ?\nPosté par zebra3 le 07/09/06 à 19:10 . Évalué à 3.\n- SoundConverter et Revelation (qui ne font pas partie officiellement de GNOME, mais qui y auraient leurs places),\n- l'éditeur de menu (avant Alacarte)\n- Serpentine (je ne sais pas s'il est officiel)\n- ...il y a en a sûrement beaucoup d'autres\nPosté par zebob le 07/09/06 à 21:10 . Évalué à 1.\nIl me semble également que Baobab est en Perl.\nPosté par Juke (page perso) le 08/09/06 à 00:06 . Évalué à 2.\nnon c'est du C.\nPosté par Juke (page perso) le 08/09/06 à 00:08 . Évalué à 2.\nJ'ai du mal à me passer de la deskbar maintenant, c'est peut etre parce que je suis sur un petit ecran, j'ai enlever la barre d'adresse dans le navigateur et je n'utilise que la deskbar. Par contre c'est dommage c'est encore assez instable.\nPosté par patrick_g (page perso) le 07/09/06 à 16:27 . Évalué à 2.\n>> Justement non, le contrat de Gnome, au cas où tu l'aurais pas compris, c'est de proposer un framework en C et un ensemble de bindings pour avoir des applis dans des langages sans discriminiation et sans choix à priori.\nBon on va donc procéder par un exemple par l'absurde.\nTu prônes la non discrimination des langages. Très bien. Moi aussi je suis favorable aux bindings pour laisser le choix aux développeurs. Mais est-ce que Gnome doit avoir, par défaut, des applications dans tous ces langages ?\nQue des bindings existent soit. Que les devs fassent ce qu'ils veulent avec leurs applis soit. Mais le projet Gnome doit CHOISIR un et un seul langage de haut niveau afin d'éviter la situation absurde décrite ci-dessus.\nLa non discrimination des langages c'est bien beau mais ce qu'on attends du board de la fondation Gnome c'est qu'elle fasse des choix techniques corrects et pertinents pour le futur. Là ce qu'elle nous propose c'est l'intégration d'applications dans tous les langages possibles et imaginables ?\nEncore une fois le problème ce n'est pas Tomboy vs Sticky Notes. Le problème c'est qu'on ajoute des dépendances et que ces dépendances vont entrainer l'arrivée de nouveaux logiciels par défaut (F-Spot à coup sur) sans qu'il y ait eu un choix clair pour le langage de haut niveau.\nLa solution élégante c'est quoi ? Proposer des applications par défaut en C (comme actuellement) ou dans UN langage de haut niveau. Comme ça les besoins des développeurs sont satisfaits (ils peuvent choisir entre la vitesse d'exécution ou la vitesse de développement ou mixer les deux) et les besoins des utilisateurs sont satisfaits (ils ont une empreinte mémoire acceptable et ils ont des dépendances acceptables).\nPosté par TImaniac (page perso) le 07/09/06 à 17:08 . Évalué à 4.\nJe pense que tu cernes mal la situation. Evidemment, dans l'idéal, un seul framework avec un seul langage, c'est plus élégant.\nCela dis Gnome n'est pas une société comme Microsoft qui maîtrise parfaitement de A à Z ses softs. La situation est totalement différente : Gnome fourni un framework de base, des bindings, des types liés à Gnome ou non développent des applis avec leur outils préférés. Arrive un moment où ces applis deviennent "Hype" et où les gens se disent "ah oué ca serait cool de l'avoir dans Gnome". Donc effectivement, soit t'es cohérent, tu imposes un langage, et tu prends tes doigts et tu réinventes la roue (youpi). Auquel cas d'ailleur tu te fais même pas chier à faire des bindings, tu laisses ca à des personnes extérieures à Gnome. Où alors tu peux aussi être cohérent d'une autre manière : tu délivres des bindings, ce qui inévitablement conduit à des appli intéressantes les utilisants, et là tu les accepte quand elles sont intéressantes.\nMais est-ce que Gnome doit avoir, par défaut, des applications dans tous ces langages ?\nGnome est modulaire, ces applis ne sont pas indispensable à la plateforme, libre aux distributions de délivrer Gnome avec les packages qu'ils souhaitent.\nLa non discrimination des langages c'est bien beau mais ce qu'on attends du board de la fondation Gnome c'est qu'elle fasse des choix techniques corrects et pertinents pour le futur.\nDe ton point de vu ce sont des mauvais choix, on l'a compris. Mais tu crois que de leur point de vue ils ont fait le mauvais choix ?? Pour le futur justement parlons-en, si Gnome était limité au C, ca veut dire que dans 20 ans on serait encore à faire des appli desktop en C ? Et Python ? Ne sera-t-il pas périmé dans 20 ans ? Gnome suit les évolutions techniques pour justement ne pas être délaissé dans le futur parcque marqué par les développeurs comme "obsolete". Moi ce que j'attend de Gnome c'est un Desktop complet et utilisable, si de nouvelles applis à l'ergonomie intéressantes (c'est le cas de Tomboy ou F-Spot) apparaîssent, je m'en syphonne de en quoi elles sont coder, si elles améliorent l'expérience de l'utilisateur de Gnome, c'est le principal.\nR un et un seul langage de haut niveau afin d'éviter la situation absurde décrite ci-dessus.\nBof, ca c'est toi qui trouve que c'est absurdre, visiblement le board de Gnome a majoritairement estimé que ca ne l'était pas.\nLe problème c'est qu'on ajoute des dépendances et que ces dépendances vont entrainer l'arrivée de nouveaux logiciels par défaut (F-Spot à coup sur)\nBah oué et ? Vas-y, code C-Pot ou Python-Pot ! Gnome choisi les applis en fonction de leurs qualité (vis-à-vis de l'esprit Gnome), que le meilleur soft gagne, et l'expérience utilisateur n'en sera que meilleure ! Et ne me parle pas d'absurdité technique, les performances de l'appli sont prises en compte quand il faut choisir un soft.\nsans qu'il y ait eu un choix clair pour le langage de haut niveau.\nOué et c'est justement ca que j'aime dans Gnome pour les développeurs : c'est ouvert au niveau des langages, et c'est tant mieux, ils peuvent ainsi attirer plus de développeurs qui y retrouve ses outils préférés, ce dont Gnome a fortement besoin.\nDans tous les cas, libre à toi de ne pas utiliser ces appli, ca te prend 30 secondes après install pour virer mono et l'ensemble des softs en dépendant, et hop tu te retrouveras avec le Gnome de tes rêves. Dans 10 ans ton Gnome aura pas beaucoup bouger, alors que celui des autres aura peut être pleins d'appli intéressantes à utiliser.\nMais imposer un langage de haut niveau, c'est aussi prendre des risques... En choissant le C y'a 10 ans, ils en savent quelque chose que ce genre de choix ne se fait pas à la légère !\nImposer un langage de haut niveau, c'est fermé la porte à de nombreux programmeurs et donc programmes, sans rien apporter du tout : la solution actuelle te laisse le choix, la tienne ne fera pas venir plus de programme et Gnome n'évoluera pas. Ca c'est préparer le futur.\nUn bon conseil : pense à l'expérience des utilisateurs, c'est tout ce qui importe, qu'il soit devant son bureau Gnome à cliquer, où qu'il soit dans son IDE à utiliser les API.\nPosté par patrick_g (page perso) le 07/09/06 à 18:43 . Évalué à 2.\n>> Bah oué et ? Vas-y, code C-Pot ou Python-Pot\nMais justement !!! Y'a aucun besoin de coder un C-pot puisqu'on à déjà Eye of Gnome (pour les besoins basiques de visionnages) et Gthumb (pour la gestion d'image et la retouche basique).\nA quoi bon faire entrer F-Spot dans Gnome ?? (c'est pas fait mais ça pointe à l'horizon).\n>> si Gnome était limité au C, ca veut dire que dans 20 ans on serait encore à faire des appli desktop en C ?\nMais Gnome n'est justement pas fermé actuellement. Je lui reproche même d'être ouvert au quatre vents. Un compromis me semble souhaitable sur le choix d'un seul langage de haut niveau (et si possible sans qu'il soit lardé de brevets détenus par Microsoft).\n>> Un bon conseil : pense à l'expérience des utilisateurs, c'est tout ce qui importe\nQuand j'évoque la conso mémoire je pense à quoi à ton avis ?\nPosté par zerbro le 07/09/06 à 20:10 . Évalué à 6.\nTu as deja utilisé un logiciel du genre f-spot ?\nParce que ca fait un moment que tu dit que Gthumb fait l'affaire. Demande l'avis a une personne qui a énormément de photo, et qui les gère soigneusement.\nEssaie par exemple, de retrouver toutes les photos ou mémé et oncle jo apparaissent ensemble avec gthumb...\nJ'aimerais bien que gnome intègre une appli du type f-spot (il y a un équivalent en python dont j'ai oublié le nom). Par contre, elles ne sont pas encore hyper stable et comportent des defauts.\nGthumb fait l'affaire pour visioner quelques photos bien classé en arborescence, mais pas du tout pour les classer avec des tags, vu qu'il ne gère pas les tags. Et les tags, c'est super bien.\nPosté par patrick_g (page perso) le 07/09/06 à 20:40 . Évalué à 3.\n>> Gthumb fait l'affaire pour visioner quelques photos bien classé en arborescence, mais pas du tout pour les classer avec des tags, vu qu'il ne gère pas les tags. Et les tags, c'est super bien.\nAhem....c'est quoi déjà un tag ?\nAh oui c'est l'assignation d'une catégorie à une photo non ?\nPour reprendre ton exemple je crée la catégorie "mémé" et la catégorie" oncle joe" dans ma liste. Ensuite j'édite ma photo et je coche les cases "mémé" et "oncle joe".\nVoila ! J'ai mes tags sur la photo et je peux ensuite faire des recherches pour retrouver toutes les photos de la catégorie "mémé" etc etc\nC'est bien ça un tag non ?\nJ'ai une révélation à te faire : GThumb gère les catégories ! (cf photo)\nBon maintenant à mon tour de poser une question. Sachant que Gthumb fait partie de Gnome, qu'il est conçu pour s'intégrer parfaitement à Gnome, il possède l'interessante fonction suivante :\nTrouvé sur la liste des fonctions de GThumb : http://gthumb.sourceforge.net/features.html\nEst-ce que F-Spot en est au même niveau d'intégration ?\nPosté par zerbro le 07/09/06 à 22:01 . Évalué à 3.\nJe viens de reregarder gthumb, c'est vrai qu'il y a une gestion de tag.\nCependant, l'interface n'est pas du tout adpaté (je trouve) a cette gestion. L'apperçu que j'ai eu des autres gestionnaires de photo qui mettent la gestion des catégorie au 1er plan (un peu comme rhyhthmbox pour la musique) etait beaucoup plus intuitive.\nBien sur, le 1er bug est l'interface chaise clavier (la c'etait moi). Certe. Dans ce cas que "quelqu'un" revoit completement l'interface de gthumb pour faciliter la gestion des tags : avec une liste des catégories apparaissant clairement et visible en permanence, une zone de recherche elle aussi disponible ne permanence...\nLa preuve en est que sur les forums sur lesquels je passe de temps a autre, apparement, gthumb ne satisfait pas grand monde, et beaucoup de gens attendent beaucoup d'applications "à la" F-spot (pas forcement F-spot).\nBon, c'est completement hors sujet par rapport au post initial sur mono.\nEnsuite, non, F-spot n'en est pas au meme niveau d'intégration. Et surtout, il n'est pas du tout assez stable. Mais je ne crois pas qu'il soit question d'intégrer F-spot dans gnome.\nPosté par boris le 08/09/06 à 01:05 . Évalué à 1.\nPosté par Barnabé le 09/09/06 à 10:54 . Évalué à 7.\n(Laconique, non ?)\nPosté par gpe le 11/09/06 à 14:30 . Évalué à 1.\nParce thumbnail ce n'est pas un mot à ch*er?\nMoi, j'aime bien imagette, ça dit clairement ce que c'est.\nPosté par boubou (page perso) le 07/09/06 à 21:11 . Évalué à 4.\nJ'ai beaucoup de photos et j'ai essayé F-Spot (sous Fedora Core, donc dans sa version 0.1.10). Ca plante tout le temps. Moralité, j'utilise digikam qui est beaucoup plus complet et beaucoup plus stable. J'avoue que cet intégrisme (je ne parle pas de toi) Gnome ou Kde me fatigue. Pourquoi ne pas utiliser digikam et gaim, par exemple, sans se poser la question du desktop qui lui est associé ?\nPosté par Spyhawk le 08/09/06 à 17:52 . Évalué à 0.\nPour une question d'intégration peut-être ?\nPour utiliser ce qu'un "environnement de bureau" complet devrait être ?\nPosté par zebob le 07/09/06 à 21:38 . Évalué à 5.\nun équivalent en python\nJBrout ? http://jbrout.python-hosting.com/wiki/WikiStart\nPosté par Christophe Fergeau le 07/09/06 à 17:33 . Évalué à 3.\n« La non discrimination des langages c'est bien beau mais ce qu'on attends du board de la fondation Gnome c'est qu'elle fasse des choix techniques corrects et pertinents pour le futur. »\nLe board de la fondation Gnome n'a absolument pas pour but de faire des choix techniques quant aux orientations futures de Gnome. Même le choix des applis à intégrer ou non n'est pas fait par le board, mais par la release team.\nPosté par boris le 08/09/06 à 01:02 . Évalué à 2.\nPosté par patrick_g (page perso) le 08/09/06 à 08:23 . Évalué à 1.\nPutain c'est bien la peine que je poste 2634661 messages si c'est pour que personne ne comprenne ma position ! (hum ça doit vouloir dire que je n'arrive pas à m'exprimer...inquiétant ça ;-)\nAlors, one more time, il n'est absolument pas absurde de disposer du choix du langage de programmation pour son projet. Je n'ai jamais écrit cela !\nCe que je dis c'est que les applications par défaut de Gnome ne doivent pas êtres écrites dans 36 langages. Seulement dans un ou deux (le C et un langage de haut niveau comme Python).\nC'est tout. Ni plus ni moins. Je ne parle que des applications par défaut que Gnome propose dans son desktop et pas des autres logiciels. C'est juste une question de cohérence technique du projet et d'empreinte mémoire du desktop Gnome.\nPosté par TImaniac (page perso) le 08/09/06 à 09:43 . Évalué à 5.\nC'est juste une question de cohérence technique du projet et d'empreinte mémoire du desktop Gnome.\nJ'ai l'impression que t'as à des gros à priori techniques, et tu sembles persuader que cela impact négativement l'expérience utilisateur.\nFaut bien voir que l'on parle d'appli Gnome, qui utilise donc les API du framework Gnome/GTK/GStreamer&Co. Globalement si tu fais une appli en C# et une autre en Python, le point commun, ca sera ces libs. Si tu as fais des cours d'optimisation, tu réfléchiras pas 2 fois, tu iras droit à l'essentiel : faut optimiser le code le plus utilisé et le plus réutilisé, chercher à améliorer le reste ne t'apportera qu'un gain dérisoir à l'échelle du système (globalement).\nVoilà, c'est sans doute pourquoi l'équipe de Gnome s'attache en ce moment à améliorer les problèmes de perf de Gnome et GTK, parcque c'est pertinent, tout en acceptant des appli écrites dans divers langages, car c'est également pertinent de faire évoluer le desktop.\nL'équipe qui s'occupe de choisir telle ou telle appli est beaucoup plus pragmatique que toi : ils vérifient ses performances concrêtement. Tomboy bouffe-t-il un max de ressources par rapport à ce que l'appli est censé faire ? Faut-il mieux avoir une empreinte mémoire légèrement plus grande que sticky (je dis n'importe quoi j'ai pas vérifié) et offrir un soft aux fonctionnalités/ergonomie plus intéressante ?\nCa ce sont les vraient questions. Je vois pas l'intérêt de se poser une question du genre : "est-ce en Python ou en C ?" Si c'est non, poubelle, quelque soit les qualités du soft et sa consommation de ressources. Yooupi, on a plus qu'à attendre que quelqu'un d'autre réinvente la roue dans les unique langages autorisés, et si personne ne le fait ben tant pis Gnome n'évoluera pas.\nPosté par TeXitoi (page perso) le 08/09/06 à 14:17 . Évalué à 3.\nC'est un peu absurde de dire « regardez, on vous propose tout pleins de bingings, donc vous pouvez utiliser le langage que vous voulez pour faire une application Gnome » et de dire ensuite « Dans Gnome, on accepte que les programmes qui utilisent tel ou tel language ». Enfin, je trouverais celà peu cohérent.\nPosté par ribwund le 07/09/06 à 13:52 . Évalué à 3.\nPourtant, chercher des brevets sur le site de l'USPTO, c'est facile http://www.uspto.gov/\nD'après les developpeurs qui habitent aux US qui sont sur les mêmes projets que moi, il vaut mieux éviter de s'y balader. En tout cas pour ceux qui sont aux Etats-Unis c'est pas vraiment la même chose entre une violation de brevet simple, et une violation "consciente".\nPosté par yeKcim (page perso) le 07/09/06 à 12:13 . Évalué à 1.\nJe trouve ca bizarre de lire encore des trolls a propos de mono. C'est un peu comme si je disais aujourd'hui, kde ca pue c'est pas libre. Des fois je me dis que les trolls ont la peau dure...regrettable.\nPosté par j (page perso) le 07/09/06 à 12:02 . Évalué à 0.\ncet ajout de Mono\nD'une (1) application dépendant de Mono - qui ne fait pas partie de GNOME.\nPosté par imalip le 07/09/06 à 12:19 . Évalué à 4.\nJustement, nouveauté, c'est que maintenant elle en fait officiellement partie. Sinon, ils n'en parleraient pas dans les release notes.\nPosté par liberforce (page perso) le 07/09/06 à 13:13 . Évalué à 1.\nJe pense qu'il faisait remarquer que c'est tomboy qui fait partie de GNOME, pas Mono...\nPosté par Anonyme le 07/09/06 à 16:11 . Évalué à 6.\nPosté par zerbro le 07/09/06 à 12:13 . Évalué à 6.\nChacun son opinion, mais de mon point de vu, comparer gthumb et f-spot, c'est un peu comparer xmms et rhythmbox (j'y vais à la hache pour la comparaison ;)\nL'un est basé sur une gestion en arborescence, l'autre, a partir d'une base de donnée et des tags, qui s'affranchi de cette arborescence. Ce n'est donc pas du tout le meme type de gestion.\nCerte, les deux permettent de visioner et d'organiser des photos, mais la phylosophie et le type d'organisation n'ont rien à voir. Or, c'est la façon de gérer les photos qui va nous faire choisir l'un ou l'autre.\nSur le reste, ca dépend aussi de ta distribution. Et parce que tomboy a été intégré, il ne faut pas tout de suite s'imaginer que toutes les applications mono vont venir d'un coup. D'ailleur, "on" parle de rhythmbox pour remplacer le lecteur CD de gnome (rien n'est fait, ca sera peut etre totem l'elu, ou un autre, ou pas pour tout de suite, ou peut etre que je suis a la ramasse).\nD'autant que ce que tu dénonces comme une grosse erreur, d'autres le voient comme une formidable avancée. Donc bon...\nPosté par Anonyme le 07/09/06 à 15:56 . Évalué à -2.\nPosté par TImaniac (page perso) le 07/09/06 à 11:33 . Évalué à 3.\nSi Tomboy a une ou deux fonctions en plus alors pourquoi ne pas améliorer plutôt Sticky Notes ?\nCa fait 10 plombes que les débats autour des applis GTK# existent, pourtant personne n'a eu envi de modifier sticky notes. Quelqu'un l'aurait fait, la question ne se saurait pas poser, mais visiblement ca ne faisait bander personne de rentrer dans le code. Si ca se trouve les "quelques fonctionnalités" supplémentaires demandait une refonte totale de sticky, bref si ca se trouve ca aurait été plus simple de tout recommencer.\nBen oué, et ils avaient raisons : le C est un langage qui s'interface très bien avec de nombreux langage (mieux que le C++ en tout cas) : on fait tout le framework de base en C et on offre de nombreux bindings aux développeurs d'applications desktop. GTK# n'est qu'un binding de plus, y'a déjà de nombreuses applis en Python ou C++ dans Gnome, sans que la philosophie est changée.\nPosté par boubou (page perso) le 07/09/06 à 12:00 . Évalué à 5.\nBen oué, et ils avaient raisons : le C est un langage qui s'interface très bien avec de nombreux langage (mieux que le C++ en tout cas)\nSauf qu'ils ne bavaient pas sur le C++ pour cette raison mais en arguant qu'un programme C++ ramait à mort par rapport à un programme C. Amusant, quand on voit les bindings python et C# (par exemple).\nPosté par TImaniac (page perso) le 07/09/06 à 13:39 . Évalué à 2.\nAmusant, quand on voit les bindings python et C# (par exemple).\nTu vas rire, même que y'a 30 ans, y'avait le même débat entre le C et l'assembleur, heuresement les mentalité évoluent avec les technologies, des arguments pertinents y'a 10 ans ne le sont plus forcement aujourd'hui.\nMoi je parlais de la philosophie, qui est pour les développeurs, je cite la fondation Gnome :\n"GNOME gives developers the greatest licensing flexibility and the greatest variety of programming languages."\n( http://www.gnome.org/about/why.html )\nPosté par ome le 07/09/06 à 11:38 . Évalué à 1.\nPourquoi faut-il choisir entre GNOME et KDE? Perso je préfère réserver les ressources de mon ordinateur aux tâches pour lesquelles je le destine plutôt que de faire s'exécuter une interface utilisateur de plus en plus lourdingue et bourrée de gadgets tous plus inutiles les uns que les autres. J'ai utlisé KDE pendant un moment par le passé. Après avoir trop longtemps espéré une stabilisation et une optimisation du code plutôt qu'une course folle à l'ajout de fonctionalités que je n'utilise pas, j'ai décidé de le laisser tomber.\nPosté par liberforce (page perso) le 07/09/06 à 12:47 . Évalué à 5.\nEt surtout sa réponse (la 2ème section du post):\nFederico Mena Quitero, co-fondateur de GNOME, explique qu'il n'y a jamais eu de limitations de langages de GNOME, même si le C a par la suite été favorisé, surtout pour la facilité à générer de bindings pour les autres langages.\nLe fait que mono rentre dans GNOME ne veut pas dire que le C# remplace le C en tant que langage "officiel", juste qu'on ouvre des possibilités de développement. Rappelelons que des applications en python font déjà partie de GNOME, sans qu'il ait été dit qu'il fallait remplacer tout ce qui était en C par du python (même si certains fous l'ont pensé tout haut).\nPosté par liberforce (page perso) le 07/09/06 à 12:51 . Évalué à 2.\nApparemment tu en a énervé plus d'un avec ta remarque :-)\nBon, voici le point de vue de Vincent Untz, membre du foundation board de GNOME, et qui pourra t'expliquer tout celà bien mieux que moi :-)\nPosté par patrick_g (page perso) le 07/09/06 à 14:10 . Évalué à 8.\nMerci de m'avoir donné ce lien très interessant. Je n'avais pas vu qu'il avait posté une réponse à mon journal de l'époque (maintenant je l'ai dans mon aggrégateur...il ne m'échappera plus ;-)\nSur le plan le plus général imagine la situation suivante dans deux ans : je lance ma machine avec Gnome 2.22 et ma conso mémoire s'emballe. En effet avec des applets en Python, en Ruby et des applis incontournables en Mono j'ai je ne sais combien de machine virtuelles qui tournent en même temps. Est-ce qu'il ne serait pas plus logique, si on veut répondre à la vraie demande d'un framework de haut niveau, de se limiter à Python ?\nPourquoi s'alourdir avec Mono (en plus des brevets Microsoft) alors que Python remplit ce besoin parfaitement ?\nQue Gnome propose un binding vers C# pour les devs qui sont interessés cela ne pose aucun problème. Tant que ces applis ne deviennent pas officiellement des applis Gnome.\nPar contre que Gnome commence à remplacer des applications actuelles par des applications Mono c'est très emmerdant. Moi je vois ça un peu comme une rupture de contrat moral. Je dis ça avec tristesse car j'aime beaucoup Gnome et je ne me suis jamais senti attiré par l'interface de KDE.\nPosté par lezardbreton le 07/09/06 à 14:13 . Évalué à 3.\nEntièrement d'accord avec toi. De toute façon, le débat (s'il a vraiment eu lieu) est fini visiblement, le marketing a vaincu !\nPosté par Mars le 08/09/06 à 03:19 . Évalué à 1.\nEn dehors de tout aspect technique (pas difficile je ne comprends même pas 1% de ce qui s'y raconte ... même si je persiste à continuer la lecture), et au delà de toute querelle de clocher (Gnome/KDE) je me pose quelques questions :\nQu'a fait Apple pour son Desktop ? Il utilise il me semble à la base son C+maison.\nLangage repris, il me semble, par le projet GnuStep (via les spécif OpenStep (arrêtez moi si je dis une bétise, ce qui est à peu près certain). Depuis le début du projet MacOSX, une ouverture à Java a été entreprise, mais que nenni pour Python, Perl, GTK, etc. Est ce un mal ou un bien ? Ce n'est pourtant pas une boîte qui fait des choix à la ouplaboum.\nEn tous les cas ce me fait un peu penser à Babel ... Tout communique bien mais au pris d'un Bazaar (sic) monstre. En dehors du fait "pourquoi faire simple alors qu'on peut faire compliqué ?", est ce qu'il n'y aurait pas un langage plus qu'un autre qui soit à même d'offrir un compromis satisfaisant ?\nSi au fil du temps toutes les applications doivent être réécrites, n'est il pas plus judicieux, malgré le volume de la tâche (quelques années pour quelques milliers de personnes au minimum) de reprendre tout à zéro en se basant sur les expériences et les erreurs (du) passé(es) ?\nQuand à l'adoption de Mono par le projet Gnome, ce semble étonnant du point de vue stratégique et étique :\n- Mono depuis le début ne court il pas après .Net sans pouvoir le rattraper ?\n- Gnome ne se met il pas dans une possible situation de dépendance juridique vis-à-vis de MS ? Dans ce cas c'était bien la peine de dénigrer la première licence Qt !\nA partir de l'adoption de Mono (pas de son développement par Manuel de Icaza, chacun étant LIBRE de faire ce qu'il veut) par Gnome n'aurait il pas été souhaitable de faire un fork de Gnome ? Ce ne serait pas la première fois que sur un projet important (cf XFree/Xorg) une telle décision aurait été prise ? De même était on obligé de reproduire à l'identique-- .Net ? Combien de projet typé .net dans les vrai vie tournent à la fois sous Windows et sous Linux ?\nOn pourrait s'interroger sur la pression exercée par Novell dans ce contexte afin de montrer au libre qu'elles étaient ses limites ? Or Red-Hat (non, non je ne l'utilise pas, Fedora non plus) n'a jusqu'à présent rien trouvé à redire à cette situation. Du coup je m'interroge et ... ne comprend pas trop toutes ses querelles. Du moins leur pertinence.\nJe n'ai pas entendu parler d'une vague de départ de la part de développeurs éminents de Gnome ? Aucun n'a créé, il me semble, son propre Gnome ou rejoint KDE, GnuStep ou Enlightenment ?\nFinalement n'est pas un débat de café de commerce autour du libre qui ne sert à rien ou au contraire c'est un exemple d'un parfait raté autour d'un projet qui à l'origine se voulait moral ?\npetite question concernant KDE. Ce n'est pas la première fois que dans des cas similaires on fasse réferrence à KDE 4. Cette version, est elle une révolution conceptuelle ou au contraire, reste similaire aux évolutions qu'avaient apporté les versions majeures précédentes, c'est à dire KDE 2 et 3 ?\nPosté par dinomasque le 08/09/06 à 10:15 . Évalué à 2.\nIl s'agit Objective-C++ (un mélange de C++ et d'Objective-C).\nPour ce qui est de l'ouverture de Cocoa (l'API native de MacOSX) :\nPERL : http://cocoadevcentral.com/articles/000076.php\nIl suffit de taper "Cocoa [nom du langage]" dans ton moteur de recherche favori et tu verra qu'il y a tout plein de bindings pour à peu près tous les langages de l'univers (sauf Ada apparament, mais en compilant son programme Ada en bytecode Java interfacé à Cocoa on peut quand même y arriver !).\nPosté par Johann Ollivier-Lapeyre (page perso) le 08/09/06 à 10:23 . Évalué à 6.\nLe passage KDE1 à KDE2 avait changé beaucoup de chose:\n- Kpart (apres avoir envisagé Corba)\n- khtml (et konqueror)\nBref, grosses application mais surtout les fondations du truc. Pour KDE3, c'était principalement le port pour qt3, avec bien sur son lot d'innovation, mais surtout une amélioration de l'existant et de la qualité. Egalement le theme crystal.\nPour KDE4, il y a bien entendu le port pour qt4, mais au niveau évolution, ça sera + une grosse marche, plus comme KDE1->KDE2 que KDE2->KDE3. Par exemple:\n- Phonon (Wrapper audio permettant d'utiliser le backend audio de son choix)\n- Oxygen : nouveau theme d'icones\n- Plasma : fusion de kicker et superkaramba\n- remplacement de Dcop par dbus\n.... Mais aussi de grosses améliorations sur des trucs existant, comme knotify, KIO....\nBref, plein de trucs à faire dans tous les domaines :D\nPosté par TImaniac (page perso) le 07/09/06 à 14:19 . Évalué à 1.\nPourquoi s'alourdir avec Python (en plus d'éventuels brevets et pourquoi pas de MS) alors que Mono remplit ce besoin parfaitement ? La vérité c'est que Gnome ne veut pas privilégier une plateforme plus qu'une autre, ils laissent les développeurs la "liberté" de choisir la techno qu'ils préfèrent.\n'ai je ne sais combien de machine virtuelles qui tournent en même temps.\nOué t'en a 2. Mon dieu. Tu sais ce qu'est une machine virtuelle ? tu sais quelle taille prend la machine virtuelle en mémoire ? Tu sais quel pourcentage de tes barrettes de RAM de Gnome 2.22 ca représentera ? Que ces plateformes engendre une consommation de mémoire supplémentaire, certes, mais les mettre côte à côte ou n'en utiliser qu'une seule n'y changera rien du tout, les programmes boufferons toujours autant de RAM. Faut pas oublier que par derrière ca sera toujours les libs GNOME/GTK qui seront chargées, et mieux vaut optimiser celles-ci. Ah oui : avoir 2 plateformes entretien aussi l'émulation et la compétition (pour la consommation de RAM par exemple, désolé je trouve plus de lien).\nPosté par lezardbreton le 07/09/06 à 14:23 . Évalué à 4.\nPourquoi s'alourdir avec Python\nPython est depuis longtemps une dépendance de GNOME. C'était déja une des raisons de GoneMe.\nTu sais quel pourcentage de tes barrettes de RAM de Gnome 2.22\nPosté par boris le 08/09/06 à 01:30 . Évalué à 1.\nPosté par lezardbreton le 08/09/06 à 09:34 . Évalué à 3.\n1 Go, c'est un standard pour les ordinateurs neufs, ce qui est loin de représenter le marché actuel à mon avis. Et encore, je trouve encore des machines neuves avec seulement 256Mo de RAM.\nPosté par Christophe Fergeau le 07/09/06 à 14:29 . Évalué à 5.\n« 'ai je ne sais combien de machine virtuelles qui tournent en même temps.\nOué t'en a 2. Mon dieu. Tu sais ce qu'est une machine virtuelle ? tu sais quelle taille prend la machine virtuelle en mémoire ? »\nNon, t'en as 1 par appli python ou c#. Donc ça peut rapidement s'accumuler. Et évidemment, si 3 applis python utilisent la même lib écrite en python, la lib est chargée 3 fois en mémoire au lieu que ça soit partagé comme un .so\nPosté par TImaniac (page perso) le 07/09/06 à 15:12 . Évalué à 1.\nNon, t'en as 1 par appli python ou c#.\nUne machine virtuelle n'existe que pour le développeur. En effet il peut partir du principe qu'il y a une isolation stricte du matériel mais aussi de sa mémoire avec les autres applis, une machine virtuelle donc. Après techniquement y'a des libs qui sont chargés à l'exécution, et ces libs sont comme toutes les autres libs, elles sont partageables en mémoire.\nSi plusieurs environnement d'exécution sont lancés en parrallèle sans partage de lib, c'est une mauvaise configuration ou une lacune technique (genre les dev de l'environnement d'exécution n'en ont pas tenu compte), mais pas du tout un problème inhérent au principe de machine virtuelle.\nPosté par Christophe Fergeau le 07/09/06 à 15:52 . Évalué à 3.\n« Si plusieurs environnement d'exécution sont lancés en parrallèle sans partage de lib, c'est une mauvaise configuration ou une lacune technique (genre les dev de l'environnement d'exécution n'en ont pas tenu compte), mais pas du tout un problème inhérent au principe de machine virtuelle. »\nEt ? Je te parle pas de BisounoursVM ou de ChercheurEnInfoVM là, mais de la VM de python par ex, qui à ma connaissance ne partage pas entre VM les packages que tu récupères via import. Il me semble que ce genre de pb est aussi présent dans la JVM, et que des choses sont faites pour tenter de limiter ces soucis avec la VM C#.\nPosté par TImaniac (page perso) le 07/09/06 à 18:07 . Évalué à 3.\nCe que j'ai voulu dire, c'est que ce n'est pas une barrière technique, et qu'elle peut sauter. La preuve, même si ce n'est pas intégralement fait dans Mono, c'est en bonne parti fait.\nPour Python si tu l'dis je te crois. Mais si les équipes de Mono y arrive, je vois pas pourquoi celles de Python n'y arriverait pas. Où alors c'est que la plateforme est vraiment mal conçu pour ca, et ca sera tant mieux si on a justement une alternative à Python :)\nPosté par Antoine le 10/09/06 à 00:44 . Évalué à 1.\nPour Python si tu l'dis je te crois. Mais si les équipes de Mono y arrive, je vois pas pourquoi celles de Python n'y arriverait pas.\nLe modèle de Python est beaucoup plus souple que celui de .Net. En Python, le code (je parle du bytecode Python) est une donnée comme une autre, et notamment toutes les classes, fonctions, méthodes, sont sujettes au comptage de référence comme n'importe quel objet Python jusqu'aux "constantes" de base (True, False, None). Il est donc AMHA impossible dans l'état de partager le code puisque le comptage de référence sera distinct d'une instance de la VM à l'autre.\nPosté par Moonz le 07/09/06 à 20:40 . Évalué à 2.\n> sans partage de lib, c'est une mauvaise configuration ou une lacune technique\nsys.stdout = open("log_stdout", "w+")\nprint "Hello from spam.py"\nprint "hello from egg.py"\n$ python egg.py\nhello from egg.py\n$ cat log_stdout\nHello from spam.py\nMaintenant, imagine que python se mette à partager le module sys à travers toutes les instances de la VM...\nPosté par chimrod (page perso) le 07/09/06 à 22:01 . Évalué à 3.\nIl y a une différence entre le fait de charger un module pour toutes les instances, et le fait que les instances se partagent les données de ce modules..\nPython cherche les variables d'abord en local, puis en global, et enfin dans les modules, il est donc possible d'avoir un sys.stdout défini en local, et un autre dans le module sys. ( Il est évident que cela demanderait beaucoup de changement dans le code interne de python, mais cela pourrait être fait sans changement pour le code des applications python).\nPar contre, les fonctions elles, ne seraient chargées qu'une seule fois, et là serait l'économie\nPosté par Moonz le 08/09/06 à 18:20 . Évalué à 1.\nÇa, c'était un exemple simple. Tu peux aussi faire des trucs plus "pervers", du genre remplacer une fonction dans un module (os.getenv = my_getenv). Bon, là, ça reste simple: c'est toujours que toucher à des références.\nLes seuls truc qu'on puisse partager en python, c'est tout ce qui est immutable. Pas grand chose, en fait... Parce que même les fonctions ne le sont pas (ne parlons même pas des classes). Démonstration:\n... print "spam"\n>>> def egg():\n... print "egg"\n>>> spam.func_code = egg.func_code\nBon, le truc que tu peux partager par contre, c'est func_code qui est immutable. Mais le truc, c'est que je suis pas sûr que ce soit garanti qu'il le reste :p\nPosté par chimrod (page perso) le 18/09/06 à 11:37 . Évalué à 1.\nJe suis d'accord avec toi, mais je pense qu'il est possible de passer outre, justement grace au fait que tout soit mutable :)\nEn effet, les commande from spam import * et import egg font appel à la fonction __import__ que l'on *pourrait* redéfinir ( je ne dit pas que c'est quelque chose de siimple ) pour que les varialbes passent dans l'univers local, au chargement.\nEnsuite, dans le cas d'un assignement la fonction __setattr__ est appelée ( je n'ai pas fait les test, mais d'après la doc c'est le cas ) et là encore le fait qu'elle soit mutable nous permet d'intercepter les redéfinitions vers une fonction importée, et d'éviter l'écrasement.\nPour finir, une mise à jour des varialbes __methods__ __class__ etc permet de rendre toutes ces manippulations invisibles pour le programme...\nJe suis d'accord que ça n'est pas quelque chose de simple à mettre en place, mais je pense que python nous laisse assez de marge de maneuvre pour mettre en route un tel systeme. ( Bon apres c'est que le début, faut aussi gérer les erreurs pour pas qu'un prgramme ne fasse buguer tout les autres, faut gérer les threads etc, mais bon, ça fait une idée à proposer au google summer of code de l'an prochain ! :) )\nPosté par nolius le 07/09/06 à 14:21 . Évalué à 4.\npourquoi les brevets de mircosoft te pose un gros problème moral lorqu'il s'agit de mono et aucun lorsque ca concerne le noyau linux http://linuxfr.org/2004/08/02/16957.html\nà moins que tu n'utilise pas linux?\nPosté par liberforce (page perso) le 07/09/06 à 14:36 . Évalué à 3.\nGnome commence à remplacer des applications actuelles par des applications Mono\nC'est une question de liberté: les gens peuvent utiliser ce qu'ils veulent pour développer, et les autres sont libres d'utiliser les applications s'ils le veulent. Mais on ne "remplace" pas les applications par un équivalent mono, mais plus personne ne développe l'applet de prise de notes (en C), et un logiciel plus évolué en mono sort. Pourquoi s'en priver ? Et pourtant je t'assure que je ne suis pas du genre à vouloir une dépendance à mono. Mais tant que j'ai le choix de vire tomboy pour ne pas utiliser tomboy, je ne vois pas où est le problème.\nMais le problème est toujours le même: c'est celui qui fait le boulot qui décide. Si quelqu'un avait fait évoluer sticky notes, tomboy n'aurait pas eu de raison d'être intégré. D'ailleurs il y a un clone de Tomboy en C++ qui devrait être écrit (le gars compte faire ça d'un point de vue pédagogique).\nPosté par gnumdk (page perso) le 07/09/06 à 15:12 . Évalué à 3.\n>D'ailleurs il y a un clone de Tomboy en C++ qui devrait être écrit\nNon, ca existe déjà depuis longtemps ;)\nPosté par lezardbreton le 07/09/06 à 15:23 . Évalué à 3.\nOui, sauf que techniquement et fonctionnellement, c'est un projet abouti et ceci sans machine virtuelle. Là, on parle de Tomboy, donc entièrement l'inverse.\nPareil, je sors voir s'il fait beau dehors :)\nPosté par Mildred (page perso) le 07/09/06 à 22:02 . Évalué à 7.\nOn pourrait aussi imaginer que tout les framework de haut niveau s'intègrent ensemble en utilisant la même machine virtuelle, les même libs ...\nPourquoi pas avec la machine virtuelle Parrot (créée pour perl6) : http://www.parrotcode.org/\nPour le moment, les langages supportés le sont soit de manière incomplète, soit peu utilisés, soit juste des langages sans interêt pour coder des gros trucs, genre brainfuch, whitespace .... malhereusement.\nMais ça bouge quand même :)\n# Tango : bof\nPosté par Philippe F (page perso) le 07/09/06 à 11:13 . Évalué à 8.\nUn petit mot sur tango. Le but est louable, mais la methode est completement a l'inverse de la facon dont doit se developper une specification qui pretend etre adoptee par plusieurs bureaux.\nEn gros, une equipe consistituee principalement de developpeurs de Gnome s'est montee, a developpe tango sans aucune concertation avec des autres desktop et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau devaient adopter. C'est vraiment l'oppose des buts et du principe de freedesktop.\nIl y a un certain nombre de raison pour KDE de ne pas adopter tango. Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande, donc ils n'ont pas leur mot a dire sur le "standard". Ensuite, Gnome et KDE ont un style d'icone qui est different. Tango utilise le style Gnome qui ne s'integre pas du tout dans l'historique de KDE. Enfin, KDE a son propre style d'icone tres complet et n'a pas besoin de Tango.\nJe pense que le projet en soi est interressant mais pas pour plusieurs desktops.\nA contrario, on peut citer un certain nombre de specifications de freedesktop qui ont ete developpees en _cooperation_ avec les differents bureaux, et qui sont un succes :\n- placement des icones sur le systeme de fichier\n- organistion des themes sur le systeme de fichier\n- contenu des fichiers .desktop\n- utilisation de dbus\n- notification dans la barre des taches\n- applets dans la barre des taches\nA noter que tango n'est pas le seul projet a avoir fonctionner comme cela. On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc. Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.\nTango est un tout petit peu different de cette situation puisque c'est une specification deja adoptee au sein de Gnome. Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).\nDans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.\n[^] # Re: Tango : bof\nPosté par cruciforme le 07/09/06 à 11:25 . Évalué à 2.\nSi je ne m'abuse, tango c'est juste une unification des règles pour les icônes afin qu'elles s'intègrent mieux entre elles. Ca n'a pas de rapport avec freedesktop.\nPosté par lezardbreton le 07/09/06 à 11:40 . Évalué à 1.\nTango est un thème d'icones développé par des développeurs de GNOME avec l'idée de thème multi-desktops. Il a été poussé sur le serveur Freedesktop en espérant le faire passer pour un standard. C'est ce que signalait le rédacteur ci-dessus.\nDe plus, la licence creative commons ne lui permet pas de rentrer dans Debian (pour rappel : http://people.debian.org/~evan/ccsummary.html ).\nPosté par Simon TRENY le 07/09/06 à 12:14 . Évalué à 0.\nNon, Tango est avant tout une convention de nommage pour les themes d'icones. Pour l'instant, chaque environnement de bureau utilise son propre système de nommage ce qui fait que très souvent les thèmes d'icones pour KDE sont incompatibles avec ceux de Gnome, et vice versa. Et c'est cette spécification qui tend à devenir un standard Freedesktop.\nAprès, les membres du projet Tango ont créé un thème d'icones officiel qui suit les spécifications de nommage, mais rien n'empêche KDE d'utiliser un autre thème (tant qu'il suit les spécifiations).\nPosté par Mr_Moustache le 07/09/06 à 12:21 . Évalué à 4.\nLe thème d'icônes n'est pas le but premier de Tango, le projet vise d'abord à uniformiser leur dénomination et leur style et propose des outils pour créer un thème.\nAlors oui, ils ont décider de créer un thème d'icônes pour montrer ce que ça donne mais rien n'empêche d'en créer d'autres en suivant tout ou partie de ces règles avec la licence quivabien.\nSinon je trouve que ça va profond vers l'enculage de mouches et le *woin* *woin* ... Personne n'impose rien à l'équipe KDE...\nPosté par Gof (page perso) le 07/09/06 à 12:37 . Évalué à 4.\nTango est juste un thème d'icône, avec une charte graphique bien définie.\nEt leur but est, d'après leur site, de vouloir un thème d'icône commun à tout les DE.\nIl existe effectivement une convention de nommage des icône, mais celle-ci n'a rien a voir avec tango et lui est bien antérieur \nQuand à la position de KDE, elle est claire : jamais elle ne suivra la charte graphique de tango pour son thème par défaut. Le thème d'icône fait partie de l'identité visuelle du bureaux, et KDE tient à garder sa propre identité visuelle\nPosté par Mr_Moustache le 07/09/06 à 12:58 . Évalué à 6.\n* A complete set of application, mimetype, and stock icons designed using a defined style guide.\nMême si le projet de convention de nommage date, il est la base du projet ici pour qu'il puisse être adopter par tous les bureaux. Et comme on peut le voir, ça ne se résume pas uniquement à ça, mais le thème d'icônes n'est pas destiné à être unique, c'est une proposition du projet (on ne va pas le leur reprocher).\nPosté par Étienne BERSAC (page perso) le 07/09/06 à 15:33 . Évalué à 3.\nLe thème de Gnome 2.16, n'est pas Tango. Les specs Tango propose une petite palette de base et des règles pour avoir des icônes cohérentes (perspective, reflets, bordures, etc.). On peut très bien faire un thème Tango compliant sans reprendre l'esprit des Thème Gnome.\nPar contre, c'est clair que le thème de Tango est dans la filiation de hicolor. Je pense que c'est dû à l'importante contribution de jimmac, entre autre.\nPosté par rewind le 07/09/06 à 11:27 . Évalué à 6.\nLa manière de faire de GNOME est toujours la même vis-a-vis de freedesktop et je ne l'apprécie pas particulièrement. On pourrait revenir aussi sur DBus qui, bien qu'adopté par KDE, a été imposé par GNOME. KDE a fait un effort alors que DCOP marchait très bien. On pourrait aussi parler de gstreamer, mais je crois que le troll précédent fut suffisament long pour ne pas revenir dessus. Et maintenant Tango.\nC'est trop pour moi. Autant je trouve GTK bien fait techniquement, autant la politique de GNOME m'exaspère au plus haut point (pas que pour freedesktop d'ailleurs, mais aussi avec les HIG, le choix de C#, etc) et c'est une des raisons qui m'ont fait choisir KDE plutôt que GNOME. C'est dommage d'en arriver là.\nPosté par Gof (page perso) le 07/09/06 à 11:42 . Évalué à 7.\nGNOME n'a pas imposé DBus à KDE.\nDBus a été construit par des développeur de GNOME et de KDE\nDBus est en quelque sorte un DCop2\nLe fait que les 2 bureaux utilise le même système est un avantage pour tout le monde.\nPosté par Philippe F (page perso) le 07/09/06 à 12:10 . Évalué à 10.\nJe ne suis pas trop d'accord avec toi. Il y a certains developpeurs dans Gnome qui ont une attitude vis a vis de KDE qu'on peut qualifier de detestable mais beaucoup ont une attitude tres constructive. Il suffit d'ignorer les geneurs et d'avancer avec les gens qui veulent avancer.\nDbus n'a pas ete impose a KDE. Dbus a des avantages sur DCOP : pas de dependance a X, pas de dependance a Qt. Il aurait ete possible de re-ecrire DCOP pour en faire le DBUS actuel mais le fait est que personne ne l'a fait. Comme souvent en logiciel libre, c'est celui qui fait le travail qui decide et personne n'a fait le travail pour DCOP.\nGlobalement, DBUS est une belle histoire. Il faut savoir avancer en mettant de cote son NIH syndrome. DBUS a un gros avantage par raport a DCOP: il est reconnu au sein de Gnome. Ca veut dire que dans le mesure ou KDE ne perd pas en fonctionnalite vis a vis de DCOP, c'est une victoire pour le desktop linux : on va pouvoir resoudre plein de probleme pa DBUS et permettre aux deux bureaux majeurs d'en profiter : notification de material branche, baterie faible, etc etc.\nLa seule chose qui m'agace, c'est les enthousiastes de Gnome qui s'extasient sur les possibilites de DBUS et presentent cela comme une revolution lancee par Gnome alors meme que la plupart desdites fonctionnalites sont presentes depuis 6 ans dans KDE.\nPosté par Christophe Fergeau le 07/09/06 à 12:18 . Évalué à 2.\n« La seule chose qui m'agace, c'est les enthousiastes de Gnome qui s'extasient sur les possibilites de DBUS et presentent cela comme une revolution lancee par Gnome alors meme que la plupart desdites fonctionnalites sont presentes depuis 6 ans dans KDE. »\nTu m'en vois surpris, j'ai pas le souvenir d'avoir vu qui que ce soit prétendre que DBus avait été lancé par GNOME du côté des Gnomistes déjà... C'est plutôt vu comme un projet freedesktop (lancé par Havoc Pennington il est vrai, et financé par RedHat). Par contre, oui, il y a clairement pas mal de personnes super contentes de ce qu'il est possible de faire en utilisant DBus dans Gnome, choses qui sont généralement faisables avec KDE depuis un moment.\nPosté par clearstream le 07/09/06 à 18:51 . Évalué à 2.\n> On pourrait revenir aussi sur DBus qui, bien qu'adopté par KDE, a été imposé par GNOME.\nEt comment GNOME a fait ça ?\nAvec des pots-de-vin ?\nGNOME allait attaquer KDE avec des brevets ?\nArrêter de dire des conneries. KDE a pris Dbus car ça leur plaisait. Point barre.\n> On pourrait aussi parler de gstreamer\nEt KDE n'a pas pris Gstreamer, et il n'y a pas eu de mesure de rétorsion.\nPreuve que Gnome n'impose rien à KDE. Preuve que freedesktop n'impose rien à KDE.\nMais si Gnome/Gstreamer/Freedesktop/etc pensent que KDE fait une connerie, ils ont le droit de le dire. Et vice-versa.\n> c'est une des raisons qui m'ont fait choisir KDE plutôt que GNOME. C'est dommage d'en arriver là.\nC'est vraiment dommage. Voire con.\nPosté par clearstream le 07/09/06 à 18:37 . Évalué à 2.\n> En gros, une equipe consistituee principalement de developpeurs de Gnome s'est montee\n> a developpe tango sans aucune concertation avec des autres desktop\nIl y a toujours des phases où on bossent dans son coin. Surtout à l'initialisation d'un projet et jusqu'en phase alpha voire beta. Tant que tu n'as rien de concret a proposer, c'est comme ça.\nEt qu'es-ce que tu entends par "concertation avec les autres desktop" ?\nIl y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars".\nSi ceux qui bossent sur Tango n'avait pas un peu l'assurance que leur boulot était utile, ils auraient laissé tomber Tango très vite. Tu ne crois pas ?\nS'il voulait faire des icones uniquement pour Gnome, je ne vois pas pourquoi ils sont aller sur freedesktop. Ca serait totalement inutile (Gnome a déjà produit des icones sans freedesktop).\n> et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau\nSelon toi pour être un standard de tous les projets de bureau, il suffit de le déclarer. Tu ne trouves pas que c'est un peu léger ?\n> C'est vraiment l'oppose des buts et du principe de freedesktop.\nLis freedesktop :\nfreedesktop.org is not a formal standards organization, though some see a need for one that covers some of the areas we are working on. For Linux operating system standards, look at the [WWW]Linux Standard Base project. [WWW]The X.Org Foundation and the [WWW]IETF are other groups that do formal standards. The [WWW]Free Standards Group is one group that publishes "de jure" standards for free software -- freedesktop.org is loosely affiliated the FSG.\nUnlike a standards organization, freedesktop.org is a "collaboration zone" where ideas and code are tossed around, and de facto specifications are encouraged. The primary entrée to these discussions is the [WWW]xdg mailing list.\nNote: freedesktop.org is not a standards body. The naming of this page is a historical accident, and will take a bit of wiki lifting behind the scenes to fix.\nIl n'y a pas tango dans la liste (pas encore peut-être).\nC'est TOI qui vient décréter que Tango est un standard et à partir de là tu fais des raisonnements fumeux.\n> Il y a un certain nombre de raison pour KDE de ne pas adopter tango.\nTa critique de Tango/freedesktop est facile. Tu dois être de ces KDE-fans qui vomissent freedesktop, ou du moins voit en freedesktop une "menace" pour KDE, mais n'ose pas l'avouer clairement.\nCa me fait bien rigoler les gens qui critiquent l'implication de Gnome dans freedesktop et surtout quand ça vient de KDE.\nKDE ne fait pratiquement aucune proposition au niveau de freedesktop et ne fout pratiquement rien dans freedesktop. OK et très bien. Mais dans ce cas KDE fairait mieux de la fermer sur ce qui est réalisé au niveau de freedesktop.\n> Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande\nSi KDE était plus impliqué dans freedesktop, la question ne se poserait même pas !\nKDE ne fout pratiquement pour freedesktop et tu veux que freedesktop cire les pompes de KDE. Tu ne trouves pas que tu vas un peu loin ?\n> Ensuite, Gnome et KDE ont un style d'icone qui est different.\nTango est fait pour unifier les desktops.\nSi ce n'est pas possible car la philosophie (vue côté utilisateur) des desktops est trop différente alors tant pis.\nMais l'effort de Tango est très respectable.\n> On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc.\nCe boulot la DOIT être fait au niveau de freedesktop. Freedesktop est là pour ça !\nAlors S'IL VOUS PLAIT contributeurs de KDE, allez sur freedesktop, contribuez, protestez, gueulez, faites entendre votre voie, mais arrêter de critiquer freedesktop car vous n'y participez pas assez.\n> Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.\nCe qui est tout à fait normal. Contrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard.\nAu-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.\nLe rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.\n> Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).\nJe me répète : je crois que tu connais mal les objectifs de freedesktop. Pour donner un bon exemple, freedesktop est né pratiquement en même temps que dbus est né. Dbus n'est pas rentré dans freedesktop lorsqu'il a atteint la version 1.0 (version qu'il n'a d'ailleur pas encore atteint).\n> Dans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.\nEt freedesktop s'en plaint ?\nMais cairo a toute sa place sur freedesktop car ça peut intéresser tous les desktops (sauf KDE).\nSi KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.\nPosté par Philippe F (page perso) le 08/09/06 à 02:26 . Évalué à 3.\n<< Il y a toujours des phases où on bossent dans son coin. Surtout à l'initialisation d'un projet et jusqu'en phase alpha voire beta. Tant que tu n'as rien de concret a proposer, c'est comme ça. >>\nC'est tout a fait vrai. Mais pour une implementation. Pour une specification qui se veut commune a plusieurs bureaux en revanche, la concertation est fondamentale. Et Tango est justement un projet avec un but d'unification des icones pour plusieurs bureaux.\nof the Tango project is not only the icon theme. The purpose is to work\ntowards unifying the visual aspects of all the desktops.\n<< Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars". >>\nAh oui ? Au contraire, les gens de KDE par exemple ont dit "c'est ininteressant pour KDE, on n'adoptera jamais votre truc mais continuez les gars".\nConcernant XFCE :\nNobody said that Xfce will ship the Tango icon theme. Brain just said\nthat he wants to "join as Xfce representative". We'll discuss that issue\nwhen the time arrives (which don't seem to be anytime soon).\n<< KDE ne fout pratiquement pour freedesktop >>\nJe suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.\nPar exemple si on prend les archives du mois d'aout 2006 :\nTu noteras des messages de Waldo Bastian, Aaron Seigo et Lubos Lunak. Il y a beaucoup plus de developpeurs KDE que cela qui lisent freedkestop mais ils n'ont pas toujours quelque chose a dire.\nTu peux noter le travail extremement actif de Waldo Bastian sur la stabilisations d'un certain nombre de specifications, en ce moment la spec qui decrit les fichiers .desktop\nOn peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.\nContrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard. Au-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.\nC'est fort parce que tu reussis a etre tout a fait d'accord avec ce que je pense tout en etant persuade que je pense le contraire. Relis mon post calmement et peut-etre que ce sera plus clair. Peut-etre me suis-je mal exprime ?. J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.\nFreedesktop est au contraire un endroit de concertation et j'ai cite de nombreuses specs freedesktop sur lesquelles la concertation a eu lieu et a donne des resultats interessants.\nTango n'a pas suivi ce processus fondamental de concertation et a cause de cela, restera un projet dedie a Gnome. Le coeur de Tango en lui-meme me parait tout a fait interessant mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.\nComme DCOP ?\nPosté par clearstream le 08/09/06 à 21:17 . Évalué à -3.\n> Ah oui ? Au contraire, les gens de KDE par exemple ont dit "c'est ininteressant pour KDE, on n'adoptera jamais votre truc mais continuez les gars".\nBen Tango ne sera pas un standard.\nIl n'empêche que l'effort de tango est à saluer.\nPerso, quand je vois une appli KDE, j'ai du mal à comprendre les icones. Probablement car je suis trop habitué à celles de Gnome.\nMais s'il peut y avoir une "barrière" de moins pour que j'utilise des applis KDE sous Gnome, ou que je passe avec moins de difficulté à KDE, alors tant mieux.\n> Je suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.\n> On peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.\nDbus a des fonctionnalités que n'avais pas DCOP. Certes KDE pouvait faire évoluer son propre système pour avoir les fonctionnalité de Dbus.\nMais il ne faut pas faire croire que KDE s'est "sacrifié" pour avoir Dbus. Ca les interessait, ils l'ont pris. C'est intelligent.\n> J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.\nBen je ne comprend toujours pas.\nKDE veut "s'imposer" (notes les guillemets) dans le desktop et Gnome aussi. Il n'y a rien d'anormal et rien à reprocher à ça.\nLe problème, est quel est ta définition de "s'imposer".\nSi c'est vouloir être largement utilisé et s'en donner les moyens (ici "médiatique) alors je suis d'accord avec toi.\nSi c'est *forcer* les autres a utiliser Tango, je ne suis pas d'accord avec toi.\nD'ailleurs comment Tango peut *forcer* les autres à utiliser Tango ?\n> mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.\nBelle démonstration que Tango n'impose rien.\n> Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.\n> Comme DCOP ?\nLe fait est que KDE ne propose pas grand chose. Tu me (nous) dis que KDE bosse avec freedesktop et je m'en félicite.\nM'enfin, Gnome (ou des développeurs proches de Gnome) a fait au moins cinq fois plus de propositions. Je ne vais pas te les rappeler.\nD'ailleurs je ne connais pas de projet sur freedesktop qui soit à l'initiative de KDE. N'étant pas un expert KDE, si je me trompe n'hésite surtout pas à éclairer ma lanterne.\nIl peut y avoir une explication rationnelle à ça. KDE est C++/Qt centrique. Ce n'est pas un reproche, c'est un constat. KDE pense C++, KDE pense Qt, KDE pense KDE. C'est aussi leur force.\nGnome pense libgnome, gtk+, pango, glib, cairo, gstreamer, bindings, python, C#, java, etc...\nQuelque part Gnome est plus disposé a faire des propositions réutilisable sans se "trainer un gros Qt et du C++ inadapté pour faire des bindings".\nPour prendre un exemple chaud, Gnome (des développeurs "fan" de Gnome) fait un serveur multimédia. C'est Gstreamer, ça n'utilise que glib et il y a des bindings. KDE fait un serveur multimédia (un wrapper). C'est phonon, ça demande du C++, Qt, libkde (à confirmer), et les bindings ils n'y ont peut-être même pas pensé.\nBen je comprend que KDE ne pousse pas phonon sur freedesktop car phonon est KDE centrique et ne veut pas être une solution "universelle".\nPosté par Gof (page perso) le 08/09/06 à 21:51 . Évalué à 4.\nEt toi tu n'as toujours pas compris ce qu'est Phonon.\nPhonon n'est PAS un serveur multimedia\nPhonon est juste une API qui respecte les conventions de nommages et les habitudes des développeurs KDE\nOn ne peux pas vraiment dire que Phonon dépends des kdelibs, puisqu'il est inclus dans les kdelibs (comment peut on déprendre de sois même ?)\nMais oui, Phonon utilise de base QObject pour les signals/slots, QString pour les chaînes de caractères, KUrl pour les noms de fichier. Ça fait partie des conventions de nommages.\nJ'espère que ce commentaire de fera comprendre ce qu'est Phonon et que ce sera la mort du troll sur Phonon. (mais j'ai des doutes)\nPosté par clearstream le 09/09/06 à 12:18 . Évalué à -1.\n> Phonon n'est PAS un serveur multimedia\n- "un serveur multimédia (un wrapper)"\n> On ne peux pas vraiment dire que Phonon dépends des kdelibs, puisqu'il est inclus dans les kdelibs (comment peut on déprendre de sois même ?)\nDonc le retirer de kdelibs ne doit pas poser de problème ?\nCa serait bien pour les applis Qt tu ne trouves pas ?\n> KUrl pour les noms de fichier.\nPour gstreamer, l'utilisation de gnome-vfs se fait via un plugin. Tu l'utilises ou non, tu l'installes ou non. Si KDE veut faire un plugin Kurl pour Gstreamer il ne doit pas y avoir de problème (s'il n'existe pas déjà). Il existe aussi un binding de Gstreamer pour C++ (pas finalisé malheureusement).\nVoilà la différence. Gstreamer (les développeurs Gnome en général) pense aux autres desktops, pense aux autres languages. Peut-être pas assez, mais beaucoup beaucoup plus que KDE.\nPourtant si Phonon est une brillante idée (ce que je ne crois pas, mais je peux me tromper et l'histoire jugera) alors ça peut intéresser les développeurs de Qt-only, les développeurs de gtk+ (du moins gtkmm) et ça devrait même intéresser les développeurs C++ ligne de commande. Surtout que je viens de voir que Qt4 a fait des efforts pour spliter la librairie.\nMais KDE n'a pensé qu'à KDE. Je ne dis pas que KDE est un "méchant". Ca doit être culturel/historique.\nMerci d'avoir abondé dans mon sens.\nPosté par Gof (page perso) le 09/09/06 à 14:22 . Évalué à 2.\n« Si KDE veut faire un plugin Kurl pour Gstreamer il ne doit pas y avoir de problème. Il existe aussi un binding de Gstreamer pour C++. »\nEh bien alors il n'y a pas de problèmes puisque c'est exactement ce que Phonon est. Phonon peut être en quelque sorte considérer comme un binding pour l'API KDE.\nAlors oui, Phonon est "réservé" à KDE, et c'est normal. Qu'est-ce que Gnome irait faire avec un binding multimédia pour KDE ?\nPosté par clearstream le 09/09/06 à 14:37 . Évalué à 0.\n> Qu'est-ce que Gnome irait faire avec un binding multimédia pour KDE ?\nJe n'ai pas parlé de Gnome/Phonon mais de Qt/Phonon, gtkmm/Phonon et C++/Phonon.\nEt notes que dans ta question il y a la réponse. Ainsi KDE l'a voulu.\nPosté par Gof (page perso) le 09/09/06 à 15:02 . Évalué à 4.\nDonc en gros, tu reproche à KDE de faire progresser KDE ?\nBha oui, les dev KDE ne devrais plus faire avancer KDE, ils devraient plutôt aider ceux de Gnome à rattraper leur retard (/ironique)\nPosté par clearstream le 09/09/06 à 15:23 . Évalué à 1.\n> Donc en gros, tu reproche à KDE de faire progresser KDE ?\nApprends à lire s'il te plait.\n- "KDE est C++/Qt centrique. Ce n'est pas un reproche, c'est un constat. KDE pense C++, KDE pense Qt, KDE pense KDE. C'est aussi leur force."\nPosté par Philippe F (page perso) le 09/09/06 à 15:51 . Évalué à 7.\n> Le fait est que KDE ne propose pas grand chose.\nPlus de la moitie des specs de freedsktop ont ete proposees par KDE, discutees puis adoptees. Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.\nLis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.\n> M'enfin, Gnome a fait au moins cinq fois plus de propositions.\nJe m'eleve en faux contre cette proposition. 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.\nUne grande partie du travail de freedesktop, c'est de proposer des specifications, avec si possible une ou plusieurs implementaitons. Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client.\n> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,\nC'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants. C'est sur que si tu comptes comme ca, Gnome a beaucoup de projets.\nGstreamer n'assure pas la compabilite binaire ni source entre version. C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire. 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 (note que c'est le comportement a l'heure actuelle).\nLa solution, c'est de construire une couche d'isolation qui pourra fonctionner par exemple avec les diverses versions de gstreamer et aussi avec d'autres serveurs son, et qui elle sera stable. C'est phonon. Une api pour fournir des services sons aux applications KDE sans que celles-ci aient besoin de savoir si le serveur son installe est arts, esd, gstreamer v1, gstreamer v2, gstreamer v3, nmm ou autres.\nPhonon en est encore a la phase experimental. Deja quand on voit comment il est mal recu, je vois mal comment on pourrait le pousser. J'espere pour ma part qu'il suivra le chemin de DCOP, c'est a dire qu'on realisera qu'il resoud un reel probleme et apporte qqch d'util, et qu'a partir de la, soit on adaptera phonon pour etre independant de KDE, soit on redeveloppera un wrapper de serveur son utilisable par tous les projets.\nPosté par clearstream le 09/09/06 à 17:41 . Évalué à 2.\n> Plus de la moitie des specs de freedsktop ont ete proposees par KDE\n> Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.\nJe 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).\n> Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.\nKDE fait des propositions pour que des projets hébergés par freedesktop soient utiles à KDE. C'est normal et très bien venu.\nMais quel projet a été initialisé par KDE pour l'intéropérabilité ?\nSpécification pour gestionnaire de fenêtre ? Non.\nDbus ? Non.\nHAL ? Non.\nUn API multimédia pour tous les desktops ? Non.\nQuoi alors ? C'est la seconde fois que je pose la question.\n> 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.\nBen 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.\n> Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne.\nTu veux dire que le dbus de KDE n'a pas de dépendance avec glib ?\nBen 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).\nTu vas peut-être maintenant dire que KDE a sa propre implémentation de HAL ?\nJe te donne tout de suite la réponse : Non.\n> maintenant deux implementations de la partie client.\nNon. KDE a fait une surcouche.\nSi je me trompe (je n'ai pas vérifié), indique où sont les sources de l'implémentation de dbus par KDE.\n> C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants.\nC'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.\n> Gstreamer n'assure pas la compabilite binaire ni source entre version.\nIl 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.\nL'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).\nDis moi si je me trompe, mais KDE 4 ne sera pas compatible avec KDE 3.\n> C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire.\nPuisque 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.\nEt 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).\nPourtant KDE prend dbus mais refuse gstreamer au motif de la non stabilité de l'API.\nOn n'est pas dans le deux poids deux mesures ?\nEt je ne te parle même pas de HAL où la situation est "pire" (notes les guillemets).\n> 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\nEt 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.\nCes problèmes sont à gérer par les gestionnaires de paquet et ils font ça très bien et ils existent pour ça.\n> (note que c'est le comportement a l'heure actuelle).\nAbsolument 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.*.\nPosté par Seazor le 10/09/06 à 13:52 . Évalué à 2.\nJe connais un projet freedesktop venant de KDE : ghns.\nPar contre, je suis loin de connaitre et de suivre les dev de freedesktop, je ne pourrais donc pas te dire pour les autres d'où ils viennent et qui fait quoi.\nPour DBus, si j'en crois http://www.freedesktop.org/wiki/Software_2fDBusBindings , kde 4 ne dépendra probablement que de QT puisque le binding sera distribué avec. Par contre, pour les dépendances de QT à ce propos, c'est une autre histoire.\nJe crois que ton scenar devait être celui de KDE 3 et son support partiel (et forcément au second plan face à DCop). Il a du évoluer depuis.\nGnome essai d'avoir et de développer des solutions utilisables par plusieurs desktops et KDE non.\nJe peux me tromper mais j'ai plutôt l'impression que KDE propose plus sur les specs que sur le code.\nP-ê parce qu'ils n'aiment pas se reposer sur du code extérieur qui ne soit pas considéré comme suffisamment mature.\nC'est qu'ils y tiennent à leur compatibilité entre mineurs et que pour eux, c'est considéré comme un risque.\nJ'ai l'impression qu'une chose qu'ils n'aiment pas chez KDE, c'est les cohabitations de différentes versions de libs.\nQT4 inclus la compatibilité vers QT3 (au lieu de faire cohabiter les 2). KDE4, je pense que ce sera pareil (pas sur). DBus passera par QT (voir plus haut).\nC'est p'tet pour ca que faire cohabiter Gst 0.8 et 0.10 ne leur plait pas (ils préfèrent passer par phonon même si phonon ne sert que PARTIELLEMENT à ça).\nPosté par clearstream le 10/09/06 à 15:58 . Évalué à 1.\n> DBus passera par QT\n? KDE passera par Qt pour utiliser DBus.\n> C'est p'tet pour ca que faire cohabiter Gst 0.8 et 0.10 ne leur plait pas\nCa ne plait à personne. Comme ça ne plait a personne d'avoir gtk 1.x et gtk 2.x.\nRester indéfiniment sur Gstreamer 0.8 et gtk 1 ne plait aussi à personne.\nDe toute manière, maintenant il faut fouiller grave pour trouver des applis qui ne sont pas passées à Gstreamer 0.10. Pour Gnome c'est fait depuis plus de 6 mois.\nPosté par Moonz le 11/09/06 à 11:41 . Évalué à 2.\n> De toute manière, maintenant il faut fouiller grave pour trouver des applis qui ne sont pas passées à Gstreamer 0.10. Pour Gnome c'est fait depuis plus de 6 mois.\nPosté par clearstream le 11/09/06 à 20:59 . Évalué à 0.\nToutes les applis Gnome depuis Gnome 2.14 (le boulot a été fait dans Gnome 2.13). Gnome-media, gnome-applets, gnome-volume, totem, etc.\nPosté par Seazor le 11/09/06 à 12:58 . Évalué à 1.\nT'as oublié le (voir plus haut) qui te le disait déjà qq lignes plus haut ! (y compris le lien vers freedesktop)\nIl y a ceci aussi : http://linuxfr.org/~tanguy_k/22063.html\nEt pour confirmation, lis donc le descriptif de cette présentation de l'aKademy (fin de ce mois) : http://conference2006.kde.org/conference/talks/27.php\nCa leur plait d'autant moins que ca demande des adaptations dans les softs, qui sont causées par qqch d'extérieur.\nEt si mes souvenirs sont bons, chez KDE, ils veulent une compatibilité source à travers toute la version majeure.\n=> un soft prévu pour 4.0 doit normalement pouvoir compiler dans 4 ans sur un éventuel kde 4.5\nEt si la compilation de (par exemple) kopete pour kde 4.0 foire sur kde 4.5 à cause des "ding dong" accompagnant les messages qui auraient été prévus pour Gst 0.10 non installé car devenu obsolete entretemps, ils vont l'avoir mauvaise.\nJe commence même à me demander ce que Kde 4 va utiliser d'extérieur sans les wrapper (QT pour X, dbus et plein d'autres choses, phonon pour le mmedia, solid pour le matos, etc ).\nIl doit pas y avoir grand chose ! (si qqun sait...)\nIl n'y aura probablement que les applis ayant des besoins spécifiques (traitement audios ou videos avancés par exemple) qui n' utiliseront pas les wrappers parce qu'ils leurs sont insuffisants. Et ça en connaissance de cause.\nEt ces applis seront extérieures à KDE ou au mieux dans kde-extra.\nPosté par clearstream le 11/09/06 à 20:55 . Évalué à 1.\n> Il y a ceci aussi : http://linuxfr.org/~tanguy_k/22063.html\nCe n'est pas une réécriture de Dbus. C'est l'encapsulation de dbus (les même sources que ceux de freedesktop) dans Qt.\n> Et pour confirmation, lis donc le descriptif de cette présentation de l'aKademy (fin de ce mois) : http://conference2006.kde.org/conference/talks/27.php\nCa ne change rien. Tu devrais le relire attentivement.\n> Et si mes souvenirs sont bons, chez KDE, ils veulent une compatibilité source à travers toute la version majeure.\nGnome ne l'exige pas.\n> Je commence même à me demander ce que Kde 4 va utiliser d'extérieur sans les wrapper\nwrapper est différent de refaire l'implémentation.\nAu-dessus il y avait :\n- "Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client."\nIl n'y aura qu'un implémentation de la partie client. Mais celle-ci aura un "binding" qt/c++ pour les développeurs qui le veulent.\nPosté par Seazor le 12/09/06 à 11:28 . Évalué à 2.\nCa n'empeche pas que les applis KDE n'ont aucune dépendance directe vers qqch non KDE. (sauf besoin spécifique je le rapelle)\nEt je crois que c'est le mot "directe" qui est important dans toute cette histoire.\nD'où une différence dans les besoins de stabilité des APIs utilisées.\nAjoute cette contrainte aux discussions sur Gst et ca devrait finir d'expliquer l'interet de Phonon.\n- Ca n'est de toutes façons pas de l'utilisation directe. (voir plus haut)\n- L'un peut évoluer vers l'autre de manière transparente pour les applis. (et cette transparence est un point important pour la compatibilité évoquée au dessus)\nIl n'y aura qu'un implémentation de la partie client.\nEt ? c'est celle-là qui les intéresse... non ? ;-)\nNote : pendant que j'écrivais ceci, l'intervention ci-dessous de Johann apporte encore plus de poids !\nIl me semblait que le but d'originie était : compatibilité source sur une X et binaire sur une X.Y. Mais là, c'est encore mieux !\nPosté par Johann Ollivier-Lapeyre (page perso) le 12/09/06 à 11:07 . Évalué à 3.\nC'est mieux que ça. on veut (et sur la branche .x, on a eu) une compatibilité BINAIRE.\n=> un soft prévu pour 4.0 doit normalement pouvoir s'executer sans recompilation dans 4 ans sur un éventuel kde 4.5\nD'où l'utilité de phonon car gstreamer ne garantie meme pas la compatibilité source, et ça aurait entrainé au bout de ans, non pas 0.10 et 0.12 ensemble, mais 0.10, 0.12, 0.14, 0.16.... simultanément, en esperant que ce joyeux monde cohabite, et en maintenant les patch de sécurité là dessus.... bonjour le bordel. Plus certainement, KDE aurait choisi autre chose et on se serait retrouvé avec 2 backend différent pour Gnome et KDE.\nPosté par Christophe Fergeau le 12/09/06 à 16:29 . Évalué à 3.\nBon, arrêtez de dire que GStreamer ne garantit pas la compatibilité source ou binaire. Comme ça a été dit précédemment, GStreamer garantit à la fois une API et une ABI stable *pour une release majeure* (eg 0.8.x, 0.10.y, ...).\nCe qui pose pb à KDE, et c'est une raison parfaitement valable, c'est que les développeurs de GStreamer ne veulent/peuvent pas garantir une version *supportée* *ayant une API et une ABI stable* pour toute la durée de vie de KDE 4.x (on va dire de l'ordre de 5 ans histoire de fixer les idées).\nPosté par Johann Ollivier-Lapeyre (page perso) le 13/09/06 à 13:52 . Évalué à 2.\nc'est ce qu'on entend par stable effectivement. Et y'a pas vraiment de reproche là dessus de ma part sachant que gstreamer est encore jeune (et numéroté en 0.*), et que les changements chez gstreamer sont certainement justifiés.\nOn pourrait aussi imaginer un mariage KDE/gstreamer pour KDE 5.x si les choses évoluent bien, j'ai aucun problèmes là dessus non plus.\nPosté par Gof (page perso) le 08/09/06 à 14:04 . Évalué à 4.\nJe peux essayer de tanter une explication trollistique du pourquoi KDE serait moins impliqué dans freedesktop que GNOME.\nGNOME a plus besoin de freedektop, alors que KDE n'en a pas vraiment besoin.\nKDE est très complet et a déjà toute les technologie nécessaire pour une bonne intégration dans son bureaux.\nGNOME quand à lui est beaucoup moins complet. Un utilisateur de GNOME doit souvent utiliser un bon nombre d'application qui ne sont pas de GNOME. (toutes les application GTK-only)\nJe vois donc freedesktop comme une tentative d'intégrer les applications gtk-only à GNOME\nMais KDE, bien qu'il n'a pas réellement besoin de freedesktop, s'y implique quand même. KDE n'est pas Microsoft, et n'a pas d'intérêt à restreindre les utilisateur à leur bureau. C'est une bonne chose de laisser la liberté aux utilisateurs d'utiliser des application non KDE sous KDE, ou d'utiliser des applications KDE hors de l'environnement KDE (<troll>y compris sous Windows</troll>)\nCeci dit, ce n'est que mon analyse à moi. Je me trompe peut-être\nPosté par Jean-Christophe Berthon (page perso) le 07/09/06 à 19:41 . Évalué à 7.\nDésolé d'intervenir mais je crois que tu te trompes.\n(Note : je suis fana de KDE)\nLe but de Tango c'est avant tout l'ergonomie ! C'est de définir des règles pour l'illustration d'une interface graphique. Ces règles impliquent en gros que le but d'un thème n'est pas d'être flashi mais d'être utilisable par tout le monde : c'est-à-dire par n'importe quel humain et ce quelque soit soir culture ou un éventuel handicap.\nPar exemple pour faire simple. Peut-être connais-tu l'application Eudora. C'est un client e-mail comme Outlook Express ou Thunderbird. Les développeurs d'Eurdora étant tous américains, lorsqu'ils ont choisi une icône servant à représenter leur produit, ils ont tout bonnement utilisé l'espèce de tube avec le petit drapeau que les américains ont comme boîte au lettre (ex: http://messagerie.ac-nancy-metz.fr/images/eudora.gif) Pour information, quand le facteur aux US met du courrier dans une boîte comme celle-là, ils relèvent le petit drapeau. C'est exactement ce que montrait Eudora dans la petite icône de la barre de notification. Le problème est que c'était peut-être extrêmement intuitif pour des américains, mais ça laissait perplexe le reste du monde !\nTango, c'est un projet qui a pour but d'essayer de définir des règles qui peuvent éviter ce genre d'éceuille. C'est de l'ergonomie d'interface.\nUn exemple de ce que préconise Tango : un navigateur internet ce doit d'avoir 2 flèches, une pointant vers la gauche et l'autre la droite. Ces 2 flèches servent à la navigation sur internet, ce qui permet de revenir sur la page précédente et de retourner à la page d'après. Mais ils indiquent que pour une meilleur compréhension de ce méchanisme par l'utilisateur, la flèche permettant de revenir en arrière (la plus utilisée) devrait être accompagnée du texte "Back" (ou "Précédent") afin d'être plus facilement compréhensible pour un novice, et plus facilement identifiable ou cliquable (le bouton état plus gros avec le texte) pour quelqu'un connaissant déjà cette fonctionnalité.\nAprès que Gnome (et même peut-être les instigateurs de Tango) propose un thème "tango-compliant" ne veut pas dire que KDE se doit de l'utiliser ! Bien sûr, mais KDE a donc la possibilité de faire un thème "tango-compliant" tout en étant un thème KDE.\nPosté par Johann Ollivier-Lapeyre (page perso) le 08/09/06 à 10:49 . Évalué à 5.\nL'aspect ergonomique des icones est important oui. On y travaille sur Oxygen et je crois que chez MS ou Apple aussi... Sur Oxygen, on utilise aussi par exempleune palette de couleur différente selon l'importance de l'icone... Enfin bref.\nIl n'empeche que Tango est en train de manquer son objectif. Qu'un projet de ce type travaille en comité restraint au début c'est normal. Mais faire un commité 100% Gnome et arriver avec un theme au look typiquement gnome en voulant le mettre partout... ben ça passe pas, surtout quand chez KDE on trouve que c'est moche a vomir (les gouts toussa....).\nDéfinir une spec de theme commune ensemble (nomage,taille...) et un theme tango-gnome et tango-kde, ça serait bien passé.\nApres, pour l'avenir, je sais pas. Je ne crois pas qu'on aura le temps de changer le format de theme de KDE pour faire du Tango, et faudrai aussi modifier le format Tango en partie (accepteraient ils nos demandes). Franchement, j'y crois pas sans contributeurs supplémentaires.\nPosté par Jean-Christophe Berthon (page perso) le 08/09/06 à 15:19 . Évalué à 3.\nAu fait, je viens de faire un tour sur le site de Tango et un paragraphe m'a frappé :\nInterested contributors from Gnome, KDE, and other free and open qusource projects are welcome.\nApparemment, un groupe de personne a initié le projet et invite tout le monde à y participer. Maintenant, je voudrais bien connaître pourquoi toi et la personne orginaire du thread "Tango : bof" pensez que le projet Tango est fait dans son coin.\nJe commence à être un vieux routard de Linux FR et de l'internet en général, pour me rendre compte que des rumeurs sont en continue créées et entretenues (beaucoup de personne s'aime lire, comme d'autre - dont moi ;-) - s'aime s'entendre parler).\nBref, donc si je résume :\n- Tango serait incarner par des gnomistes seulement\n- Tango ferait tout dans son coin\n- Les kdeistes n'ont pas été consultés\nCa c'est les bases du message initial de notre thread. Maintenant où sont les sources de telles affirmations ? Ensuite si vous les avez on continue la conversation, sinon on marque le thread comme un "troll" ;-)\nPosté par lezardbreton le 08/09/06 à 17:57 . Évalué à 1.\nEn fait, ça va être difficile de te retrouver des liens. La première fois que Tango a fait parler de lui, c'est lorsque le travail était pratiquement fini. Te retrouver un mail sur la liste KDE alors qu'il n'y en a pas eu, ça sera compliqué. L'annonce de Tango sur une ML de KDE s'est faite ainsi : http://www.mail-archive.com/appeal@kde.org/msg00091.html\nJe te conseille de lire la réponse de Aaron Seigo : http://www.mail-archive.com/appeal@kde.org/msg00095.html\nto be perfectly honest, given what you've just said, i am very suprised that this is the first time KDE has been contacted about it.\nPosté par clearstream le 08/09/06 à 21:35 . Évalué à 4.\nC'est-à-dire à l'époque de la création de la mailing sur freedesktop (le 26 octobre 2005) :\nPremière contribution KDE quelques jours après (le 31 octoble) :\nCa c'est bon esprit ! Que la force soit avec KDE.\nIl y a du "KDE touch" dans Tango et c'est tant mieux.\nC'est bien mieux que toutes ces "pleunicheries" : "Tango ne nous a pas prévenu, Tango bosse dans son coin, Tango put le Gnome, etc".\nLa mailing de xdg est sur freedesktop depuis mai 2003 :\n# bientot la fin de esound ?\nPosté par zerbro le 07/09/06 à 12:02 . Évalué à 7.\nqu'il est *peut etre* question de commencer à laisser tomber esd pour un nouveau serveur son : pulseaudio, lors du prochain gnome (2.18).\nJe n'en avais jamais entendu parlé encore, mais pour ceux qui veulent en savoir d'avantage :\nD'apres ce que j'ai lu, pulseaudio n'a aucune dépendence vis a vis des bibliothèques gnome ou gtk.\nCa ne peut que améliorer les choses par rapport a esd...\nEt si certains ici en savent un peu plus sur pulseaudio, qu'ils partagent leur avi.\nPosté par Yusei le 07/09/06 à 12:19 . Évalué à 10.\nUne vidéo pour un serveur son, est-ce bien raisonnable ? Ils pourraient partager leur ogg, non ?\n(oui oui, j'y vais de ce pas)\nPosté par dawar (page perso) le 07/09/06 à 13:17 . Évalué à 3.\nHa, c'est le fameux Polypaudio qui devait déjà remplacer Esound il y'a longtemps (Gnome 2.12 ou 2.14 ?). Si ça n'a pas changé, c'est compatible Esound. Mais quite à utiliser un serveur son, je préfère prendre jackd qui semble plus avancé, ou sinon DMIX.\nPosté par Mathieu Pillard (page perso) le 07/09/06 à 14:25 . Évalué à 3.\nPulseaudio a plusieurs avantages sur jackd ou dmix. D'ailleurs, il peut utiliser les 2 :-)\nC'est compatible esound effectivement, mais s'arreter la c'est bien dommage: Ca autodetecte tout bien, rien à configurer coté pulseaudio pour que ca marche (il faut juste changer les applis pour qu'elles utilisent soit esd soit directement pulseaudio, soit utiliser un wrapper oss/alsa fourni par pulseaudio). Ca utilise avahi pour detecter les démons pulseaudio présents sur ton réseau que tu as le droit d'utiliser, et tu peux te servir de ceux ci comme sortie. Chaque programme peut avoir une ou plusieurs sorties son, et ca peut etre changé dynamiquement. Enfin, il ya plein d'outils avec une jolie GUI et des trucs en ligne de commande pour controler tout ca: http://0pointer.de/public/pulse-screenshot.png pour le screenshot :-)\nPosté par dawar (page perso) le 07/09/06 à 15:53 . Évalué à 7.\nC'est interessant, mais pour "mr tout le monde", quel avantage par rapport à dmix directement intégré dans alsa, ou il n'a pas à ce soucier de choisir la bonne sortie entre esound, Pulseaudio, arts ? Bon, oui, Alsa est limité à GNU/Linux, mais sinon ?\nEn plus ce genre de deamon introduit souvent une latence assez désagréable, enfin, esound etait peux être pas optimisé mais ce genre d'astuce logiciel pour réussir a faire sortir deux sons en même temps, je trouve cela (peux être a tord) assez préhistorique...\nPosté par Mathieu Pillard (page perso) le 07/09/06 à 20:19 . Évalué à 2.\nDmix ne fonctionne pas tout le temps, pour commencer. Ca demande des bidouilles différentes selon le matos, et meme si la situation s'est beaucoup améliorée, il reste des machines sur lesquelles ca ne fonctionnera pas par défaut.\nPour ESD... Il était assez crade et peu maintenu: la c'est l'inverse :-) Les développeurs de pulseaudio attachent beaucoup d'importance aux temps de latence, ils sont s'ailleurs mesurés et indiqués dans les différents outils, ce qui te permet de rapporter des bugs :-)\nPosté par boris le 08/09/06 à 01:30 . Évalué à 2.\nPosté par Étienne BERSAC (page perso) le 07/09/06 à 15:39 . Évalué à 4.\npulseaudio est le X11 du son. Il permet un peu plus que simplement partager le son. (Comme X11 fait un peu plus que partager l'affichage).\nPulseaudio est écrit par le fabuleux Lennart Poettering. Il n'est pas à son premier coup d'essai.\nNiveau fonctionnalité, je ne peux pas m'étaler, mieux vaut lire la bluffant FAQ de PulseAudio (ex PolypAudio) : http://pulseaudio.org/wiki/FAQ .\nA mes yeux, la fonctionnalité la plus interressante, c'est de partager le son comme on partage les display avec X. Ça permet de ne pas dépendre d'un daemon comme mpd, mais de nativement gérer le partage. Il semble que ça soit très utile pour le terminaux aussi.\nPosté par Mildred (page perso) le 07/09/06 à 22:06 . Évalué à 2.\nl'avantage de mpc/mpd (du moins celui que j'y trouve) c'est que lorsque la GUI crashe (ou tout simplement mon serveur X, j'ai toujours de la musique, une gestion playlist et tout ...\nJe n'ai pas l'impression (je peux me tromper) que le but est de déporter un flux audio, car c'est le serveur qui fait les accès aux fichiers de musique, pas le client.\nSi tu veux déporter ton son, tu dois t'arranger pour déporter aussi ton dossier de musiques, par un partage NFS par exemple.\n# MONO, pourquoi tant de haine ???\nPosté par Fabrice Mousset (page perso) le 07/09/06 à 12:06 . Évalué à 1.\nJe ne suis pas un grand guru du développement et j'ai toujours beaucoup de mal à comprendre les guerre de clochers.\nChaque fois que je vois un post concernant Mono, c'est des commentaires incendiaires.. Bref j'ai l'impression que l'on accuse Mono de tous les mots de la terre.\nPersonnellement, j'ai déjà fait beaucoup de développement en utilisant le Framework .NET de Microsoft et je suis très content de trouver des solutions alternatives et libre pour le développement en DotNet.\nC'est pas parce que le grand méchant Microsoft a participé aux spécifications d'un langage que ce langue est le mal absolu. Parce que, pour rappel, DotNet est une spécification ECMA et pas un jouet purement Microsoft.\nChaque langage a son domaine de prédilection, moi, ce que je regrète sous Linux, c'est qu'il y a très peu d'environnements de développement qui permettent de faire des choses simplement et rapidement.\nTout le monde n'a pas envie de se plonger dans les arcannes du système. Avoir un langage pourvu de libraire "Très haut niveau" permet de se développer des petits outils de façon agréable.\nMoi, je trouve que Mono est une bonne chose et que MonoDevelop, par exemple, permet faire pas mal de choses, simplement, rapidement et graphiquement. Tout le monde n'a pas envie de développer un nièmme, au choix:\n- système de fichiers,\n- serveur Web / FTP / Mail\nEnfin, comme dirait nos chers politiciens, c'est mon avis et je le partage ;-)\n[^] # Re: MONO, pourquoi tant de haine ???\nPosté par boubou (page perso) le 07/09/06 à 12:13 . Évalué à 6.\nDotNet est une spécification ECMA et pas un jouet purement Microsoft.\nNon, .NET comprend 350 casses spécifiées par l'ECMA et 3000 non spécifiées, propriétés de Microsoft.\nCeci étant je suis d'accord avec toi sur l'aspect technique. Pour moi, .NET est le Java dont j'ai toujours rêvé et Mono une implémentation très intéressante.\nPosté par TImaniac (page perso) le 07/09/06 à 18:12 . Évalué à 1.\nLe plus important dans l'histoire, c'est que ce soit les 350 classes de base essentielles. T'y ajoutes comme précisé plus bas les bindings Gnome & Co, et t'as une plateforme basé sur des technos libres et/ou normalisées.\nEt puis bon en réfléchissant, ca aurait été débile de chercher à normaliser des bibliothèques spécifiques aux environnements Windows, aussi débile que si on cherchait à normaliser GTK#.\nLa normalisation du CLR/CLI et des classes de base est là pour fournir un socle d'interopérabilité, c'est ce qu'a voulu Microsoft et ce qu'a fait Mono.\nPosté par boubou (page perso) le 07/09/06 à 19:13 . Évalué à 3.\nToujours à faire ta propagande, n'est-ce pas ?\nEn quoi ADO.NET et ASP.NET (par exemple) sont spécifiques à Windows ? Cette partie n'est pas normalisée et est pas mal couverte par les brevets Microsoft... Et je ne parle pas de toute l'aspect web services.\nT'y ajoutes comme précisé plus bas les bindings Gnome & Co, et t'as une plateforme basé sur des technos libres et/ou normalisées.\nHum. Je sais bien qu'il existe des alternatives à ADO.NET, mais c'est quand même l'outil classique pour interface une BD à un programme .NET. Or, on en a besoin sur le desktop. Quant à faire une appli serveur (orientée web services par exemple), sans se servir des api microsoft non standardisées, c'est effectivement possible, mais bon...\nPosté par Mildred (page perso) le 07/09/06 à 22:11 . Évalué à 2.\nASP.NET, je ne vois pas trop l'interêt ... du moins de ce que je peux en juger extérieurement.\nles pages générées sont affreuses et il arrive bien souvent que je ne puisse pas utiliser les onglets, ou alors que des choses simples comme le logguer dans un onglet et rafraichir l'autre pour être loggué dans l'autre ne marche pas\nEnfin, peut être que lorsque IE7 aura des tabs, ça changera ...\nPosté par TImaniac (page perso) le 08/09/06 à 00:38 . Évalué à 2.\nPourquoi systématiquement cette remarque à 2 balles ? Tu préfères par dénigrer systématiquement ton interlocuteur quand t'es pas d'accord avec lui ?\nEn quoi ADO.NET et ASP.NET (par exemple) sont spécifiques à Windows ?\nEuh, c'est ca que t'appel une lib "de base" ? Là on parle de Mono & Gnome, bref on peut très bien se passer de ADO.NET et ASP.NET et faire des applis desktop pour Gnome complète basé sur les standards de l'ECMA et les bindings de Gnome.\nPour ce qui est d'ADO.NET cela peut être parfois utile, mais globalement les drivers utilisés sous Linux sont des drivers spécifiques aux BDD utilisées (MySQL par exemple). Leur licence dépend généralement du fournisseur de base de données.\nEt je ne parle pas de toute l'aspect web services.\nOué c'est vrai que les web services c'est pas standardisé :) Z'allait pas non plus mettre à l'ECMA ce qui est déjà normalisé au W3c. Et pour ce qui est de l'implémentation de MS, ben les brevets concernant les web services c'est Novell qui les détient.\nPosté par boubou (page perso) le 08/09/06 à 09:31 . Évalué à 2.\nPourquoi systématiquement cette remarque à 2 balles ?\nParce qu'à chaque fois que quelqu'un poste une remarque "négative" (je mets des guillemets car ta perception de négative est très large), tu réponds en essayant de minimiser cette remarque, soit en parlant de choses qui n'ont aucun rapport, soit en pointant les mêmes défauts (ou des défauts apparentés) dans autre chose. Exemple : "Microsoft a des brevets qui couvrent .NET". Ta réponse "Oui mais il y a aussi des brevets sur X ou Y". C'est une méthode typique de la propagande. Qu'est-ce que change le fait que X ou Y soit breveté à la situation de Mono ? Rien du tout. Par contre, ça induit le doute dans l'esprit des lecteurs.\nTu préfères par dénigrer systématiquement ton interlocuteur quand t'es pas d'accord avec lui ?\nTu remarqueras que je te réserve cette remarque car depuis qu'on trolle sur .NET ta méthode n'a toujours pas changé.\nEuh, c'est ca que t'appel une lib "de base" ?\nNon, par contre dans le poste auquel je répondais tu sous-entendais qu'une des motivations de la non standardisation de bibliothèques était leur caractère spécifique Windows. Je te donne donc des exemples de bibliothèques très importantes qui ne sont pas standardisées et qui sont spécifiques windows.\nLà on parle de Mono & Gnome, bref on peut très bien se passer de ADO.NET et ASP.NET et faire des applis desktop pour Gnome complète basé sur les standards de l'ECMA et les bindings de Gnome.\nBa non, affirmation typique Timaniac (propagande ?). Par exemple tu prends F-Spot et tu vois qu'il utilise par exemple System.Web qui n'est pas standardisé. En outre il stocke pour l'instant tag et compagnie dans une base sqlite. Comme ce genre de base ne scale pas des masses, je suppose qu'une interface avec des SGBD plus solides est prévue et utilisera ADO.NET, non standard (j'aouve que c'est ici de la spéculation).\nPlus globalement, l'accès à des services web ou à des BD est de plus en plus important pour des applications desktop et se fait en .NET par des api non standardisées, d'ou un problème possible.\nEt alors, le rapport ? ADO.NET n'est pas standardisé et est couvert par les brevets que j'ai mentionné (et sûrement par le brevet de FireStar, mais c'est un autre problème). Microsoft n'est pas du tout obligé de donner une licence RAND pour les brevets en question (car ce n'est pas standardisé) et pourrait donc bloquer toute implémentation de l'api d'ADO.NET. Je ne vois pas le rapport avec la licence du back end...\nOué c'est vrai que les web services c'est pas standardisé :) Z'allait pas non plus mettre à l'ECMA ce qui est déjà normalisé au W3c.\nEncore aucun rapport. Ce qui est standardisé, c'est le dialecte XML (DTD et schéma), la sémantique à accorder aux différents éléments, etc. Rien n'empêche une entreprise de breveter une API de création d'un serveur ou d'appel à un service, et c'est d'ailleurs ce qu'a fait Microsoft pour celle de .NET (deux brevets, sauf erreur de ma part). Tu comprends la différence ?\nEt pour ce qui est de l'implémentation de MS, ben les brevets concernant les web services c'est Novell qui les détient.\nEt voilà, toujours aussi imprécis (et faux). Novell a fait don à l'OIN de trois brevets portant sur le commerce électronique et sur certaines formes de web services (dans le domaine du commerce). Ces brevets ne couvrent pas tout le concept de web services. En outre, c'est orthogonal à un brevet sur une api, et en plus, ça ne concerne qu'une infime partie de l'api de .NET qui n'est pas standardisée.\nPosté par TImaniac (page perso) le 08/09/06 à 22:02 . Évalué à 3.\nQu'est-ce que change le fait que X ou Y soit breveté à la situation de Mono ? Rien du tout.\nCa change tout au contraire ! (Sinon je le dirais pas :) )\nPour moi c'est comme si on disait "ne fumez pas des malboro, c'est dangereux pour la santé". C'est pas faux, mais ca induit véritablement l'interlocuteur en erreur, il pourrait être tenté de croire qu'il y a d'autre marque peut être moins dangereuse. La phrase objective voulant faire passer un message pertinent serait de dire "ne fumez pas des cigarettes, c'est dangereux pour la santé". Ben pour Mono c'est pareil, sous entendre qu'il faut mieux utiliser autre chose (sans préciser quoi), c'est une forme de mensonge par omission. Faudrait dire "N'utilisez aucun logiciel c'est dangereux juridiquement" pour être honnête, ou alors dire "Utilisez Mono ou un autre, c'est pareil".\nC'est une méthode typique de la propagande.\nJe suis un simple geek sans aucun intérêt dans Mono, j'admire cette techno et je cherche simplement à ce qu'on arrête de la dénigrer systématiquement pour des raisons juridiques. Alors merci d'arrêter les termes de "propagande" qui sous-entend que je cherche à pervertir le cerveau des gens en les convertissant à une idée. Si je suis Wikipedia, je dois faire un truc comme ca :\n"Dans le langage commun, la propagande équivaut à la désinformation mise au service d'une cause politique d'intérêts privés."\nJe ne désinforme pas, pas comme ceux qui sous-etende d'utiliser autre chose en "oubliant" de dire que c'est aussi dangereux.\nMerci de t'apercevoir que je suis cohérent et que j'ai pas changé mes idées, comme quoi j'y crois.\ne ?). Par exemple tu prends F-Spot et tu vois qu'il utilise par exemple System.Web qui n'est pas standardisé.\nEuh... oué et ? Quel intérêt de standardisé System.Web ?\n. Comme ce genre de base ne scale pas des masses, je suppose qu'une interface avec des SGBD plus solides est prévue et utilisera ADO.NET, non standard\nOué, et là encore, quel intérêt de standardisé ADO.NET ? C'est d'autant pas standard que ce n'est même pas censé être une interface commune à toutes les base de données, chaque driver à ses API spécifiques dédiée à une BDD.\nComprend pas ta conclusion. On doit pas avoir la même idée de l'intérêt de normaliser quelque chose en informatique. Normaliser sert avant tout à faciliter l'interopérabilité. L'intéropérabilité au niveau des web services, c'est l'interface que tu décris (le schema w3c et ce qui va avec), comment c'est implémenté derrière justement on s'en cogne. En l'occurence pour .NET tout est dans la sérialisation XML automatique et le mécanisme d'attribut, qui sont tous les 2 normalisés, garantissant qu'une implémentation de la serialization XML soit compatible avec une autre, ce qui est tout à fait pertinent.\net pourrait donc bloquer toute implémentation de l'api d'ADO.NET. Je ne vois pas le rapport avec la licence du back end...\nPas grave, Mono fera un autre API, c'est pas vital à l'interopérabilité entre applications. Ca pose seulement un problème de compatibilité entre Mono et .NET,\nEncore aucun rapport. Ce qui est standardisé, c'est le dialecte XML (DTD et schéma), la sémantique à accorder aux différents éléments, etc.\nMerci de rappeler où est l'interopérabilité dans les web-services, et où la normalisation a un intérêt.\nRien n'empêche une entreprise de breveter une API de création d'un serveur ou d'appel à un service\nOué et ? Au pire Mono implémente les web-services comme le fond d'autres framework, à moins que les brevets bloque toute implémentation possible des web-services, ce qui ferait que tous les framework et pas spécialement Mono sont en danger.\nEt voilà, toujours aussi imprécis (et faux).\nOué c'est faux si tu veux, t'as raison, ils ont des brevets qui couvre une parti seulement des web services. Et ? Pourquoi tu discutes d'un détail comme ca ? Ca change rien au fond : Novell a des brevets, aussi infîmes soient-ils, ils sont une arme de dissuasion et ca c'est tout leur intérêt et tout ce que je voulais dire (et ce que tu as très bien compris).\net en plus, ça ne concerne qu'une infime partie de l'api de .NET qui n'est pas standardisée.\nInfime mais vitale, t'as vu comment ils utilisent les web services à fond dans Vista ?\nPosté par boubou (page perso) le 10/09/06 à 14:40 . Évalué à 2.\nPour moi c'est comme si on disait "ne fumez pas des malboro, c'est dangereux pour la santé". C'est pas faux, mais ca induit véritablement l'interlocuteur en erreur, il pourrait être tenté de croire qu'il y a d'autre marque peut être moins dangereuse. La phrase objective voulant faire passer un message pertinent serait de dire "ne fumez pas des cigarettes, c'est dangereux pour la santé".\nJ'ai bien compris, tu essayes de t'abriter derrière un danger pour refuser l'évaluation du niveau de risque. Les cigarettes sont dangereuses pour la santé, mais pas toutes de la même façon. Par exemple, on admet généralement que la quantité de goudron est un indicateur important des risques de cancer et cette quantité dépend de la marque et du type.\nToute ta stratégie autour de Mono est de minimiser le risque, soit en le niant (ça c'était au départ, quand on ne savait pas avec certitude s'il existait des brevets portant sur .NET), soit en prétendant de façon erronée qu'il est identique à ceux induits par d'autres logiciels, ce qui est faux en général.\nBen pour Mono c'est pareil, sous entendre qu'il faut mieux utiliser autre chose (sans préciser quoi), c'est une forme de mensonge par omission. Faudrait dire "N'utilisez aucun logiciel c'est dangereux juridiquement" pour être honnête, ou alors dire "Utilisez Mono ou un autre, c'est pareil".\nVoilà un bon exemple de ce que je dis au dessus. Tu aurais raison de dire "la probabilité qu'un logiciel quelconque enfreigne un brevet est élevée", il y a un consensus là dessus. Il y a donc un risque inhérent à l'utilisation de tous logiciels (ou presque). Mais refuser de tenir compte de la hiérarchie des risques, c'est tout simplement nier la réalité. Dans cette hiérarchie, on a MP3 tout en haut (open source illégal dans les pays qui reconnaissent les brevets logiciels), Mono entre les deux (brevets spécifiques possédés par un acteur par super sympa avec le libre) et Java assez bas (techno qui va être libérée par son créateur qui possède un paquet de brevets pour la protéger). Que tu le veuilles ou non, il y a une différence de risque entre .NET et Java, en faveur du second.\nJe suis un simple geek sans aucun intérêt dans Mono, j'admire cette techno et je cherche simplement à ce qu'on arrête de la dénigrer systématiquement pour des raisons juridiques.\nNous avons déjà eu cette "conversation". Je ne cherche pas à dénigrer Mono, que j'admire techniquement sûrement autant que toi, je cherche simplement à faire apparaître les faits, alors que tu cherches à les minimiser ou à détourner l'attention d'eux.\nAlors merci d'arrêter les termes de "propagande" qui sous-entend que je cherche à pervertir le cerveau des gens en les convertissant à une idée.\nTu cherches à masquer la réalité et tu désinformes, en particulier en répétant que les risques sont les mêmes et qu'il n'y a pas d'alternative.\nEuh... oué et ? Quel intérêt de standardisé System.Web ? Oué, et là encore, quel intérêt de standardisé ADO.NET ? C'est d'autant pas standard que ce n'est même pas censé être une interface commune à toutes les base de données, chaque driver à ses API spécifiques dédiée à une BDD.\nRevenons à la question d'origine. Beaucoup de gens (dont toi) aiment minimiser les risques induits par Mono en répétant à l'envie que .NET est standardisé (et donc que MS est obligé de donner une licence RAND de ses brevets, ce qui nous fait une belle jambe, mais c'est une autre histoire). Or, à peine 10% de l'API de .NET est effectivement standardisé, ce qui ne fait pas beaucoup. Histoire de minimiser ce fait, tu prétends qu'on peut faire une plateforme libre en ajoutant des api à ce qui est normalisé. En théorie, c'est vrai, mais comme je te le fais remarquer avec divers exemples, ce n'est pas ce qui se passe dans les faits. Dans les faits, les applications développées pour Mono utilisent certaines api microsoft non standardisées et sont donc vulnérables à une éventuelle aggression de MS. Donc pour revenir à ta question, l'intérêt d'avoir ces api sous une forme standardisée serait de limiter les risques induits par les brevets .NET.\nBla, bla. La discussion ne porte pas sur l'intérêt de la standardisation en informatique, mais au fait que celle-ci réduit les risques pour Mono...\nUne fois qu'un délit est commis, on est puni même si on dit qu'on est désolé.\nMerci de rappeler où est l'interopérabilité dans les web-services, et où la normalisation a un intérêt. Oué et ? Au pire Mono implémente les web-services comme le fond d'autres framework, à moins que les brevets bloque toute implémentation possible des web-services, ce qui ferait que tous les framework et pas spécialement Mono sont en danger.\nEncore une fois, je t'invite à lire les brevets de Microsoft. Ce que MS brevete, c'est une façon d'implémenter certains web services. Pour être compatible .NET, Mono doit les implémenter de cette façon et c'est ce qui est fait actuellement. Donc, ça augmente les risques pour un développeur, car une api peut trs bien disparaître à cause d'une plainte de MS. Toute l'analyse des risques liés à Mono est justement faite de ce genre de choses qui montrent que contrairement à ce que tu repettes, les risques avec .NET ne sont pas les mêmes qu'avec d'autres technos comme Java ou Python.\nOué c'est faux si tu veux, t'as raison, ils ont des brevets qui couvre une parti seulement des web services.\nPas du tout, ils ont des brevets sur l'implémentation standard et l'api de web services en .NET, pas sur "les web services".\nEt ? Pourquoi tu discutes d'un détail comme ca ?\nParce que ça montre qu'en utilisant l'api en question, on prend plus de risques qu'en utilisant une autre api.\nCa change rien au fond : Novell a des brevets, aussi infîmes soient-ils, ils sont une arme de dissuasion et ca c'est tout leur intérêt et tout ce que je voulais dire (et ce que tu as très bien compris).\nLes brevets rétablissent une forme d'équilibre, ils ne font pas magiquement disparaître les risques.\nAs-tu fait une analyse détaillée des brevets de l'OIN pour dire que l'utilisation des web services dans Vista est couverte par ces brevets ? Ma lecture des brevets en question est qu'ils portent avant tout sur le e-commerce et je doute que Vista utilise les web services seulement pour le e-commerce. Donc les brevets sont peut être gênant pour une partie de Vista, mais il ne faudrait quand même pas rêver.\nPosté par TImaniac (page perso) le 10/09/06 à 17:20 . Évalué à 2.\nsoit en prétendant de façon erronée qu'il est identique à ceux induits par d'autres logiciels, ce qui est faux en général.\nCa c'est ton avis que je ne partage pas.\nAlors celle là elle est facile ! Il dit pas la même chose que moi, donc il désinforme ! Moi je suis persuadé qu'il n'est pas plus risqué d'utiliser Mono que d'utiliser Python ou une autre plateforme de dev. T'as le droit de pas être d'accord, d'argumenter, mais franchement l'argument de la propagande, c'est vraiment bas.\nDans les faits, les applications développées pour Mono utilisent certaines api microsoft non standardisées\nCertes, mais ces parties sont pour moi loin d'être au coeur de Mono, et loin d'être vital à mon sens.\nDonc pour revenir à ta question, l'intérêt d'avoir ces api sous une forme standardisée serait de limiter les risques induits par les brevets .NET.\nCa peut effectivement être un avantage, mais on standardise pas pour ca, j'espère que tu en conviendras.\nPourquoi blablabla ? Tu t'es senti obligé de rappeler le nombre de classes normalisées par rapport au nombre non normalisé, sans évidemment préciser que les 350 normalisées sont les classes essentielles à l'interopérabilité du socle technique. Moi j'ai juste voulu rappeler pourquoi seulement ces classes sont normalisés et pourquoi les autres ne le sont pas, ce qui change pour moi complètement ce qu'on doit déduire du rapport que tu présentes.\nEnfin bel évitemment, au passage je te décris comment sont implémentés les web-services, je te montre que l'implémentation est instrinséquement lié aux mécanismes du CLR qui lui est normalisé. Mais non c'est du blabla.\nOn est d'accord. Celà dis Novell a explicitement dit qu'ils prennaient à leur charge d'éventuel problème justement liés à leur implémentation. Je suis bien d'accord avec toi que pour un projet qui fork ou autre, cela peut être plus dangereux.\nEncore une fois, je t'invite à lire les brevets de Microsoft. Ce que MS brevete, c'est une façon d'implémenter certains web services.\nFranchement j'en ai lu quelque uns, je sais pas toi mais perso le blabla des brevets peut être interprété de tellement de manière, sans doute n'est-je pas l'habitude de lire ce genre de document.\nPour être compatible .NET, Mono doit les implémenter de cette façon et c'est ce qui est fait actuellement.\nPourquoi "doit" ? Le code utilisateur n'incorpore rien en relation direct avec les web-service ci ce n'est un attribut de classe/méthode. L'implémentation est purement interne à la plateforme.\noute l'analyse des risques liés à Mono est justement faite de ce genre de choses qui montrent que contrairement à ce que tu repettes, les risques avec .NET ne sont pas les mêmes qu'avec d'autres technos comme Java ou Python.\nJ'ai du mal à capter comment tu peux affirmer ce genre de truc. T'as analysé les milliers de brevets pour voir leur impact sur les autres plateformes ? Ce que je constate c'est que Mono implémente une techno issu de MS, que de nombreux détracteur de cette "source" technologique sont allé cherché les brevets déposés par MS à l'occasion pour en faire une analyse des risques. Moi je dis ok c'est très bien, mais en quoi tu peux affirmer que le risque est plus important qu'avec les autres plateformes ? Ah oui y'a pas eu d'analyse avec les autres plateformes, donc le risque est moins important c'est ca ?\nVois pas le rapport, moi je voulais juste montrer que Novell détenait des brevets enmerdant pour MS. Ta précision n'y change strictement rien, même si je te remercie pour les détails.\nDonc les brevets sont peut être gênant pour une partie de Vista, mais il ne faudrait quand même pas rêver.\nCertes, mais je voulais souligner le fait que si le(s) brevet(s) est enfrein par le framework .NET lui même, Novell tient la une bonne contre-attaque.\nMoi ce que je vois, c'est que Mono est soutenu par Novell, c'est pour moi un gage juridique contre d'éventuelle attaque de brevets, gage que d'autres plateformes n'ont pas toujours (ce qui peut être très enmerdant). Que tu soulignes les brevets c'est très bien, mais pour moi lorsqu'ils sont anhihilés par une stratégie derrière, ils deviennent beaucoup moins dangereux que l'inconnu juridique en matière de brevet qu'on a sur d'autres plateformes.\nJ'espère que tu es conscients que je n'essai pas de tromper mon lecteur, que je n'ai seulement pas la même vue du niveau de dangereusité des brevets sur Mono que toi.\nPosté par Anonyme le 10/09/06 à 17:51 . Évalué à 1.\nJe suis sous Gentoo GNU/Linux, je regarde le (meta)package Gnome, il est disponible pour les archis: alpha, amd64, arm , hppa, ia64, mips, ppc, ppc64, sparc et x86.\nMaintenant je regarde le package mono, il n'y a plus que amd64, ppc et x86 (certes le site mono-project ajoute arm, ia64 et sparc) mais du coup quand je regarde les packages beagle et tomboy j'ai la même limitation d'architecture.\nBien entendu, si la politique de GNOME est d'offrir le plus de bindings possibles, ca serait idiot d'interdir après aux développeurs de les utiliser.\nJe pense juste que c'est un peu tôt pour inclure officiellement un projet en C# dans GNOME (oui j'ai du ARM et du SPARC à la maison ^^)\nPosté par Anonyme le 10/09/06 à 18:27 . Évalué à 1.\ntiens, quelqu'un qui s'amuse à porter Tomboy pour gtkmm:\nsurtout que, comme il ait fait référence dans les commentaires, le projet Google SOC http://live.gnome.org/Tomboy/NetworkedTomboy pourrait faire de Tomboy un preneur de note universel avec plusieurs frontend (GTK, KDE, ETK, etc...)\nPosté par Croconux le 07/09/06 à 22:21 . Évalué à 2.\nLe plus important dans l'histoire, c'est que ce soit les 350 classes de base essentielles.\nC'est sur que Microsoft aurait eu un peu de mal à breveter "Console.WriteLine("Hello World")". Ces classes de base contiennent le strict minimum que tout language propose (entrées/sorties, collections, types de base,...).\nPosté par boubou (page perso) le 08/09/06 à 09:34 . Évalué à 2.\nDétrompe toi. De même qu'une collection d'articles est protégée en tant qu'oeuvre composite, un brevet peut très bien protéger la combinaison de trivialités ou une amélioration par rapport à l'existant. Cela rend les accords de licence complexes. Par exemple si tu brevetes A+B où A et B sont deux choses brevetées, ça ne te donne pas le droit d'utiliser A+B, tu dois avoir une licence pour A et pour B. Par contre, quelqu'un qui veut utiliser A+B doit obtenir une licence de toi. Dans le cas d'une api, on peut donc breveter (et c'est fait par microsoft) une combinaison de classes, même si chaque classe semble totalement triviale.\nIl est clair que ce système de brevets logiciels est délirant, mais c'est comme ça qu'il fonctionne.\nPosté par Étienne BERSAC (page perso) le 07/09/06 à 15:48 . Évalué à 2.\nÀmha, Mono et DotGNU ont l'avantage de créer une faille dans le monopole de MS sur .Net. ( voir à ce sujet http://dotgnu.org/danger.html ). De plus, le C# est un langage plutôt élégant.\nEnfin, il n'y a pas que .Net dans la vie. Gnome *est* une plateforme de développement très complète. hal, dbus, gtk+, et j'en passe en font un plateforme très complète. D'ailleur, Mono est principalement utilisé pour ses binding Gtk#, Gnome#, Glade#, DBus# et consorts. Résultat, c'est la plateforme Gnome qu'on utilise et non la plateforme .Net (ou Win32/WinFX).\nC'est la philosophie à la base de Gnome : Code avec le language que tu veux, mais code avec les même bibliothèque que tout le monde : Gtk+, DBus, Hal, GStreamer, Poppler, Cairo, etc. (Bonobo sera obsolète à partir de 2.18.).\nFinalement, Microsoft à fait juste sa plateforme pour un résultat similaire. L'avantage de Gnome, c'est qu'on peut coder en C pour une exécution rapide ou en python/C# pour un développement rapide.\nÀ noter qu'un atout de Gnome c'est que la majorité de ses composants ne sont pas fondamentalement Gnome (DBus, Poppler et Cairo en sont de bon exemple).\nPosté par Samuel Verschelde (page perso) le 07/09/06 à 12:29 . Évalué à 3.\nCa a l'air pas mal baobab pour l'étude de la place que prennent les fichiers sur le disque, mais il y a encore du chemin à faire pour détrôner filelight dans mon coeur : http://www.methylblue.com/filelight/\nEt tant pis si c'est une application KDE, je n'ai pas peur de l'utiliser sous gnome aussi.\n[^] # Re: Baobab\nPosté par Nicolas Ternisien (page perso) le 07/09/06 à 12:56 . Évalué à 2.\nClairement, Filelight est encore au dessus, sa représentation en forme de disque et son interactivité en fond un outil indispensable pour les utilisateurs très Ctrl+C Ctrl+V avec les copains\nPosté par Samuel Verschelde (page perso) le 07/09/06 à 13:04 . Évalué à 5.\nC'est quoi un utilisateur très Ctrl+C Ctrl+V avec les copains ?\nPosté par liberforce (page perso) le 07/09/06 à 13:26 . Évalué à 2.\nJe suppose que c'est le gens qui récupèrent tout et n'importe quoi et après s'étonne qu'ils n'ont plus de place sur leur disque. Les guillemets n'auraient pas été de trop pourtant.\nPosté par Nicolas Bourdais le 07/09/06 à 15:32 . Évalué à 3.\nPour la représentation en forme de disque, baobab devrait l'avoir un moment ou un autre, une équipe travaille sur ce widget:\nPosté par Zorro (page perso) le 07/09/06 à 14:54 . Évalué à 3.\nLes Gnomistes ont gdmap, très sympa aussi. Juste que c'est pas des secteurs d'un cercle, mais des carrés qui se subdivisent.\n# Nommage des applications\nPosté par Dring le 07/09/06 à 13:51 . Évalué à 10.\n[troll type="competition" pelage="velu grave"]\nJe suis toujours à me plaindre dans KDE du nommage avec un "K" de toutes les applications. Konqueror, Kontact, KMail, amaroK, Koffice, j'en passe et des plus mauvais.\nJe me demande finalement ce qui est le pire. "Orca" pour la gestion de l'accessibilité ? "Tomboy" pour la prise de note ? Et pourquoi pas "Cuisine" pour le lecteur mp3, "Concombre" pour le visualiseur de photo, et "Ornythorinque" pour le tableur ?\nPeut-être que je passe à côté d'une métaphore pourtant évidente, mais je pense surtout que pour avoir moins parlant, il aurait fallu faire un concours.\n[^] # Re: Nommage des applications\nPosté par Johann Ollivier-Lapeyre (page perso) le 07/09/06 à 13:58 . Évalué à 7.\nenfin chez KDE, on est plus orienté matiere et molécule actuellement: Plasma, Oxygen, Glucose, Kaffeine, ...\nPosté par TImaniac (page perso) le 07/09/06 à 13:59 . Évalué à 6.\nBof, tu peux voir ca comme des noms de code qui font tripper les développeurs, concrêtement en tant qu'utilisateur j'irais dans un le menu Application > Son & Musique > Lecteur de musique ou Application > Bureautique > Prises de notes. Après comment s'appel le soft...\nPosté par mammique le 07/09/06 à 17:49 . Évalué à 1.\nApplication > Images > Pornview\nPosté par Cereal Killer le 07/09/06 à 18:06 . Évalué à 3.\nDepends: libatk1.0-0 (>= 1.9.0), libc6 (>= 2.3.6-6), libcairo2 (>= 1.0.2-2), libfontconfig1 (>= 2.3.0), libglib2.0-0 (>= 2.10.0), libgtk2.0-0 (>= 2.8.0), libpango1.0-0 (>= 1.12.1), libpng12-0 (>= 1.2.8rel), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxfixes3, libxi6, libxine1 (>= 1.0.1), libxinerama1, libxrandr2, libxrender1, zlib1g (>= 1:1.2.1)\nTag: interface::x11, role::sw:application, uitoolkit::gtk, use::browsing, use::viewing, works-with::image:raster, x11::application\nPosté par EmmanuelP le 07/09/06 à 14:09 . Évalué à 2.\nJe me demande finalement ce qui est le pire. "Orca" pour la gestion de l'accessibilité ? "Tomboy" pour la prise de note ?\nPour Orca, je ne sais pas.\nPour Tomboy, je ne suis pas sur, mais ça semble avoir un rapport avec Tintin, Tom dans la version anglaise, reporter et donc preneur de notes...\nMais, bon, aussi, est-ce que c'est vraiment important ?\nC'est le nom du projet, laisse aux développeurs le plaisir de choisir le nom qu'ils veulent.\nDe toutes façons, dans le menu, le nom de l'application est précédé de sa fonction (navigateur web Epiphany, notes Tomboy, lecteur de nouvelles Pan), donc ça ne pose pas de problème.\nOrnythorinque, pour le tableur, c'est plutôt pas mal... Il faut que je propose ça au responsable de gnumeric. :)\nPosté par Christophe Fergeau le 07/09/06 à 14:16 . Évalué à 1.\nPour Tomboy, jusqu'à il y a très récemment, l'icône était une tête de Tintin, donc ça confirme tes soupçons ;)\nPosté par mobutu le 07/09/06 à 14:28 . Évalué à 4.\nCe n'est pas la première fois dans le libre, que j'obsèrve des noms qui peuvent avoir une connotation douteuse. Un Tomboy, c'est un garçon manqué.\nEt gimp, c'est une tenue de sadomasochiste.\nCe qui, quelque part, correspond au profil de ses utilisateurs. (j'en fais malheureusement partie.)\nPosté par liberforce (page perso) le 07/09/06 à 14:30 . Évalué à 2.\nEt encore, tu es passé à côté d'Istambul et Byzanz pour la réalisation de démonstrations vidéo...\nPosté par tontonflingueur le 07/09/06 à 15:09 . Évalué à 2.\n... et de la libcaca pour l'affichage de graphiques sur une console en mode texte ...\nAu début je me suis dit, dommage comme nom ça passe vraiment pas en français.\nMais en fait le développeur est un francophone qui assume complètement (voir le logo).\nPosté par Cereal Killer le 07/09/06 à 16:46 . Évalué à 5.\nNon seulement il l'assume, mais apparemment, il récidive avec la libculcul :)\n$ apt-cache show libcucul0\nDescription: low-level Unicode character drawing library\nThis package contains the shared library for libcucul, libcaca's\nplatform-independent character drawing engine.\nPosté par iug le 08/09/06 à 09:11 . Évalué à 1.\nEn même tant quand on voit qui est le mainteneur (je poste pas d'URL parce que je vais me faire bannir de linuxfr :).\nPosté par meuble2001 le 07/09/06 à 16:47 . Évalué à 1.\nPar contre, la libsexy et sa frangine la libsexy2 sont tres sympathiques :)\nPosté par Oook le 07/09/06 à 19:34 . Évalué à 6.\nElles connaissent encule ?\n(script d'install d'E17)\nPosté par meuble2001 le 08/09/06 à 14:57 . Évalué à 1.\nNope, mais je leur en parlerai !\nPosté par mammique le 07/09/06 à 17:46 . Évalué à 3.\nEt pourquoi pas "Cuisine" pour le lecteur mp3, "Concombre" pour le visualiseur de photo, et "Ornythorinque" pour le tableur ?\nPosté par dinomasque le 07/09/06 à 18:08 . Évalué à 7.\nAprès tout IKEA le fait bien avec ses meubles depuis des dizaines d'années.\nPosté par Zorro (page perso) le 07/09/06 à 20:47 . Évalué à 3.\nEn fait, le gros, l'énorme problème, avec les logiciels libres, c'est de trouver des noms qui soient pas déposés ou réservés, justement. Les grosses boîtes peuvent se payer des recherches en antériorité ou des trucs comme ça... Pas les petites ou les développeurs indépendants.\n# Evolution 2.8 sur Mandriva 2006\nPosté par Zorro (page perso) le 07/09/06 à 14:50 . Évalué à 5.\nJ'installe toujours les toutes dernières versions stable d'Evolution, que j'utilise intensivement pour mon boulot.\nIl paraît qu'il y a des nouveautés dans cette nouvelle version 2.8 - ha oui, c'est vrai, des nouvelles couleurs dans le Calendrier, et une barre de recherche dans les messages encore plus lourde à manipuler qu'avant.\nBref. Pour tout ceux-là qui voudraient l'installer sur une Mandriva 2006, il leur faudra probablement faire comme moi : recompiler le bousin. C'est pas trop dur, il faut juste bien faire dans l'ordre. Et je crois aussi utile de montrer comment passer outre une erreur lors de l'étape de compilation make :\nÀ un moment, il y a une erreur qui dit "GNOME_PARAM_GOPTION_CONTEXT undeclared", et qui stoppe la compilation. C'est parce que les bibliothèques Gnome 2.10.1 de la Mandriva 2006 sont trop vieilles. J'ai eu beaucoup de mal à trouver l'astuce sur le web, donc voilà comment faire, pour pas avoir à réinstaller tout Gnome. Il faut éditer le fichier /usr/include/libgnome-2.0/libgnome/gnome-program.h et rajouter une ligne #define GNOME_PARAM_GOPTION_CONTEXT "goption_context" , juste après le gros paquet des #define, à la ligne 130.\nLa réponse était en fait sur le wiki des développeurs indiens de Novell, mais il répond plus.\nPosté par boris le 08/09/06 à 01:41 . Évalué à 4.\n[^] # Re: Apropos\nPosté par Jean-Christophe Berthon (page perso) le 08/09/06 à 15:25 . Évalué à 2.\nPeut-être cette page t'apportera un élément de réponse :-)