Je vous ai donné des preuves que l'on pouvait programmer des applis en .NET qui tournent sur Mono. Et inversement que des applis Mono pouvaient tourner sur .NET (+ bibliothèques supplémentaires de mono, mais ça c'est valable pour tous logiciel qui ne peut se satisfaire des bibliothèques standard).
Vous voulez des applis "phares". Il n'y en pas pour l'instant selon vos exigences (car banshee fonctionnera très bientôt sur windows, mais vous ne voulez pas en entendre parler). Et alors, quel rapport avec Mono ?
Parce que Word et Internet Explorer ne sont pas écrit en python, je devrais considérer python comme un langage qui ne vaut rien ? Votre raisonnement relève exactement de cette logique.
Sur ce, bye.
P.S. : au passage, je ne suis pas un afficionado de mono. Je n'ai jamais rien programmé en mono, ni en .NET, ni en quoi que ce soit à part un peu de Emacs LISP, de php, et un brin de python et de c. Mais rien de sérieux pour l'instant. Seulement mono a le malheur d'être malaimé pour des raisons stupides, complètement idéologiques, et cela me hérisse le poil.
Arrêtez vos conneries. Vous vous basez sur un article qui date de 2006 pour dire cela. Aujourd'hui il reste quelque tous petits bugs, mais la compatibilité est quasi parfaite (avec mono 2.0). Et il est utilisable.
Mais vous êtes vraiment casse bonbon. Je vous cite :
"Bon ben voila tu viens de repondre a la question. Mono ne sert a rien puisque les applis que monsieur tout le monde aimeraient avoir ne tournent pas dessus."
Alors oui, "aimeraient" suppose qu'ils ne peuvent l'avoir donc cela sous-entend qu'il serait sur un système autre que .NET.
Bon, j'en ai marre de jouer votre jeu. Je vous présente une toute petite liste présentant des applications tournant indifféramment sous .NET et mono et vous faites la fine bouche.
J'en ai marre de jouer à votre jeu car vous établissez des limitations bidons.
On peut écrire une application sous .NET qui tourne sous Mono. Comme avec java. Seulement c'est rarement fait car les devs .NET programment pour Windows.
Java c'est pareil, si vous ne programmez pas en pensant multiplateforme ça risque de ne pas fonctionner.
Point barre. Votre question débile c'est une question sélective qui ne vise qu'à aller là ou vous désirez aller, ça n'est pas une vraie question.
C'est comme si je vous demandais de me citer une application écrite dans un autre langage que LISP, qui n'embarque pas un interpréteur LISP, qui soit populaire et "auto-programmable". Je sais que vous auriez du mal à en trouver. Et alors ?
On parle d'un environnement de développement (langes, bibliothèques, outils), la question n'est pas de savoir s'il existe des applications intéressantes qui tournent "out of the box" sur la plupart des OS écrite avec mono (de fait il en existe, j'en ai listé une brindille), la question est de savoir si on peut les écrire, et la réponse est oui.
De plus votre argumentation est stupide, c'est quoi une "application intéressante" ?
Tomboy, banshee (bientôt multi-plateforme) et f-spot ne sont pas des applications "intéressantes" ?
"tu as mal compris, ils ne veulent ni de .NET ni de Windows, c'est pourtant simple. "
J'ai parfaitement bien compris. Seulement l'argument du monsieur tout le monde, c'est windows. Donc cet argument il peut être utilisé contre quasiment tout les projets libres, et donc la plupart des langages majoritairement utilisés dans l'univers du libre. Les applis windows majoritairement utilisées ne sont pas des applis en python. Donc, si je suis le raisonnement d'Albert, python ça pue au moins autant que mono etc.
Je ne parle même pas des applications web basée sur .NET qui tournent indifféramment sous un serveur windows ou unix.
Quand au fameux "les applis que monsieur tout le monde aimeraient avoir". C'est qui monsieur tout le monde ?
Si monsieur tout le monde c'est la majorité et que l'on peut suppose que ce monsieur tout le monde utilise winsdows et des applis windows, alors monsieur tout le monde il utile Microsoft Word et Internet Explorer.
Et voyez-vous python, perl, java, ou lisp, comme mono, ils ne font pas tourner Internet Explorer et Microsoft Word, les logiciels de "monsieur tout le monde".
Donc à vous écouter on devrait tous passer à du .NET... sous windows.
Il aura un train de retard sur ce point. Mais en soi, en tant qu'outil de développement il ne sera en retard sur rien !
Le fond de mon argumentation n'était pas la comparaison entre jython et python, mais entre swfdec et Mono. L'un est autonome et n'a de retard qu'en comparaison avec un projet (.NET) sur lequel il a un soucis de compatibilité ENTRE AUTRE CHOSES, alors que l'autre n'existe que pour être compatible avec les applis flash qui traîne sur le net, ce qui fait qu'il est substantiellement TOUJOURS en retard (et très utile !).
Dès l'argument du retard ne peut pas être en soi un argument valable pour dénigrer l'ensemble du projet, sauf pour la personne qui ne s'intéresse à Mono que pour faire ses progs Windows sous Linux. Et vue le mépris que vous affichez pour Mono et tout ce qui touche de près ou de loin à Microsoft (non sans raisons, je vous l'accorde), cela m'étonnerai que Mono vous intéresse pour cette raison.
Reconnaissez que ce projet propose d'autres bibliothèques qui lui donne une valeur indépendamment de .NET !
Je suis d'accord sur ce point, c'est LE défaut de F-spot.
J'aime aussi beaucoup Gthumb, il fut pendant longtemps mon visionneur d'images favoris. Mais quelques fonctionnalités lui manque (pour mon usage personnel), même si sur quelques points il est supérieur à F-spot (et beaucoup plus mûr). Je pense tout particulièrement à sa vitesse, et ses outils de traitement en masse des images qui sont aussi simples que puissants.
Vous n'avez pas bien compris ce que je voulais dire.
Mono serait à la traîne s'il était dans la même situation qu'un swfdec : être compatible au maximum avec le .NET de Microsoft pour le premier, et être compatible au maximum avec flash pour le second.
Or, Mono peut-être utilisé sans se soucier de la compatibilité avec le .NET de Microsoft puisqu'il propose un ensemble de bibliothèques mûres qui le rende tout à fait utilisable dans le cadre du développement d'une appli en GTK pour Gnome, par exemple. Les exemples sont nombreux.
Ensuite votre exemple sur C# est juste, mais que dire... C'est pareil pour n'importe quel langage issue d'une norme, ou n'importe quel version "non officielle" d'un langage !
Le python de jython n'intégrera jamais les avancées de Python aussi vite que Python ! GCC n'intègrera jamais les nouvelles fonctionnalités issues d'un brainstorming sur le nouveau C aussi vite que la norme est imprimée !
Puisque Microsoft bosse directement sur ce qui sera C# 3, 4, 5, et bien oui, le C# de Mono prendra plus de temps pour proposer un C# équivalent.
Et alors ? Ça empêche de l'utiliser et d'être viable ?
Mais de quoi parlez-vous ? Si la compatibilité avec .NET (la plateforme Windows) est l'un des objectifs du projet Mono, il n'est pas le seul, et sans doute pas le premier.
Son objectif premier est de proposer un environnement de dévelopement libre utilisant comme base la machine virtuelle de .NET et les APIS définis par l'ECMA auxquels viennent s'ajouter GTK#, Gst#, un module Apache etc. en plus des bibliothèques compatibles avec la plateforme de Microsoft. Mais les bibliothèques de Microsoft ne sont pas indispensables à Mono !
Votre exemple sur le C est complètement à côté de la plaque puisque le C est un langage alors que Mono est un Framework.
Je peux dire exactement la même chose de C : gcc compilera toutes les applications C, sauf... celles qui utilisent des bibliothèques absentes sur la machine du type qui compile !
Il y a des applis en C pour Windows qui utilisent des apis Windows et, tenez-vous bien, un compilateur c sous linux sans bibliothèques compatibles ne compilera pas ces applis !
Comme prévu, toujours le même argument débile qui ressort. Mono ne sera et n'a jamais été à la traîne de quoi que ce soit puisqu'il propose son propre jeu de bibliothèques en plus des bibliothèques compatible .NET.
Oui F-spot peut être remplacé par Digikam, mais l'inverse est également vrai !
Puisque je préfère largement l'interface de F-spot, j'utilise... F-spot.
Tomboy est moins complet que Basket, mais il est aussi beaucoup moins bordélique et plus agréable à utiliser. Il lui manque juste l'inclusion de photos et un où deux trucs plus anecdotiques.
beagle en revanche s'avère être beaucoup plus lourd qu'un strigi ou un tracker. Ce qui est gênant pour un outil qui passe son temps à scanner les modifications sur le système de fichier.
Au sujet d'Emacs je rapelle, pour ajouter à cette discussion enflammée, que ce merveilleux dispose en standard depuis sa version 22 d'un tableur : SES.
Oui, GNUstep, bien sûr. J'aime énormément ce projet, malheureusement il faut avouer que l'intégration d'une appli utilisant GNUstep dans les environnements majeurs est mauvaise, sauf en ce qui concerne OSX bien entendu.
Pour le "tout le monde est d'accord pour...", je suis d'accord avec vous, ça n'est pas très intelligent. Je suis allez beaucoup trop vite.
Pour le reste, évidemment non ;) Car voyez-vous j'aime l'interface de Gimp ! Bon, soyons clair, je crois que j'apprécie l'interface d'Abiword parce que j'aime l'ergonomie générale de Gnome.
Cela dit, Gnome n'est pas pour moi parfait. NeXTStep avait lancé d'excellente pistes en matière d'ergonomie, qui ne furent reprisent dans quasiment aucun projet, même pas MacOSX.
Dans l'idéal il faudrait repenser entièrement la conception globale des traitements de texte. Mais d'ici là...
Pour ce qui est de gtk+, malgré tout le bien que je pense de Gnome, il me semble effectivement peu adapté (du moins tant que GTK+3 n'est pas sortit). Pour une raison : OSX.
Derrière ce titre un brin provocateur se cache deux remarques :
1) Abiword me semble un bon outil à étudier pour repenser l'interface de OO. Je le trouve clair et ergonomique (à deux trois points près).
2) Il manque à OpenOffice un truc très con dont dispose Abiword : la possibilité de séparer la feuille de style css lors de l'import en html, et la possibilité de convertir les images en base64. Mais j'ai peut-être manqué quelque chose.
Le deuxième point est mineur, mais le premier est majeur. L'interface, et tout le monde sera d'accord sur ce point, de OO.o est médiocre ergonomiquement, voire mauvaise, en plus d'être assez mal intégrée à l'environnement.
Passer de VCL à un toolkit du type wxwidget a-t-il été envisagé ?
Il faut rappeler que Go-oo ne fut pas penser au départ comme étant un fork, dès lors la présence de oo dans le nom était tout indiqué. Et le nom du projet importait finalement peu.
Vu la direction que prend le projet, il semble souhaitable que ses concepteurs envisagent de changer le nom.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Vous voulez des applis "phares". Il n'y en pas pour l'instant selon vos exigences (car banshee fonctionnera très bientôt sur windows, mais vous ne voulez pas en entendre parler). Et alors, quel rapport avec Mono ?
Parce que Word et Internet Explorer ne sont pas écrit en python, je devrais considérer python comme un langage qui ne vaut rien ? Votre raisonnement relève exactement de cette logique.
Sur ce, bye.
P.S. : au passage, je ne suis pas un afficionado de mono. Je n'ai jamais rien programmé en mono, ni en .NET, ni en quoi que ce soit à part un peu de Emacs LISP, de php, et un brin de python et de c. Mais rien de sérieux pour l'instant. Seulement mono a le malheur d'être malaimé pour des raisons stupides, complètement idéologiques, et cela me hérisse le poil.
[^] # Re: .NET et portabilité GUI = 2
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
"Bon ben voila tu viens de repondre a la question. Mono ne sert a rien puisque les applis que monsieur tout le monde aimeraient avoir ne tournent pas dessus."
Alors oui, "aimeraient" suppose qu'ils ne peuvent l'avoir donc cela sous-entend qu'il serait sur un système autre que .NET.
Bon, j'en ai marre de jouer votre jeu. Je vous présente une toute petite liste présentant des applications tournant indifféramment sous .NET et mono et vous faites la fine bouche.
J'en ai marre de jouer à votre jeu car vous établissez des limitations bidons.
On peut écrire une application sous .NET qui tourne sous Mono. Comme avec java. Seulement c'est rarement fait car les devs .NET programment pour Windows.
Java c'est pareil, si vous ne programmez pas en pensant multiplateforme ça risque de ne pas fonctionner.
Point barre. Votre question débile c'est une question sélective qui ne vise qu'à aller là ou vous désirez aller, ça n'est pas une vraie question.
C'est comme si je vous demandais de me citer une application écrite dans un autre langage que LISP, qui n'embarque pas un interpréteur LISP, qui soit populaire et "auto-programmable". Je sais que vous auriez du mal à en trouver. Et alors ?
[^] # Re: .NET et portabilité GUI = 2
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
De plus votre argumentation est stupide, c'est quoi une "application intéressante" ?
Tomboy, banshee (bientôt multi-plateforme) et f-spot ne sont pas des applications "intéressantes" ?
Paint.NET n'est pas une appli intéressante ?
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
J'ai parfaitement bien compris. Seulement l'argument du monsieur tout le monde, c'est windows. Donc cet argument il peut être utilisé contre quasiment tout les projets libres, et donc la plupart des langages majoritairement utilisés dans l'univers du libre. Les applis windows majoritairement utilisées ne sont pas des applis en python. Donc, si je suis le raisonnement d'Albert, python ça pue au moins autant que mono etc.
Bref, c'est un raisonnement con !
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
http://www.misuzilla.org/dist/net/twitterircgateway/
http://paint.net/ (plus que quelques petits bugs)
http://banshee-project.org/download/ (bientôt sous windows)
http://www.integrazioneweb.com/monosim/
Je ne parle même pas des applications web basée sur .NET qui tournent indifféramment sous un serveur windows ou unix.
Quand au fameux "les applis que monsieur tout le monde aimeraient avoir". C'est qui monsieur tout le monde ?
Si monsieur tout le monde c'est la majorité et que l'on peut suppose que ce monsieur tout le monde utilise winsdows et des applis windows, alors monsieur tout le monde il utile Microsoft Word et Internet Explorer.
Et voyez-vous python, perl, java, ou lisp, comme mono, ils ne font pas tourner Internet Explorer et Microsoft Word, les logiciels de "monsieur tout le monde".
Donc à vous écouter on devrait tous passer à du .NET... sous windows.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
Le fond de mon argumentation n'était pas la comparaison entre jython et python, mais entre swfdec et Mono. L'un est autonome et n'a de retard qu'en comparaison avec un projet (.NET) sur lequel il a un soucis de compatibilité ENTRE AUTRE CHOSES, alors que l'autre n'existe que pour être compatible avec les applis flash qui traîne sur le net, ce qui fait qu'il est substantiellement TOUJOURS en retard (et très utile !).
Dès l'argument du retard ne peut pas être en soi un argument valable pour dénigrer l'ensemble du projet, sauf pour la personne qui ne s'intéresse à Mono que pour faire ses progs Windows sous Linux. Et vue le mépris que vous affichez pour Mono et tout ce qui touche de près ou de loin à Microsoft (non sans raisons, je vous l'accorde), cela m'étonnerai que Mono vous intéresse pour cette raison.
Reconnaissez que ce projet propose d'autres bibliothèques qui lui donne une valeur indépendamment de .NET !
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
J'aime aussi beaucoup Gthumb, il fut pendant longtemps mon visionneur d'images favoris. Mais quelques fonctionnalités lui manque (pour mon usage personnel), même si sur quelques points il est supérieur à F-spot (et beaucoup plus mûr). Je pense tout particulièrement à sa vitesse, et ses outils de traitement en masse des images qui sont aussi simples que puissants.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 3.
Mono serait à la traîne s'il était dans la même situation qu'un swfdec : être compatible au maximum avec le .NET de Microsoft pour le premier, et être compatible au maximum avec flash pour le second.
Or, Mono peut-être utilisé sans se soucier de la compatibilité avec le .NET de Microsoft puisqu'il propose un ensemble de bibliothèques mûres qui le rende tout à fait utilisable dans le cadre du développement d'une appli en GTK pour Gnome, par exemple. Les exemples sont nombreux.
Ensuite votre exemple sur C# est juste, mais que dire... C'est pareil pour n'importe quel langage issue d'une norme, ou n'importe quel version "non officielle" d'un langage !
Le python de jython n'intégrera jamais les avancées de Python aussi vite que Python ! GCC n'intègrera jamais les nouvelles fonctionnalités issues d'un brainstorming sur le nouveau C aussi vite que la norme est imprimée !
Puisque Microsoft bosse directement sur ce qui sera C# 3, 4, 5, et bien oui, le C# de Mono prendra plus de temps pour proposer un C# équivalent.
Et alors ? Ça empêche de l'utiliser et d'être viable ?
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 6.
Son objectif premier est de proposer un environnement de dévelopement libre utilisant comme base la machine virtuelle de .NET et les APIS définis par l'ECMA auxquels viennent s'ajouter GTK#, Gst#, un module Apache etc. en plus des bibliothèques compatibles avec la plateforme de Microsoft. Mais les bibliothèques de Microsoft ne sont pas indispensables à Mono !
Votre exemple sur le C est complètement à côté de la plaque puisque le C est un langage alors que Mono est un Framework.
Je peux dire exactement la même chose de C : gcc compilera toutes les applications C, sauf... celles qui utilisent des bibliothèques absentes sur la machine du type qui compile !
Il y a des applis en C pour Windows qui utilisent des apis Windows et, tenez-vous bien, un compilateur c sous linux sans bibliothèques compatibles ne compilera pas ces applis !
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à -1.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
En effet, les résultats de Tracker ne m'ayant jamais sevrit de rien, je ne l'ai jamais vraiment utilisé...
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Camille_B . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
Puisque je préfère largement l'interface de F-spot, j'utilise... F-spot.
Tomboy est moins complet que Basket, mais il est aussi beaucoup moins bordélique et plus agréable à utiliser. Il lui manque juste l'inclusion de photos et un où deux trucs plus anecdotiques.
beagle en revanche s'avère être beaucoup plus lourd qu'un strigi ou un tracker. Ce qui est gênant pour un outil qui passe son temps à scanner les modifications sur le système de fichier.
[^] # Re: Bah, c'est comme les écrans brillants !
Posté par Camille_B . En réponse au journal Adieu les écrans normaux. Évalué à 10.
[^] # Re: N'est stupide que la stupidité :)
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 1.
[^] # Re: N'est stupide que la stupidité :)
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 3.
http://www.emacswiki.org/cgi-bin/wiki/SimpleEmacsSpreadsheet
Je ne pense pas qu'il soit touché par la limite des 65K lignes
[^] # Re: oo vs abiword
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 1.
[^] # Re: oo vs abiword
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 1.
[^] # Re: oo vs abiword
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 1.
Vous connaissez un toolkit multiplateforme, assez bien intégré à l'envirronement sur lequel il tourne, et qui soit "moderne" ?
Il y a QT, je sais, mais encore ?
(c'est dans ces moments là que l'info sur un GTK+3 prend tout son sens...)
[^] # Re: oo vs abiword
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 1.
Pour le reste, évidemment non ;) Car voyez-vous j'aime l'interface de Gimp ! Bon, soyons clair, je crois que j'apprécie l'interface d'Abiword parce que j'aime l'ergonomie générale de Gnome.
Cela dit, Gnome n'est pas pour moi parfait. NeXTStep avait lancé d'excellente pistes en matière d'ergonomie, qui ne furent reprisent dans quasiment aucun projet, même pas MacOSX.
Dans l'idéal il faudrait repenser entièrement la conception globale des traitements de texte. Mais d'ici là...
Pour ce qui est de gtk+, malgré tout le bien que je pense de Gnome, il me semble effectivement peu adapté (du moins tant que GTK+3 n'est pas sortit). Pour une raison : OSX.
# oo vs abiword
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 2.
1) Abiword me semble un bon outil à étudier pour repenser l'interface de OO. Je le trouve clair et ergonomique (à deux trois points près).
2) Il manque à OpenOffice un truc très con dont dispose Abiword : la possibilité de séparer la feuille de style css lors de l'import en html, et la possibilité de convertir les images en base64. Mais j'ai peut-être manqué quelque chose.
Le deuxième point est mineur, mais le premier est majeur. L'interface, et tout le monde sera d'accord sur ce point, de OO.o est médiocre ergonomiquement, voire mauvaise, en plus d'être assez mal intégrée à l'environnement.
Passer de VCL à un toolkit du type wxwidget a-t-il été envisagé ?
[^] # Re: Nom pourrie
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 2.
[^] # Re: Nom pourrie
Posté par Camille_B . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 3.
Vu la direction que prend le projet, il semble souhaitable que ses concepteurs envisagent de changer le nom.