Un thème d'icône Tango et compatible avec les spécifications Freedesktop XDG, pour une intégration avec les environnements de bureau compatibles (KDE, Xfce...).
De nouveaux venus : gnome-power-management pour la gestion d'énergie, Tomboy pour la prise de notes, Alacarte pour l'édition des menus, Baobab pour l'analyse de l'occupation du disque dur, Orca pour la gestion de l'accessibilité.
De nombreuses améliorations sur Evolution, en termes de performances notamment grâce à Cecilia Gonzalez Alvarez, qui a pris part au Women's Summer Outreach Program, mais aussi au niveau graphisme avec l'ajout au calendrier d'Evolution d'effets basés sur la bibliothèque graphique Cairo.
Et diverses autres améliorations, comme la possibilité de changer graphiquement les permissions de toute une arborescence (enfin !), mais aussi une grande refonte de bug-buddy, l'agent de rapport de bugs qui a été grandement simplifié pour l'utilisateur ! Cela permettra d'avoir des rapports de bugs plus cohérents et devrait en faciliter la correction.
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#, ainsi que l'utilisation des nouvelles fonctionnalités offertes par GTK+ 2.10.
Dans le futur des applications Mono comme F-Spot, Banshee ou Beagle sont susceptibles de faire leur apparition.
Aller plus loin
- Release notes (1 clic)
- Sortie de GTK+ 2.10 (3 clics)
- First look at GNOME 2.16 (1 clic)
- GNOME Fr (4 clics)
# un journal
Posté par tuiu pol . Évalué à 8.
# Mono
Posté par patrick_g (site web personnel) . Évalué à 6.
Tomboy 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 ?
Le résultat c'est une dépendance à Mono. C'est très lourdingue et en plus juridiquement j'ai pas confiance.
Et 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 !
C'é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.
Inutile 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.
Patrick_g, un probable futur ex-gnomiste.
[^] # Re: Mono
Posté par zerbro . Évalué à 8.
J'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.
Ensuite, comparer F-spot a gthumb, c'est osé. Ce n'est *pas du tout* le meme type d'application. Et gthumb continue d'exister.
Bref, le seul truc qui change, c'est que tomboy et mono font officiellement parti de gnome.
Et alors ?
Enfin si tu veux passer à KDE, libre a toi.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 0.
C'est _exactement_ le même type d'application.
Bien sur il y a certaines fonctions présentes chez l'un et pas chez l'autre et inversement mais rien de fondamental.
Sinon 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
KDE 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é.
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 10.
Dire sans cesse qu'il y a des incertitudes avec Mono, on peut voir ca comme ca d'après Wikipedia :
"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 :
Installer le doute,
en s'appuyant sur la peur
au moyen d'informations non vérifiables (incertitude)."
Bon 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.
Par 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.
Moinssez 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 :)
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 10.
Ce 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/
Je 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.
Je 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.
[^] # Re: Mono
Posté par nolius . Évalué à 3.
dans une distribution linux, il doit y avoir des milliers de brevets violés, non?
c'est ce qui arrive quand on accepte des brevets comme le double click
http://solutions.journaldunet.com/0406/040607_brevets.shtml
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Mono
Posté par zerbro . Évalué à 4.
Le 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).
Tout ceci sans tenir compte des brevets.
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 2.
Désolé pour ce jugement de valeur sans grand fondement...
[^] # Re: Mono
Posté par Gmooron . Évalué à 4.
Et 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, ...)
[^] # Re: Mono
Posté par yeKcim (site web personnel) . Évalué à 4.
[^] # Re: Mono
Posté par Antoine . Évalué à 3.
Raté. Par exemple, dans ce test effectué en VBR aux alentours de 130kbps, Lame fait quasi jeu égal avec Vorbis et AAC.
http://www.hydrogenaudio.org/forums/index.php?s=&showtop(...)
« 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. »
Et, 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.
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Je 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 !)
Je peux donc te donner moi aussi une information vérifiable : Microsoft possède au moins trois brevets sur l'API de .NET
Et ? 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.
On sait aussi que Sun va mettre son JDK sous une licence open source, ce qui clôt le débat.
Oué 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)
Je termine par un peu de pub (honte à moi) : j'ai écris un nouveau pavé sur la situation juridique de Mono (et de Java)
Je 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.
Enfin 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.
Enfin au final j'ai du mal à capter ce que tu me reproches vu que je ne trouves aucune contradiction avec ce que tu dis.
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 2.
Non, 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.
l'OIN a toutes les cartes pour défendre Mono, notamment des brevets clés sur les web-services.
On 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...
Oué ca fait 10 ans qu'ont a des rumeurs comme ca.
Hum, 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à.
Bref Mono n'est pas un cas particulier et est autant en danger/sécurité que la plupart des technos/softs libres.
Les 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.
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 5.
Vi 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).
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.
Oué 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...
Comme roi du FUD, tu te poses bien là.
Ben 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.
(Quand à l'annonce du 14 août, désolé, j'étais en vacances, j'en étais encore aux rumeurs insistantes et déclarations officieuses).
Les 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.
Si 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.
Enfin 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).
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 0.
Est-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.
Oué 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 !
Sauf 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).
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...
Tu 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.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 8.
>> 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
Si j'envisage éventuellement de changer de plateforme c'est que je pense vraiment que Gnome a rompu un contrat moral.
C'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).
C'est ça un desktop, ni plus ni moins.
Ouvrir 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.
Les 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.
C'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.
Au 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.
Moi ç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.
[^] # Re: Mono
Posté par j (site web personnel) . Évalué à 7.
Ce 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)
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 5.
Y'a longtemps que Gnome a rompu ton contrat moral en utilisant Python...
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.
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.
Ils doivent CHOISIR et s'y tenir.
Oué 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.
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.
Bah 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.
J'aime Gnome, j'aime son interface simple et son HIG
Ca 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.
Mais visiblement dans Gnome il n'y a pas de direction claire et de choix qui est fait.
Les 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.
[^] # Re: Mono
Posté par mobutu . Évalué à 2.
Y'a longtemps que Gnome a rompu ton contrat moral en utilisant Python..."
Y'a quoi comme truc en python à part la rigolote mais inutile deskbar ?
[^] # Re: Mono
Posté par liberforce (site web personnel) . Évalué à 5.
[^] # Re: Mono
Posté par zebra3 . Évalué à 3.
- gnome-bittorrent,
- SoundConverter et Revelation (qui ne font pas partie officiellement de GNOME, mais qui y auraient leurs places),
- gnome-app-install,
- l'éditeur de menu (avant Alacarte)
- Serpentine (je ne sais pas s'il est officiel)
- ...il y a en a sûrement beaucoup d'autres
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Mono
Posté par zebob . Évalué à 1.
[^] # Re: Mono
Posté par Juke (site web personnel) . Évalué à 2.
[^] # Re: Mono
Posté par Juke (site web personnel) . Évalué à 2.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 2.
Bon on va donc procéder par un exemple par l'absurde.
Tu 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 ?
Une appli en C + Une appli en Ruby + Une appli en Python + Une appli en Mono + Une appli en Java + Une appli en OCAml + Une appli en Haskell...etc etc
C'est absurde !!
Que 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.
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. Là ce qu'elle nous propose c'est l'intégration d'applications dans tous les langages possibles et imaginables ?
Encore 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.
La 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).
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 4.
Cela 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.
Mais est-ce que Gnome doit avoir, par défaut, des applications dans tous ces langages ?
Gnome est modulaire, ces applis ne sont pas indispensable à la plateforme, libre aux distributions de délivrer Gnome avec les packages qu'ils souhaitent.
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.
De 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.
R un et un seul langage de haut niveau afin d'éviter la situation absurde décrite ci-dessus.
Bof, ca c'est toi qui trouve que c'est absurdre, visiblement le board de Gnome a majoritairement estimé que ca ne l'était pas.
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)
Bah 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.
sans qu'il y ait eu un choix clair pour le langage de haut niveau.
Oué 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.
Dans 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.
Mais 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 !
Imposer 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.
Un 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.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 2.
Mais 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).
A quoi bon faire entrer F-Spot dans Gnome ?? (c'est pas fait mais ça pointe à l'horizon).
>> si Gnome était limité au C, ca veut dire que dans 20 ans on serait encore à faire des appli desktop en C ?
Mais 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).
>> Un bon conseil : pense à l'expérience des utilisateurs, c'est tout ce qui importe
Quand j'évoque la conso mémoire je pense à quoi à ton avis ?
[^] # Re: Mono
Posté par zerbro . Évalué à 6.
Parce 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.
Essaie par exemple, de retrouver toutes les photos ou mémé et oncle jo apparaissent ensemble avec gthumb...
J'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.
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.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 3.
Ahem....c'est quoi déjà un tag ?
Ah oui c'est l'assignation d'une catégorie à une photo non ?
Pour 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".
Voila ! 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
C'est bien ça un tag non ?
J'ai une révélation à te faire : GThumb gère les catégories ! (cf photo)
http://www.flickr.com/photo_zoom.gne?id=237005377&size=o
Bon 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 :
Thumbnails are saved in the same database used by Nautilus so you don't waste disk space.
Trouvé sur la liste des fonctions de GThumb : http://gthumb.sourceforge.net/features.html
Est-ce que F-Spot en est au même niveau d'intégration ?
[^] # Re: Mono
Posté par zerbro . Évalué à 3.
Cependant, 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.
Bien 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...
La 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).
Bon, c'est completement hors sujet par rapport au post initial sur mono.
Ensuite, 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.
[^] # Re: Mono
Posté par boris . Évalué à 1.
[1] on a vraiment des mots à ch*er je trouve...
[^] # Re: Mono
Posté par Barnabé . Évalué à 7.
Non ?
(Laconique, non ?)
[^] # Re: Mono
Posté par gpe . Évalué à 1.
Parce thumbnail ce n'est pas un mot à ch*er?
Moi, j'aime bien imagette, ça dit clairement ce que c'est.
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 4.
[^] # Re: Mono
Posté par Spyhawk . Évalué à 0.
Pour utiliser ce qu'un "environnement de bureau" complet devrait être ?
[^] # Re: Mono
Posté par zebob . Évalué à 5.
JBrout ? http://jbrout.python-hosting.com/wiki/WikiStart
[^] # Re: Mono
Posté par Christophe Fergeau . Évalué à 3.
Le 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.
[^] # Re: Mono
Posté par boris . Évalué à 2.
Ah bon, c'est absurde de disposer du choix du langage de programmation pour son projet ? J'ai du mal à te suivre, là. Ils servent à quoi, sinon, les bindings ? A faire joli ?
Il y a plein de gens qui programment avec Perl, et si je pense que perl lui-même est absurde, ben moi je l'utilise pas pour programmer, mais je vais pas empecher les autres de le faire s'ils aiment ça ! D'autant que certains écrivent de très bon programmes en Perl.
Tu veux pas les applis écrites en Java/c#/Perl/Ruby/asmZ80 ? Mais tu es libre de ne pas les installer. Les bibliothèques de la plateforme sont en C, y'a pas de problème. Tu es libre de réécrire F-Spot si ça t'amuse.
Et puis t'as oublié GtkAda. On peut faire plein de trucs chouette avec GtkAda. Tous les programmes de Gnome devraient être écrits avec GtkAda.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 1.
Alors, 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 !
Ce 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).
C'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.
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 5.
J'ai l'impression que t'as à des gros à priori techniques, et tu sembles persuader que cela impact négativement l'expérience utilisateur.
Faut 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).
Voilà, 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.
L'é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 ?
Ca 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.
[^] # Re: Mono
Posté par TeXitoi (site web personnel) . Évalué à 3.
[^] # Re: Mono
Posté par ribwund . Évalué à 3.
D'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".
[^] # Re: Mono
Posté par yeKcim (site web personnel) . Évalué à 1.
[^] # Re: Mono
Posté par j (site web personnel) . Évalué à 0.
D'une (1) application dépendant de Mono - qui ne fait pas partie de GNOME.
[^] # Re: Mono
Posté par imalip . Évalué à 4.
[^] # Re: Mono
Posté par liberforce (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mono
Posté par zerbro . Évalué à 6.
L'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.
Certe, 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.
Sur 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).
D'autant que ce que tu dénonces comme une grosse erreur, d'autres le voient comme une formidable avancée. Donc bon...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 3.
Ca 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.
C'é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.
Ben 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.
[^] # Re: Mono
Posté par boubou (site web personnel) . Évalué à 5.
Sauf 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).
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu 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.
Moi je parlais de la philosophie, qui est pour les développeurs, je cite la fondation Gnome :
"GNOME gives developers the greatest licensing flexibility and the greatest variety of programming languages."
( http://www.gnome.org/about/why.html )
[^] # Re: Mono
Posté par ome . Évalué à 1.
[^] # Re: Mono
Posté par liberforce (site web personnel) . Évalué à 5.
Lis ceci:
http://www.alobbs.com/news/1144
Et surtout sa réponse (la 2ème section du post):
http://primates.ximian.com/~federico/news-2006-07.html#19
Federico 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.
Le 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).
[^] # Re: Mono
Posté par liberforce (site web personnel) . Évalué à 2.
Bon, 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 :-)
http://www.vuntz.net/journal/2006/08/08/393-gnome-et-mono-mo(...)
[^] # Re: Mono
Posté par patrick_g (site web personnel) . Évalué à 8.
Sur 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 ?
Pourquoi s'alourdir avec Mono (en plus des brevets Microsoft) alors que Python remplit ce besoin parfaitement ?
Que 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.
Par 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.
[^] # Re: Mono
Posté par lezardbreton . Évalué à 3.
[^] # Re: Mono
Posté par Mars . Évalué à 1.
1/
Qu'a fait Apple pour son Desktop ? Il utilise il me semble à la base son C+maison.
Langage 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.
En 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 ?
Si 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) ?
2/
Quand à l'adoption de Mono par le projet Gnome, ce semble étonnant du point de vue stratégique et étique :
- Mono depuis le début ne court il pas après .Net sans pouvoir le rattraper ?
- 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 !
A 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 ?
On 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.
Je 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 ?
Finalement 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 ?
PS :
petite 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 ?
[^] # Re: Mono
Posté par dinomasque . Évalué à 2.
Il s'agit Objective-C++ (un mélange de C++ et d'Objective-C).
Pour ce qui est de l'ouverture de Cocoa (l'API native de MacOSX) :
Python http://developer.apple.com/cocoa/pyobjc.html
Ruby http://lists.apple.com/archives/student-dev/2005/Sep/msg0003(...)
PERL : http://cocoadevcentral.com/articles/000076.php
Ocaml http://www.cs.unm.edu/~wneumann/cococaml/
etc.
Il 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 !).
BeOS le faisait il y a 20 ans !
[^] # Re: Mono
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 6.
- Kpart (apres avoir envisagé Corba)
- Dcop
- Arts
- KIO
- khtml (et konqueror)
- Koffice
Bref, 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.
Pour 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:
- Phonon (Wrapper audio permettant d'utiliser le backend audio de son choix)
- Oxygen : nouveau theme d'icones
- Plasma : fusion de kicker et superkaramba
- remplacement de Dcop par dbus
.... Mais aussi de grosses améliorations sur des trucs existant, comme knotify, KIO....
Bref, plein de trucs à faire dans tous les domaines :D
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 1.
Moi je te réponds :
Pourquoi 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.
'ai je ne sais combien de machine virtuelles qui tournent en même temps.
Oué 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).
[^] # Re: Mono
Posté par lezardbreton . Évalué à 4.
Python est depuis longtemps une dépendance de GNOME. C'était déja une des raisons de GoneMe.
Tu sais quel pourcentage de tes barrettes de RAM de Gnome 2.22
Beaucoup trop car c'est de l'utilisation de la mémoire qui aurait pu et du être évitée.
[^] # Re: Mono
Posté par boris . Évalué à 1.
Oé, si tu veux lancer Evolution, c'est clair...
Après, bon, j'ai une barette de 1Go dans ma machine, ce qui tend à devenir le standard, eh bien.. En utilisation de tous les jours (avec des trucs qui tournent en Mono, en python, mes 3 emacs dont un avec Slime, ça fait déja un paquet de machines virtuelles, mes 32 tabs dans firefox, et des gcc qui partent dans tous les sens, ..) eh bien, avec tout ça c'est encore le kernel et ses buffers qui occupent la majorité de la mémoire. Alors cet argument, il devient de plus en plus à 2 balles.
J'ai d'ailleurs pensé à ajouter un autre Go pour qu'il y ait encore plus de buffers pour que find / se termine en moins de 2 secondes. C'est vrai, à cause de Mono ça rame, y'a plus de place pour les buffers.
[^] # Re: Mono
Posté par lezardbreton . Évalué à 3.
[^] # Re: Mono
Posté par Christophe Fergeau . Évalué à 5.
Oué 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 ? »
Non, 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
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 1.
Une 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.
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.
[^] # Re: Mono
Posté par Christophe Fergeau . Évalué à 3.
Et ? 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#.
[^] # Re: Mono
Posté par TImaniac (site web personnel) . Évalué à 3.
Pour 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 :)
[^] # Re: Mono
Posté par Antoine . Évalué à 1.
Le 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.
[^] # Re: Mono
Posté par Moonz . Évalué à 2.
Et encore heureux !
# spam.py
import sys
sys.stdout = open("log_stdout", "w+")
import egg
print "Hello from spam.py"
# egg.py
print "hello from egg.py"
$ python egg.py
hello from egg.py
$ python spam.py
$ cat log_stdout
hello from egg.py
Hello from spam.py
Maintenant, imagine que python se mette à partager le module sys à travers toutes les instances de la VM...
[^] # Re: Mono
Posté par chimrod (site web personnel) . Évalué à 3.
Python 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).
Par contre, les fonctions elles, ne seraient chargées qu'une seule fois, et là serait l'économie
[^] # Re: Mono
Posté par Moonz . Évalué à 1.
Les 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:
>>> def spam():
... print "spam"
...
>>> def egg():
... print "egg"
...
>>> spam()
spam
>>> egg()
egg
>>> spam.func_code = egg.func_code
>>> spam()
egg
>>>
Bon, 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
[^] # Re: Mono
Posté par chimrod (site web personnel) . Évalué à 1.
En 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.
Ensuite, 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.
Pour finir, une mise à jour des varialbes __methods__ __class__ etc permet de rendre toutes ces manippulations invisibles pour le programme...
Je 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 ! :) )
[^] # Re: Mono
Posté par nolius . Évalué à 4.
à moins que tu n'utilise pas linux?
[^] # Re: Mono
Posté par liberforce (site web personnel) . Évalué à 3.
C'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.
Mais 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).
[^] # Re: Mono
Posté par gnumdk (site web personnel) . Évalué à 3.
Non, ca existe déjà depuis longtemps ;)
http://basket.kde.org/development.php
-> [ ]
[^] # Re: Mono
Posté par lezardbreton . Évalué à 3.
Pareil, je sors voir s'il fait beau dehors :)
[^] # Re: Mono
Posté par Mildred (site web personnel) . Évalué à 7.
Pourquoi pas avec la machine virtuelle Parrot (créée pour perl6) : http://www.parrotcode.org/
Pour 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.
Mais ça bouge quand même :)
http://www.parrotcode.org/languages/
# Tango : bof
Posté par Philippe F (site web personnel) . Évalué à 8.
En 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.
Il 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.
Je pense que le projet en soi est interressant mais pas pour plusieurs desktops.
A 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 :
- placement des icones sur le systeme de fichier
- organistion des themes sur le systeme de fichier
- contenu des fichiers .desktop
- utilisation de dbus
- notification dans la barre des taches
- applets dans la barre des taches
A 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.
Tango 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).
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.
[^] # Re: Tango : bof
Posté par cruciforme . Évalué à 2.
[^] # Re: Tango : bof
Posté par lezardbreton . Évalué à 1.
De plus, la licence creative commons ne lui permet pas de rentrer dans Debian (pour rappel : http://people.debian.org/~evan/ccsummary.html ).
[^] # Re: Tango : bof
Posté par Simon TRENY . Évalué à 0.
Aprè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).
[^] # Re: Tango : bof
Posté par Mr_Moustache . Évalué à 4.
Alors 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.
Sinon je trouve que ça va profond vers l'enculage de mouches et le *woin* *woin* ... Personne n'impose rien à l'équipe KDE...
[^] # Re: Tango : bof
Posté par Gof (site web personnel) . Évalué à 4.
Tango est juste un thème d'icône, avec une charte graphique bien définie.
Et leur but est, d'après leur site, de vouloir un thème d'icône commun à tout les DE.
Il 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 [1]
Quand à 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
[1] http://www.freedesktop.org/wiki/Standards_2ficon_2dtheme_2ds(...)
[^] # Re: Tango : bof
Posté par Mr_Moustache . Évalué à 6.
Eventually, the Tango Desktop Project will provide the following initiatives:
* A suggested default native look.
* A subsystem to help standardize toolkits on a common icon naming structure.
* A complete set of application, mimetype, and stock icons designed using a defined style guide.
* A general, cross-desktop human interface guideline.
Mê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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tango : bof
Posté par rewind (Mastodon) . Évalué à 6.
C'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à.
[^] # Re: Tango : bof
Posté par Gof (site web personnel) . Évalué à 7.
DBus a été construit par des développeur de GNOME et de KDE
DBus est en quelque sorte un DCop2
Le fait que les 2 bureaux utilise le même système est un avantage pour tout le monde.
Sinon pour le reste, je suis d'accord.
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . Évalué à 10.
Dbus 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.
Globalement, 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.
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.
[^] # Re: Tango : bof
Posté par Christophe Fergeau . Évalué à 2.
Tu 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.
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 2.
Et comment GNOME a fait ça ?
Avec des pots-de-vin ?
Du chantage ?
Des photos compromettantes ?
GNOME allait attaquer KDE avec des brevets ?
Arrêter de dire des conneries. KDE a pris Dbus car ça leur plaisait. Point barre.
> On pourrait aussi parler de gstreamer
Et KDE n'a pas pris Gstreamer, et il n'y a pas eu de mesure de rétorsion.
Preuve que Gnome n'impose rien à KDE. Preuve que freedesktop n'impose rien à KDE.
Mais si Gnome/Gstreamer/Freedesktop/etc pensent que KDE fait une connerie, ils ont le droit de le dire. Et vice-versa.
Non ?
> c'est une des raisons qui m'ont fait choisir KDE plutôt que GNOME. C'est dommage d'en arriver là.
C'est vraiment dommage. Voire con.
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 2.
Où est le problème ?
> a developpe tango sans aucune concertation avec des autres desktop
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.
Et qu'es-ce que tu entends par "concertation avec les autres desktop" ?
Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars".
Si 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 ?
S'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).
> et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau
Comment tu fais pour affirmer ça ?
Selon 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 ?
> C'est vraiment l'oppose des buts et du principe de freedesktop.
Lis freedesktop :
http://freedesktop.org/wiki/http://freedesktop.org/wiki/StandardsIl n'y a pas tango dans la liste (pas encore peut-être).
C'est TOI qui vient décréter que Tango est un standard et à partir de là tu fais des raisonnements fumeux.
> Il y a un certain nombre de raison pour KDE de ne pas adopter tango.
Très bien.
Ta 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.
Ca me fait bien rigoler les gens qui critiquent l'implication de Gnome dans freedesktop et surtout quand ça vient de KDE.
KDE 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.
> Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande
Si KDE était plus impliqué dans freedesktop, la question ne se poserait même pas !
KDE 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 ?
> Ensuite, Gnome et KDE ont un style d'icone qui est different.
Tango est fait pour unifier les desktops.
Si ce n'est pas possible car la philosophie (vue côté utilisateur) des desktops est trop différente alors tant pis.
Mais l'effort de Tango est très respectable.
> 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.
Ce boulot la DOIT être fait au niveau de freedesktop. Freedesktop est là pour ça !
Alors 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.
> Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.
Ce qui est tout à fait normal. Contrairement à 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.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
> 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).
Je 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).
> 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.
Et freedesktop s'en plaint ?
Ben non.
Mais cairo a toute sa place sur freedesktop car ça peut intéresser tous les desktops (sauf KDE).
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.
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . Évalué à 3.
C'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.
cf par exemple :
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
The purpose
of the Tango project is not only the icon theme. The purpose is to work
towards unifying the visual aspects of all the desktops.
>>
<< Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars". >>
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".
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
Concernant XFCE :
http://lists.freedesktop.org/archives/xdg/2005-November/0074(...)
<<
Nobody said that Xfce will ship the Tango icon theme. Brain just said
that he wants to "join as Xfce representative". We'll discuss that issue
when the time arrives (which don't seem to be anytime soon).
>>
<< KDE ne fout pratiquement pour freedesktop >>
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.
Par exemple si on prend les archives du mois d'aout 2006 :
http://lists.freedesktop.org/archives/xdg/2006-August/author(...)
Tu 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.
Tu 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
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.
<<
Contrairement à 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.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
>>
C'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.
Freedesktop 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.
Tango 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.
<<
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.
>>
Comme DCOP ?
[^] # Re: Tango : bof
Posté par clearstream . Évalué à -3.
Ben Tango ne sera pas un standard.
Il n'empêche que l'effort de tango est à saluer.
Perso, quand je vois une appli KDE, j'ai du mal à comprendre les icones. Probablement car je suis trop habitué à celles de Gnome.
Mais 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.
> 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.
Tant mieux si je me suis trompé.
> 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.
Dbus a des fonctionnalités que n'avais pas DCOP. Certes KDE pouvait faire évoluer son propre système pour avoir les fonctionnalité de Dbus.
Mais il ne faut pas faire croire que KDE s'est "sacrifié" pour avoir Dbus. Ca les interessait, ils l'ont pris. C'est intelligent.
> J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.
Ben je ne comprend toujours pas.
KDE veut "s'imposer" (notes les guillemets) dans le desktop et Gnome aussi. Il n'y a rien d'anormal et rien à reprocher à ça.
Le problème, est quel est ta définition de "s'imposer".
Si c'est vouloir être largement utilisé et s'en donner les moyens (ici "médiatique) alors je suis d'accord avec toi.
Si c'est *forcer* les autres a utiliser Tango, je ne suis pas d'accord avec toi.
D'ailleurs comment Tango peut *forcer* les autres à utiliser Tango ?
> 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.
Ben tant pis.
Belle démonstration que Tango n'impose rien.
> <<
> 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.
> >>
>
> Comme DCOP ?
??!!??
Le fait est que KDE ne propose pas grand chose. Tu me (nous) dis que KDE bosse avec freedesktop et je m'en félicite.
M'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.
D'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.
Il 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.
Gnome pense libgnome, gtk+, pango, glib, cairo, gstreamer, bindings, python, C#, java, etc...
Quelque 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".
Pour 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é.
Ben je comprend que KDE ne pousse pas phonon sur freedesktop car phonon est KDE centrique et ne veut pas être une solution "universelle".
[^] # Re: Tango : bof
Posté par Gof (site web personnel) . Évalué à 4.
Phonon n'est PAS un serveur multimedia
Phonon est juste une API qui respecte les conventions de nommages et les habitudes des développeurs KDE
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 ?)
Mais 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.
J'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)
[^] # Re: Tango : bof
Posté par clearstream . Évalué à -1.
J'ai dit :
- "un serveur multimédia (un wrapper)"
> 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 ?)
Donc le retirer de kdelibs ne doit pas poser de problème ?
Ca serait bien pour les applis Qt tu ne trouves pas ?
> KUrl pour les noms de fichier.
Pour 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).
Voilà 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.
Pourtant 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.
Mais KDE n'a pensé qu'à KDE. Je ne dis pas que KDE est un "méchant". Ca doit être culturel/historique.
Merci d'avoir abondé dans mon sens.
[^] # Re: Tango : bof
Posté par Gof (site web personnel) . Évalué à 2.
« 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++. »
Eh 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.
Alors oui, Phonon est "réservé" à KDE, et c'est normal. Qu'est-ce que Gnome irait faire avec un binding multimédia pour KDE ?
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 0.
Je n'ai pas parlé de Gnome/Phonon mais de Qt/Phonon, gtkmm/Phonon et C++/Phonon.
Et notes que dans ta question il y a la réponse. Ainsi KDE l'a voulu.
[^] # Re: Tango : bof
Posté par Gof (site web personnel) . Évalué à 4.
Bha oui, les dev KDE ne devrais plus faire avancer KDE, ils devraient plutôt aider ceux de Gnome à rattraper leur retard (/ironique)
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 1.
Apprends à lire s'il te plait.
J'ai dit :
- "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."
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . Évalué à 7.
Plus 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.
Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
> M'enfin, Gnome a fait au moins cinq fois plus de propositions.
Je 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.
Une 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.
> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,
C'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.
Gstreamer 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).
La 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.
Phonon 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.
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 2.
Exemple ?
> Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Je 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).
> Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
C'est-à-dire ?
KDE fait des propositions pour que des projets hébergés par freedesktop soient utiles à KDE. C'est normal et très bien venu.
Mais quel projet a été initialisé par KDE pour l'intéropérabilité ?
Spécification pour gestionnaire de fenêtre ? Non.
Dbus ? Non.
HAL ? Non.
Un API multimédia pour tous les desktops ? Non.
Quoi alors ? C'est la seconde fois que je pose la question.
> 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.
Ben 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.
> Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne.
Tu veux dire que le dbus de KDE n'a pas de dépendance avec glib ?
Ben 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).
Tu vas peut-être maintenant dire que KDE a sa propre implémentation de HAL ?
Je te donne tout de suite la réponse : Non.
> maintenant deux implementations de la partie client.
Non. KDE a fait une surcouche.
Si je me trompe (je n'ai pas vérifié), indique où sont les sources de l'implémentation de dbus par KDE.
> C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants.
C'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.
> Gstreamer n'assure pas la compabilite binaire ni source entre version.
Comme tout le monde ?
Il 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.
L'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).
Dis moi si je me trompe, mais KDE 4 ne sera pas compatible avec KDE 3.
> C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire.
Puisque 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.
Et 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).
Pourtant KDE prend dbus mais refuse gstreamer au motif de la non stabilité de l'API.
On n'est pas dans le deux poids deux mesures ?
Et je ne te parle même pas de HAL où la situation est "pire" (notes les guillemets).
> 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
Et 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.
Ces problèmes sont à gérer par les gestionnaires de paquet et ils font ça très bien et ils existent pour ça.
> (note que c'est le comportement a l'heure actuelle).
Absolument 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.*.
[^] # Re: Tango : bof
Posté par Seazor . Évalué à 2.
Par 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.
Pour 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.
Je 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.
Gnome essai d'avoir et de développer des solutions utilisables par plusieurs desktops et KDE non.
Je peux me tromper mais j'ai plutôt l'impression que KDE propose plus sur les specs que sur le code.
P-ê parce qu'ils n'aiment pas se reposer sur du code extérieur qui ne soit pas considéré comme suffisamment mature.
C'est qu'ils y tiennent à leur compatibilité entre mineurs et que pour eux, c'est considéré comme un risque.
J'ai l'impression qu'une chose qu'ils n'aiment pas chez KDE, c'est les cohabitations de différentes versions de libs.
QT4 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).
C'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).
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 1.
? KDE passera par Qt pour utiliser DBus.
> C'est p'tet pour ca que faire cohabiter Gst 0.8 et 0.10 ne leur plait pas
Ca ne plait à personne. Comme ça ne plait a personne d'avoir gtk 1.x et gtk 2.x.
Rester indéfiniment sur Gstreamer 0.8 et gtk 1 ne plait aussi à personne.
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.
[^] # Re: Tango : bof
Posté par Moonz . Évalué à 2.
gst-editor ?
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 0.
[^] # Re: Tango : bof
Posté par Seazor . Évalué à 1.
? KDE passera par Qt pour utiliser DBus.
T'as oublié le (voir plus haut) qui te le disait déjà qq lignes plus haut ! (y compris le lien vers freedesktop)
Il y a ceci aussi : http://linuxfr.org/~tanguy_k/22063.html
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
Partie Gst
Ca ne plait à personne. Comme ça ne plait a personne d'avoir gtk 1.x et gtk 2.x.
Ca leur plait d'autant moins que ca demande des adaptations dans les softs, qui sont causées par qqch d'extérieur.
Et si mes souvenirs sont bons, chez KDE, ils veulent une compatibilité source à travers toute la version majeure.
=> un soft prévu pour 4.0 doit normalement pouvoir compiler dans 4 ans sur un éventuel kde 4.5
Et 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.
Je 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 ).
Il doit pas y avoir grand chose ! (si qqun sait...)
Il 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.
Et ces applis seront extérieures à KDE ou au mieux dans kde-extra.
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 1.
Et alors ?
Ce n'est pas une réécriture de Dbus. C'est l'encapsulation de dbus (les même sources que ceux de freedesktop) dans Qt.
> 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
Ca ne change rien. Tu devrais le relire attentivement.
> Et si mes souvenirs sont bons, chez KDE, ils veulent une compatibilité source à travers toute la version majeure.
Gnome ne l'exige pas.
> Je commence même à me demander ce que Kde 4 va utiliser d'extérieur sans les wrapper
wrapper est différent de refaire l'implémentation.
Au-dessus il y avait :
- "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."
Il 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.
[^] # Re: Tango : bof
Posté par Seazor . Évalué à 2.
Et je crois que c'est le mot "directe" qui est important dans toute cette histoire.
> Et si mes souvenirs sont bons, chez KDE, ils veulent une compatibilité source à travers toute la version majeure.
Gnome ne l'exige pas.
D'où une différence dans les besoins de stabilité des APIs utilisées.
Ajoute cette contrainte aux discussions sur Gst et ca devrait finir d'expliquer l'interet de Phonon.
wrapper est différent de refaire l'implémentation.
- Ca n'est de toutes façons pas de l'utilisation directe. (voir plus haut)
- 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)
Il n'y aura qu'un implémentation de la partie client.
Et ? c'est celle-là qui les intéresse... non ? ;-)
Note : pendant que j'écrivais ceci, l'intervention ci-dessous de Johann apporte encore plus de poids !
Il 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 !
[^] # Re: Tango : bof
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
C'est mieux que ça. on veut (et sur la branche .x, on a eu) une compatibilité BINAIRE.
=> un soft prévu pour 4.0 doit normalement pouvoir s'executer sans recompilation dans 4 ans sur un éventuel kde 4.5
D'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.
[^] # Re: Tango : bof
Posté par Christophe Fergeau . Évalué à 3.
Ce 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).
[^] # Re: Tango : bof
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
On 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.
[^] # Re: Tango : bof
Posté par Gof (site web personnel) . Évalué à 4.
GNOME a plus besoin de freedektop, alors que KDE n'en a pas vraiment besoin.
KDE est très complet et a déjà toute les technologie nécessaire pour une bonne intégration dans son bureaux.
GNOME 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)
Je vois donc freedesktop comme une tentative d'intégrer les applications gtk-only à GNOME
Mais 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>)
Ceci dit, ce n'est que mon analyse à moi. Je me trompe peut-être
[^] # Re: Tango : bof
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 7.
(Note : je suis fana de KDE)
Le 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.
Par 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 !
Tango, 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.
Un 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é.
Aprè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.
Amicalement,
Jean-Christophe
[^] # Re: Tango : bof
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 5.
Il 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....).
Définir une spec de theme commune ensemble (nomage,taille...) et un theme tango-gnome et tango-kde, ça serait bien passé.
Apres, 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.
[^] # Re: Tango : bof
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 3.
Apparemment, 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.
Je 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).
Bref, donc si je résume :
- Tango serait incarner par des gnomistes seulement
- Tango ferait tout dans son coin
- Les kdeistes n'ont pas été consultés
Ca 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" ;-)
Jean-Christophe
[^] # Re: Tango : bof
Posté par lezardbreton . Évalué à 1.
Je te conseille de lire la réponse de Aaron Seigo : http://www.mail-archive.com/appeal@kde.org/msg00095.html
to 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.
[^] # Re: Tango : bof
Posté par clearstream . Évalué à 4.
C'est-à-dire à l'époque de la création de la mailing sur freedesktop (le 26 octobre 2005) :
http://lists.freedesktop.org/archives/tango-artists/
Première contribution KDE quelques jours après (le 31 octoble) :
http://lists.freedesktop.org/archives/tango-artists/2005-Oct(...)
Ca c'est bon esprit ! Que la force soit avec KDE.
Il y a du "KDE touch" dans Tango et c'est tant mieux.
C'est bien mieux que toutes ces "pleunicheries" : "Tango ne nous a pas prévenu, Tango bosse dans son coin, Tango put le Gnome, etc".
La mailing de xdg est sur freedesktop depuis mai 2003 :
http://lists.freedesktop.org/archives/xdg/
# bientot la fin de esound ?
Posté par zerbro . Évalué à 7.
http://live.gnome.org/RoadMap
qu'il est *peut etre* question de commencer à laisser tomber esd pour un nouveau serveur son : pulseaudio, lors du prochain gnome (2.18).
Je n'en avais jamais entendu parlé encore, mais pour ceux qui veulent en savoir d'avantage :
http://live.gnome.org/PulseAudio
http://pulseaudio.org/
D'apres ce que j'ai lu, pulseaudio n'a aucune dépendence vis a vis des bibliothèques gnome ou gtk.
Ca ne peut que améliorer les choses par rapport a esd...
Et si certains ici en savent un peu plus sur pulseaudio, qu'ils partagent leur avi.
[^] # Re: bientot la fin de esound ?
Posté par Yusei (Mastodon) . Évalué à 10.
Une vidéo pour un serveur son, est-ce bien raisonnable ? Ils pourraient partager leur ogg, non ?
(oui oui, j'y vais de ce pas)
[^] # Re: bientot la fin de esound ?
Posté par dawar (site web personnel) . Évalué à 3.
[^] # Re: bientot la fin de esound ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
C'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 :-)
[^] # Re: bientot la fin de esound ?
Posté par dawar (site web personnel) . Évalué à 7.
En 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...
[^] # Re: bientot la fin de esound ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Pour 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 :-)
[^] # Re: bientot la fin de esound ?
Posté par boris . Évalué à 2.
L'idée du serveur de sons n'est pas tant de permettre à plusieurs applications d'ouvrir /dev/dsp en même temps, mais plutôt d'offrir les mêmes fonctionnalités pour le son qu'un serveur X pour les fenêtres. Histoire que les clics de tout le monde ne soient pas joués par le serveur, mais par les terminaux.
Bon, après, chez soi sur son pti pc (Personal Computer) on voit moins l'intérèt, surtout avec dmix pour le multiplexage.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bientot la fin de esound ?
Posté par Mildred (site web personnel) . Évalué à 2.
Je 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.
Si tu veux déporter ton son, tu dois t'arranger pour déporter aussi ton dossier de musiques, par un partage NFS par exemple.
# MONO, pourquoi tant de haine ???
Posté par Fabrice Mousset (site web personnel) . Évalué à 1.
Chaque 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.
Personnellement, 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.
C'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.
Chaque 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.
Tout 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.
Moi, 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:
- système de fichiers,
- environnement graphique
- serveur Web / FTP / Mail
- etc..
Enfin, comme dirait nos chers politiciens, c'est mon avis et je le partage ;-)
[^] # Re: MONO, pourquoi tant de haine ???
Posté par boubou (site web personnel) . Évalué à 6.
Non, .NET comprend 350 casses spécifiées par l'ECMA et 3000 non spécifiées, propriétés de Microsoft.
Ceci é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.
[^] # Re: MONO, pourquoi tant de haine ???
Posté par TImaniac (site web personnel) . Évalué à 1.
Le 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.
Et 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#.
La 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.
[^] # Re: MONO, pourquoi tant de haine ???
Posté par boubou (site web personnel) . Évalué à 3.
Et 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#.
En 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.
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.
Hum. 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...
[^] # Re: MONO, pourquoi tant de haine ???
Posté par Mildred (site web personnel) . Évalué à 2.
les 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
Enfin, peut être que lorsque IE7 aura des tabs, ça changera ...
[^] # Re: MONO, pourquoi tant de haine ???
Posté par TImaniac (site web personnel) . Évalué à 2.
Pourquoi 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 ?
En quoi ADO.NET et ASP.NET (par exemple) sont spécifiques à Windows ?
Euh, 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.
Pour 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.
Et je ne parle pas de toute l'aspect web services.
Oué 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.
[^] # Re: MONO, pourquoi tant de haine ???
Posté par boubou (site web personnel) . Évalué à 2.
Parce 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.
Tu préfères par dénigrer systématiquement ton interlocuteur quand t'es pas d'accord avec lui ?
Tu remarqueras que je te réserve cette remarque car depuis qu'on trolle sur .NET ta méthode n'a toujours pas changé.
Euh, c'est ca que t'appel une lib "de base" ?
Non, 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.
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.
Ba 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).
Plus 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.
Pour 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.
Et 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...
Oué 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.
Encore 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 ?
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.
Et 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.
[^] # Re: MONO, pourquoi tant de haine ???
Posté par TImaniac (site web personnel) . Évalué à 3.
Ca change tout au contraire ! (Sinon je le dirais pas :) )
Pour 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".
C'est une méthode typique de la propagande.
Je 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 :
"Dans le langage commun, la propagande équivaut à la désinformation mise au service d'une cause politique d'intérêts privés."
Je ne désinforme pas, pas comme ceux qui sous-etende d'utiliser autre chose en "oubliant" de dire que c'est aussi dangereux.
Tu remarqueras que je te réserve cette remarque car depuis qu'on trolle sur .NET ta méthode n'a toujours pas changé.
Merci de t'apercevoir que je suis cohérent et que j'ai pas changé mes idées, comme quoi j'y crois.
e ?). Par exemple tu prends F-Spot et tu vois qu'il utilise par exemple System.Web qui n'est pas standardisé.
Euh... oué et ? Quel intérêt de standardisé System.Web ?
. 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
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.
Plus 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.
Comprend 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.
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...
Pas 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,
Encore 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.
Merci de rappeler où est l'interopérabilité dans les web-services, et où la normalisation a un intérêt.
Rien n'empêche une entreprise de breveter une API de création d'un serveur ou d'appel à un service
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.
Et voilà, toujours aussi imprécis (et faux).
Oué 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).
et en plus, ça ne concerne qu'une infime partie de l'api de .NET qui n'est pas standardisée.
Infime mais vitale, t'as vu comment ils utilisent les web services à fond dans Vista ?
[^] # Re: MONO, pourquoi tant de haine ???
Posté par boubou (site web personnel) . Évalué à 2.
J'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.
Toute 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.
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".
Voilà 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.
Je 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.
Nous 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.
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.
Tu 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.
Euh... 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.
Revenons à 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.
Comprend 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.
Bla, 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...
Pas 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,
Une fois qu'un délit est commis, on est puni même si on dit qu'on est désolé.
Merci 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.
Encore 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.
Oué c'est faux si tu veux, t'as raison, ils ont des brevets qui couvre une parti seulement des web services.
Pas du tout, ils ont des brevets sur l'implémentation standard et l'api de web services en .NET, pas sur "les web services".
Et ? Pourquoi tu discutes d'un détail comme ca ?
Parce que ça montre qu'en utilisant l'api en question, on prend plus de risques qu'en utilisant une autre api.
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).
Les brevets rétablissent une forme d'équilibre, ils ne font pas magiquement disparaître les risques.
Infime mais vitale, t'as vu comment ils utilisent les web services à fond dans Vista ?
As-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.
[^] # Re: MONO, pourquoi tant de haine ???
Posté par TImaniac (site web personnel) . Évalué à 2.
Ca c'est ton avis que je ne partage pas.
Tu 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.
Alors 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.
Dans les faits, les applications développées pour Mono utilisent certaines api microsoft non standardisées
Certes, mais ces parties sont pour moi loin d'être au coeur de Mono, et loin d'être vital à mon sens.
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.
Ca peut effectivement être un avantage, mais on standardise pas pour ca, j'espère que tu en conviendras.
Bla, 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...
Pourquoi 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.
Enfin 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.
Une fois qu'un délit est commis, on est puni même si on dit qu'on est désolé.
On 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.
Encore 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.
Franchement 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.
Pour être compatible .NET, Mono doit les implémenter de cette façon et c'est ce qui est fait actuellement.
Pourquoi "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.
oute 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.
J'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 ?
Parce que ça montre qu'en utilisant l'api en question, on prend plus de risques qu'en utilisant une autre api.
Vois 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.
Donc les brevets sont peut être gênant pour une partie de Vista, mais il ne faudrait quand même pas rêver.
Certes, 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.
Moi 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.
J'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.
[^] # Re: MONO, pourquoi tant de haine ???
Posté par Anonyme . Évalué à 1.
Maintenant 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.
Bien 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.
Je 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 ^^)
[^] # Re: MONO, pourquoi tant de haine ???
Posté par Anonyme . Évalué à 1.
http://jasondclinton.livejournal.com/52994.html
surtout 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...)
[^] # Re: MONO, pourquoi tant de haine ???
Posté par Croconux . Évalué à 2.
C'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,...).
[^] # Re: MONO, pourquoi tant de haine ???
Posté par boubou (site web personnel) . Évalué à 2.
Il est clair que ce système de brevets logiciels est délirant, mais c'est comme ça qu'il fonctionne.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Baobab
Posté par Samuel Verschelde (site web personnel) . Évalué à 3.
Et tant pis si c'est une application KDE, je n'ai pas peur de l'utiliser sous gnome aussi.
[^] # Re: Baobab
Posté par Nicolas Ternisien (site web personnel) . Évalué à 2.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Baobab
Posté par Samuel Verschelde (site web personnel) . Évalué à 5.
[^] # Re: Baobab
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Baobab
Posté par Nicolas Bourdais (Mastodon) . Évalué à 3.
http://blogs.igalia.com/mario/2006/07/19/the-new-baobab-widg(...)
[^] # Re: Baobab
Posté par Zorro (site web personnel) . Évalué à 3.
http://gdmap.sourceforge.net/
# Nommage des applications
Posté par Dring . Évalué à 10.
Je 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.
Mais quand je vois ça :
Je 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 ?
Peut-ê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.
[/troll]
[^] # Re: Nommage des applications
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 7.
[^] # Re: Nommage des applications
Posté par TImaniac (site web personnel) . Évalué à 6.
[^] # Re: Nommage des applications
Posté par mammique . Évalué à 1.
[^] # Re: Nommage des applications
Posté par Cereal Killer . Évalué à 3.
Package: pornview
Priority: optional
Section: utils
Installed-Size: 668
Maintainer: Debian QA Group <packages@qa.debian.org>
Architecture: i386
Version: 0.2pre1-6
Depends: 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)
Filename: pool/main/p/pornview/pornview_0.2pre1-6_i386.deb
Size: 235628
MD5sum: 19323b68dacb6418d6a15dcba6d58e3e
SHA1: aef25d8ab43af016274c4bae2d561ff2505e9562
SHA256: 21e6180cee5b33b415454320fc39a6ec4b685b73aca1fdc757df540189bf783c
Description: Image and movie viewer/manager
PornView is an image and movie viewer/manager with thumbnail previews.
Additional features includes thumbnail caching, directory tree views,
adjustable zoom, and fullscreen view. Slideshows allow for unattended
presentation of images for hands-free viewing. Pornview is written
using GTK+.
.
Homepage: http://pornview.sourceforge.net/
Tag: interface::x11, role::sw:application, uitoolkit::gtk, use::browsing, use::viewing, works-with::image:raster, x11::application
Excellent :)
[^] # Re: Nommage des applications
Posté par EmmanuelP . Évalué à 2.
Pour Orca, je ne sais pas.
Pour 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...
Mais, bon, aussi, est-ce que c'est vraiment important ?
C'est le nom du projet, laisse aux développeurs le plaisir de choisir le nom qu'ils veulent.
De 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.
Ornythorinque, pour le tableur, c'est plutôt pas mal... Il faut que je propose ça au responsable de gnumeric. :)
[^] # Re: Nommage des applications
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Nommage des applications
Posté par mobutu . Évalué à 4.
http://en.wikipedia.org/wiki/Tomboy
Et gimp, c'est une tenue de sadomasochiste.
http://www.bbc.co.uk/radio1/images/onemusic/docs/sleaze_nati(...)
Ce qui, quelque part, correspond au profil de ses utilisateurs. (j'en fais malheureusement partie.)
[^] # Re: Nommage des applications
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Nommage des applications
Posté par tontonflingueur . Évalué à 2.
http://sam.zoy.org/libcaca/
Au début je me suis dit, dommage comme nom ça passe vraiment pas en français.
Mais en fait le développeur est un francophone qui assume complètement (voir le logo).
[^] # Re: Nommage des applications
Posté par Cereal Killer . Évalué à 5.
[^] # Re: Nommage des applications
Posté par iug . Évalué à 1.
[^] # Re: Nommage des applications
Posté par meuble2001 . Évalué à 1.
[^] # Re: Nommage des applications
Posté par Oook . Évalué à 6.
http://fr.edevelop.org/Developpement/encule/
(script d'install d'E17)
[^] # Re: Nommage des applications
Posté par meuble2001 . Évalué à 1.
[^] # Re: Nommage des applications
Posté par mammique . Évalué à 3.
En effet pourquoi pas ?
[^] # Re: Nommage des applications
Posté par dinomasque . Évalué à 7.
BeOS le faisait il y a 20 ans !
[^] # Re: Nommage des applications
Posté par Zorro (site web personnel) . Évalué à 3.
En 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.
# Evolution 2.8 sur Mandriva 2006
Posté par Zorro (site web personnel) . Évalué à 5.
Il 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.
Bref. 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 :
À 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.
La réponse était en fait sur le wiki des développeurs indiens de Novell, mais il répond plus.
# Apropos
Posté par boris . Évalué à 4.
Et alors, bon, chez KDE quand ils veulent utiliser un bon produit écrit avec Gtk, ils ont la possibilité d'utiliser un thème qui fait que c'est Qt qui dessine les contrôles de Gtk. Comme ça, ni vu ni connu, Gimp ressemble à tout le reste et ça fait pas trop tâche sur le bureau.
Est ce qu'il existe un truc similaire pour Gtk ? Un thème Qt qui utilise Gtk pour le rendu du toolkit ?
[^] # Re: Apropos
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 2.
https://help.ubuntu.com/community/QtGnome
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.