Articles précédents : Logiciel
- [26] Linux-VServer : Nouvelle version stable, nouveau site Web
- [31] cdrkit : Debian forke cdrtools
- [0] Prométhée 5.0
- [9] pkpgcounter v1.84 supporte le calcul du taux de couverture d'encre
- [35] Qui va remplacer SysVinit ?
- [63] Premiers pilotes libres pour les imprimantes Samsung
- [16] Beagle 0.2.8 : prise en charge de Thunderbird
- [7] Une plateforme Web créant des sites dynamiques
- [14] Bygfoot en version 2.0
- [0] Cultuzz offre son moteur de réservation Cultbooking en Open Source
Liens connexes
- Release notes (508 hits)
- Sortie de GTK+ 2.10 (549 hits)
- First look at GNOME 2.16 (1570 hits)
- GNOME Fr (1267 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Rentrée des classes pour GNOME 2.16
Posté par liberforce (Jabber id, page perso, ). Modéré le 07 septembre 2006.
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.
![[en]](../../../images/en.png)
Release notes (508 hits)![[fr]](../../../images/fr.png)
Sortie de GTK+ 2.10 (549 hits)-
First look at GNOME 2.16 (1570 hits)
-
GNOME Fr (1267 hits)
> Lire les commentaires (171 commentaires, moyenne: 3,2).
un journal
A noter aussi un journal sur le sujet avec qq autres liens : https://linuxfr.org/~plagiats/22587.html
Mono
>> 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#
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 (page perso, ) le 07/09/2006 à 09:13. (lien). Évalué à 8.Tu sais, personne ne t'oblige a utiliser tomboy. Si sticky Notes te convient, il est encore la.
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 (page perso, ) le 07/09/2006 à 09:42. (lien). Évalué à 0.>> comparer F-spot a gthumb, c'est osé. Ce n'est *pas du tout* le meme type d'application
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 (page perso, ) le 07/09/2006 à 09:57. (lien). Évalué à 10.KDE 4 arrive et il n'y aucune incertitude juridique qui assombrit son code
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 (page perso, ) le 07/09/2006 à 10:11. (lien). Évalué à 10.Ah, ah, je suis de retour de vacances, on va pouvoir troller !
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 () le 07/09/2006 à 11:11. (lien). Évalué à 3.l'histoire des 283 brevets dans le noyau linux (dont 27 de microsoft) concerne plus de monde. http://linuxfr.org/2004/08/02/16957.html
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 (page perso, ) le 07/09/2006 à 11:17. (lien). Évalué à 2.Certes, certes, on compte aussi plus de 500 brevets portant directement sur Java. La question cruciale est qui possède ces brevets, quelle est leur portée, de quels autres brevets dépendent-ils, etc. Concernant .NET, on sait que les brevets de MS ont été déposés pour assurer le contrôle de la plateforme et qu'ils sont cruciaux pour son implémentation. En gros, ils sont incontournables. Il faudrait faire une analyse précise des brevets qui couvrent le noyau linux pour en savoir plus. Pour prendre un exemple, le format gif a longtemps été protégé par un brevet, ce qui ne posait pas vraiment de problème car ce format est pourri. Par contre, le format mp3 est protégé par des brevets (incontournables) ce qui pose problème jusqu'à leur disparition (en 2010). Il y a donc brevet et brevet. Ceux dont je parle pour .NET sont potentiellement dangereux.
-
[^]Re: Mono
Posté par zerbro (page perso, ) le 07/09/2006 à 11:38. (lien). Évalué à 4.Le format gif (codage LZW pour etre precis) n'a rien de pourri pour la compression d'une image sur 256 niveau de gris, sans perte. Mais tout le monde l'utilisait pour la couleur, ce qui avait donc pour effet de dégrader l'image (vu que c'etait pas vraiment prevu pour la couleur).
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 (page perso, ) le 07/09/2006 à 11:52. (lien). Évalué à 2.Au temps pour moi. En fait, ce que je voulais dire c'est que gif était extrêmement populaire, mais que jpeg (pour lequel il n'y a pas de brevet payant) puis le png (pas de brevet à ma connaissance) ont rapidement constitué des alternatives viables. Le cas du mp3 est moins évident car son support par de nombreux hardware fait que son concurrent ogg s'impose beaucoup moins vite que jpeg et png n'ont "remplacé" gif.
Désolé pour ce jugement de valeur sans grand fondement...-
[^]Re: Mono
Posté par Gmooron (page perso, ) le 07/09/2006 à 16:10. (lien). Évalué à 4.Le Gif a été populaire principalement pour sa "fonctionnalité" (je sais pas si c'est le terme à utiliser) d'animation, fonctionnalité inexistante dans le jpg et le png.
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 (page perso, ) le 08/09/2006 à 07:01. (lien). Évalué à 4.J'ajouterais surtout visionneuse a ta liste car très peu lise ce type d'animation. Ce format est pourtant très pratique et l'image d'une qualité qui ne se compare meme pas au gif
-
-
-
[^]Re: Mono
Posté par Antoine () le 09/09/2006 à 22:18. (lien). Évalué à 3.Le MP3 est aussi un format pourri, et pourtant tout le monde l'utilise.
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 (page perso, ) le 07/09/2006 à 11:30. (lien). Évalué à 2.Ce que j'adore avec toi, Timaniac, c'est que tu ne fais que répéter servillement la propagande de De Icaza.
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 (page perso, ) le 07/09/2006 à 11:59. (lien). Évalué à 2.qu'il n'y a pas plus de danger qu'avec un autre soft
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 (page perso, ) le 07/09/2006 à 12:10. (lien). Évalué à 5.Non, c'est que le risque est acceptable, c'est-à-dire en dessous d'un certain seuil.
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 (page perso, ) le 07/09/2006 à 12:28. (lien). Évalué à 0.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).
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 (page perso, ) le 07/09/2006 à 12:44. (lien). Évalué à 8.Ok je e réponds ici pour ce post et aussi pour celui plus bas sur la lourdeur.
>> 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 (page perso, ) le 07/09/2006 à 13:00. (lien). Évalué à 7.Mais FORCER les utilisateurs du desktop à utiliser ces applications Mono en remplacant les applis par défaut
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 (page perso, ) le 07/09/2006 à 13:07. (lien). Évalué à 5.Les applis par défaut de Gnome doivent se baser sur GTK+ et être en C.
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 () le 07/09/2006 à 13:09. (lien). É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 (Jabber id, page perso, ) le 07/09/2006 à 14:32. (lien). Évalué à 5.les plugins gedit, pessulus et sabayon pour l'administration, jhbuild pour compiler GNOME... j'imagine que j'en oublie ?
-
[^]Re: Mono
Posté par Guillaume Caron (Jabber id, ) le 07/09/2006 à 17:10. (lien). Évalué à 3.Y'a aussi :
- 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--
« How ’bout a magic trick? Taa-daa! It’s…ah, it’s gone. »
-
-
[^]Re: Mono
Posté par zebob (Jabber id, ) le 07/09/2006 à 19:10. (lien). Évalué à 1.Il me semble également que Baobab est en Perl.
-
[^]Re: Mono
-
-
[^]Re: Mono
Posté par Juke (Jabber id, page perso, ) le 07/09/2006 à 22:08. (lien). Évalué à 2.J'ai du mal à me passer de la deskbar maintenant, c'est peut etre parce que je suis sur un petit ecran, j'ai enlever la barre d'adresse dans le navigateur et je n'utilise que la deskbar. Par contre c'est dommage c'est encore assez instable.
-
-
[^]Re: Mono
Posté par patrick_g (page perso, ) le 07/09/2006 à 14:27. (lien). Évalué à 2.>> 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.
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 (page perso, ) le 07/09/2006 à 15:08. (lien). Évalué à 4.Je pense que tu cernes mal la situation. Evidemment, dans l'idéal, un seul framework avec un seul langage, c'est plus élégant.
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 (page perso, ) le 07/09/2006 à 16:43. (lien). Évalué à 2.>> Bah oué et ? Vas-y, code C-Pot ou Python-Pot
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 (page perso, ) le 07/09/2006 à 18:10. (lien). Évalué à 6.Tu as deja utilisé un logiciel du genre f-spot ?
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 (page perso, ) le 07/09/2006 à 18:40. (lien). Évalué à 3.>> 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.
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 (page perso, ) le 07/09/2006 à 20:01. (lien). Évalué à 3.Je viens de reregarder gthumb, c'est vrai qu'il y a une gestion de tag.
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 boubou (page perso, ) le 07/09/2006 à 19:11. (lien). Évalué à 4.J'ai beaucoup de photos et j'ai essayé F-Spot (sous Fedora Core, donc dans sa version 0.1.10). Ca plante tout le temps. Moralité, j'utilise digikam qui est beaucoup plus complet et beaucoup plus stable. J'avoue que cet intégrisme (je ne parle pas de toi) Gnome ou Kde me fatigue. Pourquoi ne pas utiliser digikam et gaim, par exemple, sans se poser la question du desktop qui lui est associé ?
-
[^]Re: Mono
-
-
[^]Re: Mono
Posté par zebob (Jabber id, ) le 07/09/2006 à 19:38. (lien). Évalué à 5.un équivalent en python
JBrout ? http://jbrout.python-hosting.com/wiki/WikiStart
-
-
-
-
[^]Re: Mono
Posté par Christophe Fergeau () le 07/09/2006 à 15:33. (lien). Évalué à 3.« 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. »
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 (page perso, ) le 07/09/2006 à 23:02. (lien). Évalué à 2.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 !!
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 (page perso, ) le 08/09/2006 à 06:23. (lien). Évalué à 1.Putain c'est bien la peine que je poste 2634661 messages si c'est pour que personne ne comprenne ma position ! (hum ça doit vouloir dire que je n'arrive pas à m'exprimer...inquiétant ça ;-)
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 (page perso, ) le 08/09/2006 à 07:43. (lien). Évalué à 5.C'est juste une question de cohérence technique du projet et d'empreinte mémoire du desktop Gnome.
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 (Jabber id, page perso, ) le 08/09/2006 à 12:17. (lien). Évalué à 3.C'est un peu absurde de dire « regardez, on vous propose tout pleins de bingings, donc vous pouvez utiliser le langage que vous voulez pour faire une application Gnome » et de dire ensuite « Dans Gnome, on accepte que les programmes qui utilisent tel ou tel language ». Enfin, je trouverais celà peu cohérent.
-
-
-
-
-
-
-
-
-
[^]Re: Mono
Posté par ribwund () le 07/09/2006 à 11:52. (lien). Évalué à 3.Pourtant, chercher des brevets sur le site de l'USPTO, c'est facile http://www.uspto.gov/
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 (page perso, ) le 07/09/2006 à 10:13. (lien). Évalué à 1.Je trouve ca bizarre de lire encore des trolls a propos de mono. C'est un peu comme si je disais aujourd'hui, kde ca pue c'est pas libre. Des fois je me dis que les trolls ont la peau dure...regrettable.
-
-
[^]Re: Mono
Posté par j (page perso, ) le 07/09/2006 à 10:02. (lien). Évalué à 0.cet ajout de Mono
D'une (1) application dépendant de Mono - qui ne fait pas partie de GNOME.-
[^]Re: Mono
Posté par imalip (page perso, ) le 07/09/2006 à 10:19. (lien). Évalué à 4.Justement, nouveauté, c'est que maintenant elle en fait officiellement partie. Sinon, ils n'en parleraient pas dans les release notes.
--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: Mono
Posté par liberforce (Jabber id, page perso, ) le 07/09/2006 à 11:13. (lien). Évalué à 1.Je pense qu'il faisait remarquer que c'est tomboy qui fait partie de GNOME, pas Mono...
-
[^]Re: Mono
-
-
-
-
[^]Re: Mono
Posté par zerbro (page perso, ) le 07/09/2006 à 10:13. (lien). Évalué à 6.Chacun son opinion, mais de mon point de vu, comparer gthumb et f-spot, c'est un peu comparer xmms et rhythmbox (j'y vais à la hache pour la comparaison ;)
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...
-
-
-
[^]Re: Mono
Posté par TImaniac (page perso, ) le 07/09/2006 à 09:33. (lien). Évalué à 3.Si Tomboy a une ou deux fonctions en plus alors pourquoi ne pas améliorer plutôt Sticky Notes ?
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 (page perso, ) le 07/09/2006 à 10:00. (lien). Évalué à 5.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)
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 (page perso, ) le 07/09/2006 à 11:39. (lien). Évalué à 2.Amusant, quand on voit les bindings python et C# (par exemple).
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 () le 07/09/2006 à 09:38. (lien). Évalué à 1.Pourquoi faut-il choisir entre GNOME et KDE? Perso je préfère réserver les ressources de mon ordinateur aux tâches pour lesquelles je le destine plutôt que de faire s'exécuter une interface utilisateur de plus en plus lourdingue et bourrée de gadgets tous plus inutiles les uns que les autres. J'ai utlisé KDE pendant un moment par le passé. Après avoir trop longtemps espéré une stabilisation et une optimisation du code plutôt qu'une course folle à l'ajout de fonctionalités que je n'utilise pas, j'ai décidé de le laisser tomber.
-
[^]Re: Mono
Posté par liberforce (Jabber id, page perso, ) le 07/09/2006 à 10:47. (lien). Évalué à 5.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.
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 (Jabber id, page perso, ) le 07/09/2006 à 10:51. (lien). Évalué à 2.Apparemment tu en a énervé plus d'un avec ta remarque :-)
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 (page perso, ) le 07/09/2006 à 12:10. (lien). Évalué à 8.Merci de m'avoir donné ce lien très interessant. Je n'avais pas vu qu'il avait posté une réponse à mon journal de l'époque (maintenant je l'ai dans mon aggrégateur...il ne m'échappera plus ;-)
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 (Jabber id, page perso, ) le 07/09/2006 à 12:13. (lien). Évalué à 3.Entièrement d'accord avec toi. De toute façon, le débat (s'il a vraiment eu lieu) est fini visiblement, le marketing a vaincu !
-
[^]Re: Mono
Posté par Mars () le 08/09/2006 à 01:19. (lien). Évalué à 1.En dehors de tout aspect technique (pas difficile je ne comprends même pas 1% de ce qui s'y raconte ... même si je persiste à continuer la lecture), et au delà de toute querelle de clocher (Gnome/KDE) je me pose quelques questions :
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 Aurélien Girard () le 08/09/2006 à 08:15. (lien). Évalué à 2.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.
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 !).
-
[^]Re: Mono
Posté par Johann Ollivier-Lapeyre (page perso, ) le 08/09/2006 à 08:23. (lien). Évalué à 6.Le passage KDE1 à KDE2 avait changé beaucoup de chose:
- 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--
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
-
-
-
[^]Re: Mono
Posté par TImaniac (page perso, ) le 07/09/2006 à 12:19. (lien). Évalué à 1.Pourquoi s'alourdir avec Mono (en plus des brevets Microsoft) alors que Python remplit ce besoin parfaitement ?
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 (Jabber id, page perso, ) le 07/09/2006 à 12:23. (lien). Évalué à 4.Pourquoi s'alourdir avec Python
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 (page perso, ) le 07/09/2006 à 23:30. (lien). Évalué à 1.Beaucoup trop car c'est de l'utilisation de la mémoire qui aurait pu et du être évitée.
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 (Jabber id, page perso, ) le 08/09/2006 à 07:34. (lien). Évalué à 3.1 Go, c'est un standard pour les ordinateurs neufs, ce qui est loin de représenter le marché actuel à mon avis. Et encore, je trouve encore des machines neuves avec seulement 256Mo de RAM.
-
-
-
[^]Re: Mono
Posté par Christophe Fergeau () le 07/09/2006 à 12:29. (lien). Évalué à 5.« '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 ? »
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 (page perso, ) le 07/09/2006 à 13:12. (lien). Évalué à 1.Non, t'en as 1 par appli python ou c#.
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 () le 07/09/2006 à 13:52. (lien). Évalué à 3.« 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. »
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 (page perso, ) le 07/09/2006 à 16:07. (lien). Évalué à 3.Ce que j'ai voulu dire, c'est que ce n'est pas une barrière technique, et qu'elle peut sauter. La preuve, même si ce n'est pas intégralement fait dans Mono, c'est en bonne parti fait.
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 () le 09/09/2006 à 22:44. (lien). Évalué à 1.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.
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 () le 07/09/2006 à 18:40. (lien). Évalué à 2.> sans partage de lib, c'est une mauvaise configuration ou une lacune technique
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 (Jabber id, page perso, ) le 07/09/2006 à 20:01. (lien). Évalué à 3.Il y a une différence entre le fait de charger un module pour toutes les instances, et le fait que les instances se partagent les données de ce modules..
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--
It is no bug, it's future-
[^]Re: Mono
Posté par Moonz () le 08/09/2006 à 16:20. (lien). Évalué à 1.Ça, c'était un exemple simple. Tu peux aussi faire des trucs plus "pervers", du genre remplacer une fonction dans un module (os.getenv = my_getenv). Bon, là, ça reste simple: c'est toujours que toucher à des références.
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 (Jabber id, page perso, ) le 18/09/2006 à 09:37. (lien). Évalué à 1.Je suis d'accord avec toi, mais je pense qu'il est possible de passer outre, justement grace au fait que tout soit mutable :)
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 ! :) )--
It is no bug, it's future
-
-
-
-
-
-
-
-
[^]Re: Mono
Posté par nolius () le 07/09/2006 à 12:21. (lien). Évalué à 4.pourquoi les brevets de mircosoft te pose un gros problème moral lorqu'il s'agit de mono et aucun lorsque ca concerne le noyau linux http://linuxfr.org/2004/08/02/16957.html
à moins que tu n'utilise pas linux?
-
[^]Re: Mono
Posté par liberforce (Jabber id, page perso, ) le 07/09/2006 à 12:36. (lien). Évalué à 3.Gnome commence à remplacer des applications actuelles par des applications Mono
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 (page perso, ) le 07/09/2006 à 13:12. (lien). Évalué à 3.>D'ailleurs il y a un clone de Tomboy en C++ qui devrait être écrit
Non, ca existe déjà depuis longtemps ;)
http://basket.kde.org/development.php
-> [ ]-
[^]Re: Mono
Posté par lezardbreton (Jabber id, page perso, ) le 07/09/2006 à 13:23. (lien). Évalué à 3.Oui, sauf que techniquement et fonctionnellement, c'est un projet abouti et ceci sans machine virtuelle. Là, on parle de Tomboy, donc entièrement l'inverse.
Pareil, je sors voir s'il fait beau dehors :)
-
-
-
[^]Re: Mono
Posté par Mildred (Jabber id, page perso, ) le 07/09/2006 à 20:02. (lien). Évalué à 7.On pourrait aussi imaginer que tout les framework de haut niveau s'intègrent ensemble en utilisant la même machine virtuelle, les même libs ...
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
Un petit mot sur tango. Le but est louable, mais la methode est completement a l'inverse de la facon dont doit se developper une specification qui pretend etre adoptee par plusieurs bureaux.
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'a
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.