Mono préféré à Java pour les développements d'applications pour station de travail Linux

Mono préféré à Java pour les développements d'applications pour station de travail Linux


Selon certains experts, Mono serait désormais plus apprécié que Java par les développeurs d'applications pour station de travail en environnement GNU/Linux.
Parmi les plus populaires applications, nous pouvons cité Tomboy outil de prise de note écrit en C#, Banshee un lecteur multimédia apprécié par des utilisateurs de Gnome, l'outil de recherche Do pour le gestionnaire de fenêtres Gnome, etc


Pour rappel, Mono est une implantation libre du framework Microsoft .Net, soutenue par la société Novell, qui possède la distribution GNU/Linux Suse.




plus d'infos
:arrow: http://www.sdtimes.com/link/33597


voir aussi
:arrow: Mono et C# distribué avec Debian : Richard M. Stallman s'insurge
:arrow: Microsoft : C# et CLI donnés aux développeurs




Mono, malgré les risques potentiels, serait plus attrayant que le désormais "libre" Java, qu'en pensez-vous ?

Bah ouais, en même temps faire du spécifique Gtk ou Gnome avec java c'est un peu se tirer une balle dans le pied alors que pour le même cout en dev (ou pas grand chose de plus) on peut avoir une appli portable...
Car si on compte le nombre d'appli SWT et Swing qui sont utilisées sous Linux (qui ne dois pas être faramineux non plus, genre Azureus, Eclipse/Netbeans, LimeWire par exemple)...

C'est un peu trollifère et à coté de la plaque comme comparaison. Tomboy et banshee ne sont rien de plus que des appli Gtk+/Gnome comme il y en a surement des paquets codées en python (toujours par exemple).

ET puis j'adore cette phrase

Code:

---

1 2

Eclipse 3.1 lacks features that MonoDevelop has, including code completion, integrated debugging, refactoring, and unit testing capabilities, Hargett claimed. "I've found in my consulting that people who install Eclipse 3.1 through the [Debian] package manager say, 'This is terrible.' " He said that customers that have installed a version of Eclipse beyond 3.1 like it.

---

Il n'a jamais eu l'occasion de toucher eclipse l'auteur. Ce sont des fonctionnalités qui datent d'eclipse 2 au minimum 8O

Pour être en train de passer progressivement de Java+Swing à Qt(+Boost) dans mon développement je trouve plutôt osé de faire du C# sous Linux (je précise quand même que je n'ai que très peu touché à C#).

Ce langage dépend quand même exclusivement de Microsoft qui peut changer l'API quand bon lui semble et aura surtout une longueur d'avance permanente en version Windows (sur Mono). Et quand je vois le temps de sortie ainsi que le retard de la version Linux de Silverlight (Moonlight) j'ai vraiment tendance à ne pas vouloir utiliser ce genre de choses.

Bref, à voire, mais je ne m'attends pas à une révolution du développement GUI sous Linux grace à Mono, loin de là.

Microsoft vient de passer le C# sous une licence qui protège les développeurs du monde libre de toutes "attaques aux brevets". Reste les libs, mais Gtk# n'en pose aucun.
http://tirania.org/blog/archive/2009/Jul-06.html

Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.

Citation:

---

Envoyé par sinok

ET puis j'adore cette phrase

Citation:

---

Eclipse 3.1 lacks features that MonoDevelop has, including code completion, integrated debugging, refactoring, and unit testing capabilities, Hargett claimed. "I've found in my consulting that people who install Eclipse 3.1 through the [Debian] package manager say, 'This is terrible.' " He said that customers that have installed a version of Eclipse beyond 3.1 like it.

---

Il n'a jamais eu l'occasion de toucher eclipse l'auteur. Ce sont des fonctionnalités qui datent d'eclipse 2 au minimum 8O

---

C'est clair que ça rend son article peu crédible ! Il ne sait visiblement pas du tout de quoi il parle ! Encore du beau boulot d'intox...
:bravo:

Citation:

---

Envoyé par Xitog

Microsoft vient de passer le C# sous une licence qui protège les développeurs du monde libre de toutes "attaques aux brevets". Reste les libs, mais Gtk# n'en pose aucun.
http://tirania.org/blog/archive/2009/Jul-06.html

Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.

---

Je ne suis pas juriste, mais je n'ai pas vu que cette "promesse" était une licence. De ce fait, je ne vois là dedans aucun engagement de Microsoft sur le long terme, et les conditions sont assez drastiques. De ce fait, l'intervention récente de Richard Stallman est bien d'actualité.

Maintenant, concernant la préférence des développeurs, les Linuxiens n'ont jamais apprécié Java. De ce fait, Java n'a jamais vraiment percé en environnement Linux. On compare donc un nombre limité de projets à un autre nombre limité de projets. Car si dans les projets très grand publique, je ne connais que Vuze en Java, il n'en demeure que nombre d'autres applications sont en Java (une bonne partie de ce qui tourne autour d'OpenStreetMap à commencer par JOSM, les outils de gestion du tuxDroid, bien des applications de développement...).

En ce qui concerne l'opinion, pour moi, Mono ne doit avoir qu'une seule fonction : faire tourner en environnement Linux des applications produites spécifiquement pour .Net, mais en aucun cas un projet Linux ne devrait choisir Mono comme techno.

Sinok et Vintz : la plus grosse critique de l'article concerne le packaging d'Eclipse dans les distributions. Et il est vrai que les versions d'Eclipse des dépôts sont on ne peux plus buggy. Mais le problème est surtout qu'à mon sens, Eclipse de part son mode de fonctionnement n'a rien à faire dans les dépôts puisqu'il est mieux installé individuellement.

Pour moi c'est plus un sujet à troll qu'autre chose : il n'y a rien pour étayer cette affirmation. Personnellement je connais peu d'entreprises qui investissent dans du développement .NET sous Linux contrairement à celle qui développent en Java...

Mono ne m'intéresse pas parce qu'il est condamné à rester pour toujours un sous-dotnet. Les nouvelles fonctionnalités sont implémentées avec des mois de retard par rapport à la version de Microsoft, et parfois jamais, d'ailleurs, et son l'existence même, qui est une implémentation de technologies brevetées, est soumise au bon vouloir de Microsoft, qui a toujours évité de prendre des engagements définitifs permettant de dire "l'avenir de Mono est assuré". Il est évident qu'il est impossible pour une entreprise d'investir dans des applications écrites pour Mono, à mes yeux. Si vraiment Microsoft voulait "ouvrir" Dotnet de manière pérenne, il faudrait au minimum :

• Étendre à tous les composants de Dotnet l'Open Specification Promise
• Créer un organisme analogue au JCP permettant aux autres acteurs du monde Dotnet (Novell, Infragistics,Embarcadero...) de s'impliquer dans son évolution

Dans le fond, le gars a pas tort : Java n'a rien foutu pour Swing depuis 5 ans (ou presque). Quelques bonnes avancées avec l'intégration bureau dans Java 1.5, mais depuis quasi rien pour l'utilisateur final. Même le thème par défaut est toujours le laid (oui, laid) Metal, et c'est au développeur de préciser qu'il veut une application avec un L&F "comme les autres".

Il faudrait que Java s'émancipe de son idée "support pour tous" et entame des améliorations du genre "support pour le plus grand nombre". Le Swing App Framework est un pas en ce sens, avec sa gestion automatique des informations de session. Un autre ajout intéressant pourrait être l'accès aisé (et unifié) à la base de registre de Windows, au Gconf de Gnome, ou autre. Mais bon, je rêve.

le langage le plus utilisé pour des projets sur sourceforge est il me semble java...

Citation:

---

Envoyé par dingoth

Dans le fond, le gars a pas tort : Java n'a rien foutu pour Swing depuis 5 ans (ou presque). Quelques bonnes avancées avec l'intégration bureau dans Java 1.5, mais depuis quasi rien pour l'utilisateur final. Même le thème par défaut est toujours le laid (oui, laid) Metal, et c'est au développeur de préciser qu'il veut une application avec un L&F "comme les autres".

---

C'est totalement faux. Java 1.5 et Java 6 ont marqué quelques très grosses avancées, concernant Swing : simplification de mise en oeuvre (SwingWorker), amélioration des performances, nouvelles fonctionnalités. Le Look and Feel par défaut, maintenant, c'est Nimbus, au fait. Et il a un aspect tout à fait sympa. Il est fondé sur le système de L&F skinnable Synth, introduit par Java 1.5, qui permet de modifier l'aspect de son L&F très facilement.

Citation:

---

Envoyé par gorgonite

Selon certains experts, Mono serait désormais plus apprécié que Java par les développeurs d'applications pour station de travail en environnement GNU/Linux.

---

Stephen O'Grady, l'expert en question, est bien connu pour ces positions pro-Microsoft.

Cela dit, il est vrai que Sun n'a jamais fait les efforts nécessaires pour imposer Java comme solution crédible au développement d'applications de bureau : que ce soit sa toolkit propriétaire (awt), son API objet (swing), la lourdeur au démarrage de sa JVM (Hotspot) et son allocation mémoire a-priori, ...

Bref, plein de petites choses qui font préférer une application native, voir une application Mono. Dommage. J'espérais que la donne allait changer avec le projet JavaFX mais non. :calim2:

Bonjour,

Citation:

---

J'espérais que la donne allait changer avec le projet JavaFX mais non

---

Il me semble pour ma part que Sun s'engage sur une piste glissante de ce côté-là. JavaFX est vu par pas mal de monde comme étant une tentative quelque peu désespérée de rattraper le train des RIA/RDA, dont la locomotive Flex a clairement une longueur d'avance. Pour moi, mettre en avant JavaFX au détriment de Swing, c'est une grave erreur de comm' de la part de Sun : Swing permet de faire de vraies appli desktop (une RDA en AIR sera toujours à des milles derrière une appli Swing ou Eclipse RCP en termes d'intégration au desktop et de performance). Beaucoup de développeurs ne se sentent-ils pas un peu trahis par ce foin autour des paillettes JavaFX ? Le navire Swing a pas mal chaviré ces derniers temps... Par exemple, le départ d'Hans Muller pour Adobe (alors à la tête du projet Swing Application Framework il me semble). J'ai ensuite été très très rassuré de voir que le JSR 296 avait été validé pour Java 7, et qu'il avait trouvé un nouveau porteur.
Quant à Nimbus : peut-être peut-il jouer le rôle de facteur d'acceptation supplémentaire de Java auprès des utilisateurs...

Citation:

---

Envoyé par 4mleth

J'ai ensuite été très très rassuré de voir que le JSR 296 avait été validé pour Java 7, et qu'il avait trouvé un nouveau porteur.

---

Pour ma part, je pense que le problème est plus profond qu'une simplification du framework Swing.

Je trouve que le modèle objet n'est pas vraiment adapté au codage d'une IHM (d'une toolkit oui, mais pas d'une IHM). D'ailleurs l'utilisation des syntaxes déclaratives (JavaFx, XAML) semble prouver la chose.

Et je trouve aussi que le langage lui même manque de souplesse. Par exemple il manque l'équivalent des "méthodes anonymes" pour associer des actions a des évènements. Ou des moyens simples de gérer le multitache, la ré-entrance, ... au niveau du code.

Citation:

---

Quant à Nimbus : peut-être peut-il jouer le rôle de facteur d'acceptation supplémentaire de Java auprès des utilisateurs...

---

Hum... A l'heure de l'intégration application/desktop et de la personnalisation a outrance des thèmes de bureau, je suis pas bien sûr qu'un énième thème "statique" spécifique à Java soit un facteur d'acceptation. :?

Citation:

---

Envoyé par Traroth2

C'est totalement faux. Java 1.5 et Java 6 ont marqué quelques très grosses avancées, concernant Swing : simplification de mise en oeuvre (SwingWorker), amélioration des performances, nouvelles fonctionnalités. Le Look and Feel par défaut, maintenant, c'est Nimbus, au fait. Et il a un aspect tout à fait sympa. Il est fondé sur le système de L&F skinnable Synth, introduit par Java 1.5, qui permet de modifier l'aspect de son L&F très facilement.

---

Désolé, mais pour une fois, je vais être sec : TOTALEMENT faux ? Non. S'il peut y a voir des erreurs, l'ensemble n'est pas TOTALEMENT faux. Quand j'écris quelque chose, qu'on le lise plutôt que le survoler ! « Totalement faux » impliquerait qu'il n'y a pas eu d'avancée du tout, ce qui contredit ton argumentation.

Mais au fait, qu'y a-t-il eu comme avancée pour l'utilisateur final (dans la lib standard et sans des "trucs") ? Les bureaux supportant la 3D ? L'uniformisation des menus d'aide afin d'avoir une API minimale commune ? L'intégration native de vidéo ? Un parser et renderer HTML un peu potable ? Le support de zones transparentes ? Voir même une TreeTable, un DatePicker ou un panneau rétractable ? Que nenni : on a du se contenter de tables triables, du double-buffering (pas trop tôt) et d'un splash-screen. Dans le registre intéressant, on a enfin eu l'intégration avec la barre des tâches et la classe Desktop.

Mais bon, je parle d'utilisateur final, on me répond avec le SwingWorker... Mais c'est pour les développeurs, ça, et même... pour les développeurs qui ne connaissaient pas bien l'EDT. Je n'ai plus réalisé d'application qui freeze depuis 2001 et à l'époque le SwingWorker, c'était une lib à part et souvent buggée.

Et puis, y'aura Java 7, à nouveau parent pauvre en ce qui concerne les applis bureaux, puisque nous n'aurons que Swing Application Framework. Pour les développeurs, y'aura même pas le beans-binding et c'est pas certain à 100% qu'on aie le beans-validation ou les JMC. (Merci JavaFx d'avoir piqué les développeurs de Swing au passage.)

En ce qui concerne le LaF, mea culpa, je parlais bien de Metal ne connaissant pas Nimbus (normal, je parlais de Java 6 aussi, pas Java 6 update 10), mais je viens de jeter un oeil à Nimbus : il ne vaut pas mieux. Par défaut, une application doit avoir un LaF système, et pas un truc pondu. Qu'on garde Nimbus et Metal pour les applets, ok, mais pas pour les applis desktop. En java, on est obligé de préciser qu'on veut pas de ces trucs laids. C'est pas normal. En tant qu'utilisateur final d'applications, j'entends voir une application utilisant le thème de mon système d'exploitation en priorité, puis des trucs customisés dans un recoin des préférences si c'est indispensable. Si j'ai choisi Clearlooks comme thème par défaut sur Linux, c'est pas pour me retrouver avec Metal (ou Nimbus).

Alors oui, Java est en retard dans les applications desktop, et je comprends parfaitement que les développeurs préfèrent Mono à Java pour l'instant.

Citation:

---

Envoyé par robert_trudel

le langage le plus utilisé pour des projets sur sourceforge est il me semble java...

---

http://www.ohloh.net/languages/compa...s&percent=true

Sur quelques 10 000 projets va me semble représentatif ;)

(enfin si on exclu le HTML du comparatif :aie:)

Ce graphique nous indique une tendance très nette à la hausse pour Mono, et un début de stagnation pour Java (montée linéaire jusqu'à 2006, puis, au même moment, montée pour Mono... on peut dire que les développeurs commencent à se répartir entre les deux camps ?).

Un peu hors sujet, maintenant... :

Je me permets de rebondir sur la remarque de pseudocode au sujet des syntaxes déclaratives pour les IHM (d'un côté Mono arrive avec XAML, et de l'autre, Java a bien du mal à trouver un truc efficace, peut-être XWT pour SWT, qui semble très prometteur).
En fait, il me semble que l'engouement pour ce type de syntaxe a quelque peu obombré le fait que dans certains cas, on doit bâtir des interfaces reconfigurables, non statiques, non déterminées à priori, ou encore dont la logique de structuration n'est pas nécessairement arborescente. Ca concerne sans doute moins de 2% des applications, mais dans ce cas, la syntaxe déclarative ne rend pas forcément service. Dans cette catégorie d'applications, on peut ranger certains outils auteurs de création multimédia, les applications qui ne se contentent pas d'aligner les widgets pour visualiser des données, des applications "très graphiques", etc. Oui, la syntaxe déclarative XML/YAML rationalise le développement dans 99% des cas, mais non, le développement d'IHM ne s'y résume pas intégralement. Et je trouve que le manque d'innovation "ergonomiques" côté programmatique est grave et gênant (cela vaut pour Java, mais sans doute pour bien d'autres langages).

Par contre je ne suis pas certain de comprendre :

Citation:

---

Je trouve que le modèle objet n'est pas vraiment adapté au codage d'une IHM (d'une toolkit oui, mais pas d'une IHM). D'ailleurs l'utilisation des syntaxes déclaratives (JavaFx, XAML) semble prouver la chose.

---

.
La syntaxe déclarative reste 100% objet (une balise XML correspond à l'instanciation d'un nouvel objet, avec ses attributs, ses méthodes), et, dans le cas de Flex/ActionScript, l'articulation du syntaxique et du programmatique est fantastiquement flexible...

Citation:

---

Envoyé par gege2061

http://www.ohloh.net/languages/compa...s&percent=true

---

Jolie lien, je suis souvent sur ohloh mais je connaissais pas cette partie la.

Citation:

---

Ce graphique nous indique une tendance très nette à la hausse pour Mono, et un début de stagnation pour Java (montée linéaire jusqu'à 2006, puis, au même moment, montée pour Mono... on peut dire que les développeurs commencent à se répartir entre les deux camps ?).

---

Le graphique ne parle pas de Mono mais juste de C#.

Je pense que la progression de C# vient en bonne partie du renouvellement quasi imposé des applications (remplacement de VB6 et VBA qui ne sont plus supporté par microsoft). Ca va stagner a un moment, d'ailleur si on regarde bien sa stagne deja depuis presque 1an.

Citation:

---

Envoyé par eclesia

Ca va stagner a un moment, d'ailleur si on regarde bien sa stagne deja depuis presque 1an.

---

C'est même en train de décliner de plus de 25% depuis le début de l'année : http://www.ohloh.net/languages/compa...asure=projects (attention un indice se cache sur le graphique :aie:)

Citation:

---

Envoyé par gege2061

http://www.ohloh.net/languages/compa...s&percent=true

Sur quelques 10 000 projets va me semble représentatif ;)

(enfin si on exclu le HTML du comparatif :aie:)

---

hum, sourceforge c'est près de 180 000 projets...

Citation:

---

Envoyé par 4mleth

En fait, il me semble que l'engouement pour ce type de syntaxe a quelque peu obombré le fait que dans certains cas, on doit bâtir des interfaces reconfigurables, non statiques, non déterminées à priori, ou encore dont la logique de structuration n'est pas nécessairement arborescente. Ca concerne sans doute moins de 2% des applications, mais dans ce cas, la syntaxe déclarative ne rend pas forcément service. Dans cette catégorie d'applications, on peut ranger certains outils auteurs de création multimédia, les applications qui ne se contentent pas d'aligner les widgets pour visualiser des données, des applications "très graphiques", etc. Oui, la syntaxe déclarative XML/YAML rationalise le développement dans 99% des cas, mais non, le développement d'IHM ne s'y résume pas intégralement. Et je trouve que le manque d'innovation "ergonomiques" côté programmatique est grave et gênant (cela vaut pour Java, mais sans doute pour bien d'autres langages).

---

C'est un peu hors sujet, mais est-ce que tu pourrais préciser ces points ?

Par exemple, quelle est leur logique de structuration, si elle n'est pas arborescente ? Des exemples visibles ? Comment sont-elles créés ? Dans quel contexte ?

Ou un lien explicatif, bien sûr.

Merci.

<HORSSUJET>
Un exemple tout bête concernant la logique arborescente : j'ai du développer un "éditeur hypertexte" où l'utilisateur peut librement convoquer et spatialiser des éléments au sein d'un espace bidimensionnel. Chaque élément peut être graphiquement connecté aux autres (comme dans un outil de mind mapping ou un visualisateur de graphs).
Puisque l'on a une surface sur laquelle reposent des objets graphiques qui sont au même niveau "hiérarchique", il n'y a alors qu'un seul niveau de profondeur. Donc une syntaxe XML n'apporte rien (un noeud racine, avec tout les éléments enfants au même niveau... autant faire une liste programmatique de "monComposantEspace.add(composantElementXX).
De plus, puisque l'on ne peut pas savoir a priori le nombre d'éléments présents (l'utilisateur ajoute et supprime à discrétion des noeuds, là encore, comme dans un éditeur de mind maps), il n'y tout bonnement rien à "déclarer" (le composant graphique global représenté en XML sera donc un truc du genre <espaceLibre att1="chou" att2="navet" />).

Une autre remarque qui me vient : dans le cas d'une application radicalement "dockable&redockable" (Eclipse, par exemple), la structuration arborescente des zones ne cesse de changer, donc on ne peut une bonne fois pour toute la déclarer dans un arbre XML. Là encore, l'apport cognitif pour le développeur d'une représentation arborescente est limitée.

A moins d'avoir fait une grave erreur de raisonnement, il me semble que dans ces cas limites d'IHM fortement reconfigurables et au contenu dynamique, en passer par du tout programmatique est nécessaire.
</HORSSUJET>

<HORS SUJET>
Mais selon toi quelle autre modèle le représente ?

Ou si, comme tu sembles le suggérer (en passer par du tout programmatique est nécessaire, dis-tu), dans l'exemple des fenêtres dockables, qui invalide une arborescence par les panneaux et sous panneaux dans les fenêtres, peut être une autre arborescence serait correcte ? Qu'une arborescence soit pas pertinente ne signifie pas que toutes les arborescences ne le serait pas.

Qu'en penses-tu ?

</HORS SUJET>
(de toutes façons je m'en fiche de mono).

Citation:

---

Envoyé par robert_trudel

hum, sourceforge c'est près de 180 000 projets...

---

C'est mieux comme ça : http://www.ohloh.net/p

Citation:

---

Results 0 - 10 of 306,101.

---

La plupart des applications écrite pour Mono utilisent GTK#, ce qui les rends totalement transparente pour l'utilisateur de Gnome par rapport à une autre application native, avec Java et swing c'est autre chose ...
Je ne connais pas grand chose à Java, mais mon experience d'utilisateur sur Linux ne me donne sérieusement pas envie de me lancer dans ce language pour créer des applications bien intégrées dans cet OS.
Il suffit de voir Limewire, c'est tout simplement incohérent (fond de la bonne couleur sur la fenêtre de préférence, mais pas sur la fenêtre de sélection de fichier :roll:), "buggé" (des boutons sont cachés sur certaines fenêtre), ...
http://files.getwebb.org/files/49/e7.../miniature.png
D'ailleurs ils ont même dû jouer avec des thèmes et des boutons persos sur Limewire pour avoir un style sympathique sur l'ensemble des OS tellement Swing est moche sur Linux.
Les applis Java sur Windows sont bien intégrées (je pense) mais pourquoi c'est différent sur linux ? C'est vraiment pas terrible pour un framework qui se veut totalement multiplateforme ...
Maintenant si un jour Sun/Oracle commence à améliorer Swing sur Linux, je veux bien y aller, mais là je reste avec Mono + Gtk, qui me donne un meilleur rendu sur Windows que ce que Swing me donne sur Linux. Swing devrait suivre l'exemple de QT4 qui est vraiment très joli sur l'ensemble des principaux OS du marché.
Il y existe aussi le binding de Gtk sur Java, mais est-il vraiment supporté correctement (GTK# est tout a fait supporté par Novell, sur Linux, OS X et Windows) ?

Pas étonnant que Mono dépasse Java sur Linux, il est fait pour cet OS.

[HS]
Qu'en est il de l'apparence de Swing sur OS X ?
[/HS]

EDIT: Les WPF ne sont pas prévus dans les prochaines versions de Mono. Pour la définition d'interface avec XML, on a Glade/GTKBuilder avec GTK.

bon je vais également troller, mais qui utilise des applications en entreprise développés sous linux comme application desktop ? je veux des noms :mrgreen:

Citation:

---

Envoyé par *alexandre*

bon je vais également troller, mais qui utilise des applications en entreprise développés sous linux comme application desktop ? je veux des noms :mrgreen:

---

Moi et ma société, avec ca > http://puzzle-gis.codehaus.org/snapshots/puzzle11.jpg

Toute notre boite est sous linux, et on se fait nos propres outils en Java ET en Swing ET c'est parfaitement intégré dans le Look de l'OS.

C'est pas bientot fini vos préjugé anti-swing. :langue: allez troller ailleurs.

Citation:

---

Envoyé par eclesia

Moi et ma société, avec ca > http://puzzle-gis.codehaus.org/snapshots/puzzle11.jpg

Toute notre boite est sous linux, et on se fait nos propres outils en Java ET en Swing ET c'est parfaitement intégré dans le Look de l'OS.

C'est pas bientot fini vos préjugé anti-swing. :langue: allez troller ailleurs.

---

C'est pas du troll, on constate juste que les applications en Java sont généralement moins bien intégrées.

Par contre je suis vraiment intrigué par la façon dont vous faites pour avoir un tel L&F avec Swing 8O. Vous utilisez un theme spécial, c'est la JRE, ou l'OpenJRE ???
(j'y connais rien à Java, mais si c'est aussi bon, je veux bien m'y lancer).

Chez moi, une appli Java ca ressemblerais plus à ca :
http://files.getwebb.org/files/f6/53.../miniature.png
Et avec un truc comme Human, Clearlook ou Dust ca le fait pas trop :(

Citation:

---

Envoyé par Rapha222

C'est pas du troll, on constate juste que les applications en Java sont généralement moins bien intégrées.

Par contre je suis vraiment intrigué par la façon dont vous faites pour avoir un tel L&F avec Swing 8O. Vous utilisez un theme spécial, c'est la JRE, ou l'OpenJRE ???
(j'y connais rien à Java, mais si c'est aussi bon, je veux bien m'y lancer).

Chez moi, une appli Java ca ressemblerais plus à ca :
http://files.getwebb.org/files/f6/53.../miniature.png
Et avec un truc comme Human, Clearlook ou Dust ca le fait pas trop :(

---

en effet, tu t'y connais pas en java... faudrait donc arrêter de troller.... quand on maitrise pas le domaine...

comme si un changement de look faisait en sorte... que ça devenait bon...

Citation:

---

Envoyé par robert_trudel

en effet, tu t'y connais pas en java... faudrait donc arrêter de troller.... quand on maitrise pas le domaine...

comme si un changement de look faisait en sorte... que ça devenait bon...

---

Je demande pourquoi il existe une telle différence d'apparence entre deux applications utilisant le même framework, c'est pas du troll ca ...

Citation:

---

Envoyé par Rapha222

Je demande pourquoi il existe une telle différence d'apparence entre deux applications utilisant le même framework, c'est pas du troll ca ...

---

L'apparence que tu vois sur cette capture est le Look&Feel Nimbus. je l'ai volontairement utilisé sur cette capture avec un parametre supplémentaire au démarrage de l'application.

Citation:

---

en effet, tu t'y connais pas en java... faudrait donc arrêter de troller.... quand on maitrise pas le domaine...

---

Je confirme, tu ne connais visiblement pas assez Java. :mrgreen:

Swing est dit plus lent que AWT ou SWT ou les autres gtk et compagnie pour la simple raison que c'est une surcouche indépendente de l'OS. Tout est déssiné avec Java2D est n'a rien a voir avec les composants natif. Swing adapte le Look&Feel au theme du systeme quand cela est possible, depuis la 1.5 le resultat est tres correct. Et si on prend la derniere version de netbeans (6.7) on a aucune différence entre le theme natif et swing aussi bien sur win que linux ou mac.

Ce que tu semble considérer comme une faiblesse, est pour un moi un veritable avantage car j'arrive a faire mes propres composants sur-mesure pour mes applications comme la boussole en haut a gauche de la capture d'ecran. je sais que je peux les styler a l'extreme pour obtenir différent effets :
- http://img41.imageshack.us/img41/7346/capturemapfx1.jpg
- http://files.getwebb.org/index.php?m...ew&id=cre66hrk
- http://puzzle-gis.codehaus.org/snapshots/puzzle11.jpg

Je crois qu'on fait fausse route a vouloir toujours coller au theme natif. Si on regarde bien, il y a de plus en plus d'application qui s'affranchisse de cette contrainte : tous les jeux videos, l'editeur 3D Blender, les sites web, les RIA , le navigateur chrome et surement d'autres que je ne connais pas. Ce n'est plus au systeme de dicter l'ergonomie de l'application. C'est l'application qui choisi son ergonomie.

Citation:

---

Envoyé par eclesia

Swing est dit plus lent que AWT ou SWT ou les autres gtk et compagnie pour la simple raison que c'est une surcouche indépendente de l'OS. Tout est déssiné avec Java2D est n'a rien a voir avec les composants natif. Swing adapte le Look&Feel au theme du systeme quand cela est possible, depuis la 1.5 le resultat est tres correct. Et si on prend la derniere version de netbeans (6.7) on a aucune différence entre le theme natif et swing aussi bien sur win que linux ou mac.

---

Bonne nouvelle :mrgreen:

Citation:

---

Ce que tu semble considérer comme une faiblesse, est pour un moi un veritable avantage car j'arrive a faire mes propres composants sur-mesure pour mes applications comme la boussole en haut a gauche de la capture d'ecran. je sais que je peux les styler a l'extreme pour obtenir différent effets :
- http://img41.imageshack.us/img41/7346/capturemapfx1.jpg
- http://files.getwebb.org/index.php?m...ew&id=cre66hrk
- http://puzzle-gis.codehaus.org/snapshots/puzzle11.jpg

---

On sait le faire également avec GTK

Citation:

---

Je crois qu'on fait fausse route a vouloir toujours coller au theme natif. Si on regarde bien, il y a de plus en plus d'application qui s'affranchisse de cette contrainte : tous les jeux videos, l'editeur 3D Blender, les sites web, les RIA , le navigateur chrome et surement d'autres que je ne connais pas. Ce n'est plus au systeme de dicter l'ergonomie de l'application. C'est l'application qui choisi son ergonomie.

---

Ca dépends des points de vue ...

Citation:

---

Envoyé par 4mleth

Par contre je ne suis pas certain de comprendre : .
La syntaxe déclarative reste 100% objet (une balise XML correspond à l'instanciation d'un nouvel objet, avec ses attributs, ses méthodes), et, dans le cas de Flex/ActionScript, l'articulation du syntaxique et du programmatique est fantastiquement flexible...

---

Ce dont on a besoin c'est une syntaxe "hierarchique". Il est vrai que le concept d'encapsulation de l'Objet permet d'avoir cette notion de hierarchie. Mais a-t-on vraiment besoin de l'héritage et le polymorphisme pour définir une IHM ? Avez vous déjà réussi a spécifier une IHM en UML ?

Citation:

---

Envoyé par eclesia

Je crois qu'on fait fausse route a vouloir toujours coller au theme natif. Si on regarde bien, il y a de plus en plus d'application qui s'affranchisse de cette contrainte : tous les jeux videos, l'editeur 3D Blender, les sites web, les RIA , le navigateur chrome et surement d'autres que je ne connais pas. Ce n'est plus au systeme de dicter l'ergonomie de l'application. C'est l'application qui choisi son ergonomie.

---

Il ne s'agit pas de "coller" au thème natif par mimétisme. Il s'agit d'utiliser le vrai thème natif. Sinon ce n'est qu'une course entre les thèmes Swing et les thèmes de l'OS, et je ne parle meme pas des thèmes perso téléchargeables par millier.

Et il n'y a pas uniquement le problème de la charte graphique (couleur, formes), mais aussi celui du comportement : widget/gadget/plasmoid, systray/dock, notifications visuelles/sonores, interactions clavier/souris/pad/vocale, services de l'OS (correction ortho, multimedia, connectivité, ...).

Java a fait le choix de la portabilité en prenant comme solution l'implémentation de couches d'abstraction pour tout ce qui concerne l'OS. Avantage : on a accès aux mêmes fonctions sur tous les OS. Inconvénient : ces fonctions sont un socle "minimum" commun à tous les OS.

Si on veut faire une application qui utilise le maximum du potentiel d'un OS, alors Swing n'est pas vraiment la solution idéale, a moins de ré-implémenter les fonctions en Java ou en faisant des appels natifs (JNI).

<HORSSUJET theme="syntaxe IHM">

Citation:

---

Ou si, comme tu sembles le suggérer (en passer par du tout programmatique est nécessaire, dis-tu), dans l'exemple des fenêtres dockables, qui invalide une arborescence par les panneaux et sous panneaux dans les fenêtres, peut être une autre arborescence serait correcte ? Qu'une arborescence soit pas pertinente ne signifie pas que toutes les arborescences ne le serait pas.

---

Une IHM déclarée dans un arbre XML représente un état "déclaré", "figé" de celle-ci. Donc oui, tu peux très bien déclarer l'état initial de ton appli docakable de la sorte, mais cette syntaxe ne te dira rien des possibilités de reconfiguration des fenêtres les unes par rapport aux autres. Quelle autre arborescence pourrait être correcte ? Aucune, je pense, chacune d'entre elles représenterait _une_ configuration de l'appli à un moment donnée, mais le principe de redockage dans toute sa dynamique serait manqué.
Ta question "quel autre modèle ?" est passionnante. Et complexe. Quelle forme syntaxique pourrait représenter quelque chose qui relève de l'arborescence dynamique ? Peut-être une sorte de graph ? Un réseau sur lequel seraient indiqués par des arcs les reconfigurations possibles des composants ? (le graph n'est pas arborescent). Ben voilà une belle question de sujet de thèse en IHM...
Pour ma part, je vois dans le programmatique la possibilité de tout faire, au détriment d'une certaine lisibilité et efficacité pour les cas simples.

Citation:

---

Ce dont on a besoin c'est une syntaxe "hierarchique". Il est vrai que le concept d'encapsulation de l'Objet permet d'avoir cette notion de hierarchie. Mais a-t-on vraiment besoin de l'héritage et le polymorphisme pour définir une IHM ? Avez vous déjà réussi a spécifier une IHM en UML ?

---

Absolument capital pour moi. Par exemple, dans un séquenceur audio/MIDI, tu auras la classe "Segment", qui te dira que sur une piste tu peux disposer des segments redimensionnables avec un nom, une couleur, etc. Puis, tu auras des données MIDI (class MIDISegment extends Segment) ou audio (class AudioSegment extends Segment), qui ajouteront des propriétés supplémentaires (respectivement afficher les données MIDI sous forme de piano-roll ou bien le contenu audio sous forme de forme d'onde).
La spec UML, pas fait (mais parce que j'ai surtout bossé jusqu'ici sur des projets de recherche où on est parfois un peu moins formels, ce qui est mal d'ailleurs). Mais ça ne me poserait aucun soucis je pense, pour bien montrer les types génériques d'objets graphiques que le système affiche (sans doutes, des classes "abstraites") et les extensions qu'on en fait pour représenter tel ou tel type de donnée dans sa spécificité.

<HORSSUJET>

Citation:

---

Envoyé par eclesia

Swing est dit plus lent que AWT ou SWT ou les autres gtk et compagnie pour la simple raison que c'est une surcouche indépendente de l'OS. Tout est déssiné avec Java2D est n'a rien a voir avec les composants natif. Swing adapte le Look&Feel au theme du systeme quand cela est possible, depuis la 1.5 le resultat est tres correct. Et si on prend la derniere version de netbeans (6.7) on a aucune différence entre le theme natif et swing aussi bien sur win que linux ou mac.

---

ne pas oublier qu'il est possible d'accéléré le java 2d en activiant l'opengl... depuis java 5

Citation:

---

Envoyé par eclesia

Je crois qu'on fait fausse route a vouloir toujours coller au theme natif. Si on regarde bien, il y a de plus en plus d'application qui s'affranchisse de cette contrainte : tous les jeux videos, l'editeur 3D Blender, les sites web, les RIA , le navigateur chrome et surement d'autres que je ne connais pas. Ce n'est plus au systeme de dicter l'ergonomie de l'application. C'est l'application qui choisi son ergonomie.

---

c'est déjà le cas avec windows: office, windows media player en sont un bon exemple....

sous mac il y a les applicatons avec le métal et les autres...

Citation:

---

Envoyé par dingoth

[...]

En ce qui concerne le LaF, mea culpa, je parlais bien de Metal ne connaissant pas Nimbus (normal, je parlais de Java 6 aussi, pas Java 6 update 10), mais je viens de jeter un oeil à Nimbus : il ne vaut pas mieux. Par défaut, une application doit avoir un LaF système, et pas un truc pondu. Qu'on garde Nimbus et Metal pour les applets, ok, mais pas pour les applis desktop. En java, on est obligé de préciser qu'on veut pas de ces trucs laids. C'est pas normal. En tant qu'utilisateur final d'applications, j'entends voir une application utilisant le thème de mon système d'exploitation en priorité, puis des trucs customisés dans un recoin des préférences si c'est indispensable. Si j'ai choisi Clearlooks comme thème par défaut sur Linux, c'est pas pour me retrouver avec Metal (ou Nimbus).

Alors oui, Java est en retard dans les applications desktop, et je comprends parfaitement que les développeurs préfèrent Mono à Java pour l'instant.

---

=> SWT... la t'auras une interface qui utilisera les dll de ton système...

Mouais... Encore une annonce bidon d'un consultant en mal de reconnaissance. Ou guere plus.

Je bosse sous dot net depuis 3 ans maintenant, et pour avoir vu les evolutions comparees en java (qui a baigne les etudes de tout le monde) et en dot net, je qualifierai ce dernier de copie conforme de java, mais en moins portable (parce qu'en realite, un produit dot net n'est reellement portable que sous windows, a moins de se restreindre en n'utilisant que le code compatible msil ET mono).

Il est certain que sous Windows, peut tenir la comparaison avec java. Mais certainement pas sous Linux. Car mono est vraiment loin tres loin d'etre sur pour des professionnels qui souhaiteraient se lancer dans le dot net, et sa maintenance n'est pas des plus aisees.

Enfin, s'il faut bien avouer que les interfaces graphiques de java sont assez moches (sauf si on ajoute le lourdissime substance), que dire de celles du dot net, qui sont en realite inexistantes et completement dependantes du systeme hote? Pour un concepteur, c'est assez inconcevable de savoir que la tete de son logiciel changera suivant la machine de la personne qui l'execute...

Citation:

---

Envoyé par Lau.c

=> SWT... la t'auras une interface qui utilisera les dll de ton système...

---

Donc pour avoir une interface dite système, je suis obligé de faire des manipulations. Ce n'est pas normal. C'est bien toute la teneur de mon message depuis le début.

Soit. Je viens en outre de penser à autre chose. Il est impossible en java d'utiliser les fonctions de glisser/déposer entre applications. Par exemple ouvrir nautilus, sélectionner quelques fichiers avec la souris et les dropper dans une application Java. Terriblement dommage. Il y a décidément beaucoup de pain sur la planche...

Il semble que ce soit possible avec SWT sous Windows (test de copi/collage dans Eclipse réussi), mais malgré tout rien dans la JVM par défaut.

Terriblement dommage ?... juste que les gens lisent pas la doc. S'il y a du pain sur la planche, c'est surtout pour leur apprendre ça.

Enfin bon on va pas en faire un plat, j'imagine que dans le milieu de mono il y a le même genre de problèmes.

Cela ne fonctionne pas, doc ou pas doc. (Sous Windows, oui, sous Linux Gnome oui, sous Linux KDE non.)