Discussion :

[DonQuiche]

Bonjour.

Je développe principalement en C# et je ne peux que constater la médiocrité des solutions à notre disposition, qu'il s'agisse de Winforms ou de WPF, pour réaliser des UI avec les critères suivants :
* Développement Windows.
* Une UI rapide. Rapide, bon sang ! Plutôt genre "animons ces vingt images à 60 ips" que "ça rame quand on élargit le panneau de gauche avec trois boîtes de texte".
* Une UI riche et moderne : animations, contrôles personnalisés, personnalisation extrême de l'apparence.
* Un développement propre : un développement objet, quelques paradigmes clairs, déployés et réutilisés partout dans le framework de façon cohérente, conçus pour faciliter les bonnes pratiques habituelles : séparation des responsabilités, réutilisation du code, etc.
* La productivité doit être raisonnablement bonne et les scénarios simples doivent être simples à implémenter. Un bon outil pour le design serait un plus.
* Une techno mâture, prête à l'emploi, sans lacunes évidentes, ne nécessitant pas de l'utilisateur qu'il finisse les 10% manquants du framework ou utilise des biblios pour ce faire.

Quelqu'un connaîtrait-il une technologie répondant à ces besoins ? Je pense notamment à Qt mais je ne connais pas assez ce dernier. Le langage ou la technologie importe peu : d'autres considérations entreront bien sûr en ligne de compte mais nous sommes prêts à tout envisager si le jeu en vaut la chandelle.

[ovh]

Il y a Qt effectivement, sinon il y a aussi wxWidgets qui est une lib initialement en C++ mais qui a été portée en Python et d'autres langages. Les contrôles affichés sous Windows adoptent le look natif, et la lib va bien au-delà de la création d'UI (couche réseau, base de données, utilitaires, etc.).

[DonQuiche]

Bonjour et merci pour la réponse. Malheureusement, de ce que j'en sais (je me trompe peut-être), wxWidgets est une biblio d'ancienne génération peu adaptée à la création d'UI riches : si l'on désire personnaliser l'apparence d'un bouton (en-dehors d'un simple choix de couleurs), la seule possibilité est de réécrire tout le code de rendu. Qui plus est, puisqu'il semble s'appuyer sur les composants standard, j'imagine que toutes les limites de ces derniers s'y retrouvent (support de la transparence, etc). Connaissant mal ce produit je n'ai pas de certitudes mais il me semble qu'il ne présente aucun avantage par rapport à une solution dotnet + WinForms (hormis la rapidité du C++ mais dotnet + Winforms ne présente pas de problèmes à ce niveau là).

[Luckyluke34]

Bonjour,

Malheureusement j'ai l'impression que tu cherches un mouton à 5 pattes...

Concernant la médiocrité de WPF je te trouve un peu dur. Sur les perfs, c'est sûr que c'est plus lent que du C++ mais sur des machines récentes je n'ai rien remarqué de catastrophique. Au niveau du paradigme je suis d'accord que c'est pas encore ça (il y a des recueils d'outils, frameworks et bonne pratiques style Prism mais qui font assez mal à la tête). Peut-être s'en tenir à du MVVM avec des frameworks comme Caliburn ou MVVM Lite ?
Par ailleurs on peut se poser la question de savoir si une techno est censée promouvoir 1 seul pattern de conception ou si elle doit laisser au développeur le choix de déterminer ses couches et de séparer les responsabilités comme il l'entend...

Pour moi WPF est encore la solution qui satisfait le plus tes (nombreux) critères.

[davcha]

html5 ?

Bon, tu fais surement des clients lourds, mais... Vu qu'on en est à parler d'ui riche, moderne, tout ça... Et qu'on est dans le forum débat...

[ovh]

html5 ?

Bon, tu fais surement des clients lourds, mais... Vu qu'on en est à parler d'ui riche, moderne, tout ça... Et qu'on est dans le forum débat...

Héhé... http://www.developpez.net/forums/d10...tions-lourdes/

[souviron34]

Si l'exigence n'était pas Windows,

si l'on désire personnaliser l'apparence d'un bouton (en-dehors d'un simple choix de couleurs)

le meilleur outil pour ça est Motif (ou openmotif / lesstiff)(pratiquement toutes les propriétés sont accessibles facilement)

Sinon Java ne serait pas correct ? Je n'ai pas regardé de près, mais je soupçonne que ça doit être relativement facile de overrider les paramètres par défaut..

[DonQuiche]

Merci à tous pour vos réponses.

@Luckyluke34
Oui, WPF est encore le meilleur des choix et le terme médiocre est peut-être un peu fort. Mais enfin, tout de même... Entre les problèmes de tearing sur XP, voire sous Vista/7 sans Aero, les fontes encore floues dans certains cas, et les problèmes de perfs qui surviennent vite (une simple saccade dans une animation suffit à ruiner l'effort investi dans celle-ci) il est selon moi difficile de produire une appli satisfaisante sur au moins l'essentiel des plateformes... Un concurrent de Picasa qui serait écrit en WPF, pour citer un exemple connu, ferait pâle figure à côté de l'original ; un comble pour une techno destinée aux UI riches !

Et côté propreté et productivité... SI on songe à tous les vices de conception (verbosité, pattern command nécessaire pour MVVM mais inutilisables 90% du temps sans outils persos - 5 lignes pour faire un binding, youhou), et la très faible réutilisabilité du code (just copy/paste the style™)...

Alors est-ce que je cherche un mouton à cinq pattes ? Je ne sais pas. Je crois que Qt offre une stylisation via css, il faudrait que je voie en détail ce que ça donne. Et il se pourrait qu'il y ait ailleurs, côté Java par exemple, des API dont j'ignore l'existence ou dont je sous-estime les possibilités. Mais en 2011 il n'est tout de même pas impossible qu'il y ait mieux que l'abominable WPF.

@davcha
Html5, oui, j'y ai pensé. Mais outre que html+js n'est vraiment pas la première technologie qui me vienne à l'esprit quand je songe "cohérence" et "propreté" , les performances sont trop souvent faiblardes. Enfin, point rédhibitoire, html5 est bien trop peu supporté encore.

Sinon, pour rebondir sur ce que tu disais, je ne doute pas JS et html sont amenés à se répandre comme une traînée de poudre sur le desktop vu le réservoir de compétences dans ce domaines. Mais je ne doute pas non plus que ce sera pour le pire plus que pour le meilleur.

@souviron34
De mes quelques souvenirs (lointains), je doute que Motif et ses vingt ans d'âge soit une réponse adaptée quand bien même il n'y aurait pas l'exigence du développement Windows : il est possible de faire une UI riche et moderne avec à peu près n'importe quelle techno, le problème est de la réaliser en un temps raisonnable : si 90% du code UI est consacré à réaliser des "effets" (animations, variations non-standard des contrôles habituels, etc), la techno n'est de toute évidence pas adaptée.

[Luckyluke34]

Un concurrent de Picasa qui serait écrit en WPF, pour citer un exemple connu, ferait pâle figure à côté de l'original ; un comble pour une techno destinée aux UI riches !

Picasa a très certainement été développé en C++ donc tu peux laisser tomber tout ce qui est "bon outil pour le design", "ne nécessitant pas de l'utilisateur qu'il finisse les 10% manquants du framework", "paradigmes clairs, déployés et réutilisés partout dans le framework"... Alors oui Picasa est une appli performante, fluide et attrayante graphiquement mais comme beaucoup de logiciels de traitement d'image actuels a été écrite dans un langage non managé et assez bas niveau ce qui fait que tu te coupes d'énormément d'éléments de productivité et de confort de dev apportés par les technos de dernière génération. On revient au fait qu'on ne peut à mon avis pour l'instant pas avoir le beurre et l'argent du beurre.

la très faible réutilisabilité du code (just copy/paste the style™)...

Heu justement tout est fait pour être réutilisable en WPF : styles, thèmes, composants graphiques... Je ne vois pas ce qui te permet de faire une telle généralisation. Et les outils de la suite Expression comme Blend augmentent encore un peu plus la productivité à ce niveau.

[DonQuiche]

@Luckyluke
Sur le premier point, je ne suis pas d'accord : oui, Picasa a été développé simplement avec de grosses gouttes de sueurs et beaucoup d'effort faute d'une API adaptée. Mais je ne vois pas en quoi cela voudrait dire qu'une telle API ne pourrait pas exister. Les lacunes de WPF n'ont rien à voir avec le fait que C# est un langage managé, elles ont tout à voir avec de nombreuses fautes de design et l'absence d'efforts pour remettre en question certains des choix fondamentaux avant la sortie de la première version, probablement du fait du contexte dans lequel est née cette techno (Longhorn). Rien n'empêcherait d'avoir une techno comparable mais beaucoup plus aboutie et solide (Jupiter ?).

Sur la réutilisabilité, je vais te donner un exemple : crée un style particulier pour un bouton avec ton propre ControlTemplate. Pour achever un style "bleu", tu as alors besoin de trois pinceaux (brushes) avec diverses nuances et gradients de bleu. Faute d'avoir de telles propriétés sur le bouton, tu les codes directement dans ton style. Et le jour où ton designer te dit que, là, ce serait bien de peindre tel bouton en vert pour le faire ressortir, tu n'as plus qu'à recopier tout ton style (30 à 100 lignes de code). Une comparaison avec le css est éloquente : on n'aurait eu qu'à écrire trois lignes. Bien sûr il y a douze façons de contourner le problème mais aucune n'est vraiment meilleure et, dans certains cas, cela tourne au ridicule.

[kdmbella]

s'il s'agissait du web je t'aurais proposer sans hésiter les bibliothèques Web 2.0 comme YUI, Exjs ,Dhtmlx ... c'est assez léger personnalisa réutilisable et beau en plus

[epeios]

J'ai écris quelques interfaces utilisateurs, mais ce n'est de loin pas ma principale activité, donc je ne suis pas un spécialiste en ce domaine. J'espère donc ne pas être complètement à coté de la plaque en évoquant l'outil que j'utilise, à savoir XULRunner.

Pour faire simple, XULRunner est un environnement d'exécution logiciel implémentant Gecko, qui est la technologie au cœur d'applications comme Firefox (le célèbre navigateur WEB) ou encore Thunderbird.

Pour rependre les différents points :

* Développement Windows

Windows, Linux, Mac OS : ça fonctionne sans problèmes (j'en ai fait l'expérience).

* Une UI rapide. Rapide, bon sang ! Plutôt genre "animons ces vingt images à 60 ips" que "ça rame quand on élargit le panneau de gauche avec trois boîtes de texte".

Jamais eu à m'en plaindre coté vitesse ; ceci dit, je n'ai jamais eu non plus à intégrer d'animations dans les interfaces que j'ai développées ...

* Une UI riche et moderne : animations, contrôles personnalisés, personnalisation extrême de l'apparence.

Comme dit, pour les animations, je ne sais pas, mais en ce qui concerne la personnalisation, il n'y a qu'à voir tout ce que l'on peut faire avec Firefox. Concrètement, pour ce qui est de l'apparence, on dispose, entre autres, de toute l'artillerie CSS.

* Un développement propre : un développement objet, quelques paradigmes clairs, déployés et réutilisés partout dans le framework de façon cohérente, conçus pour faciliter les bonnes pratiques habituelles : séparation des responsabilités, réutilisation du code, etc.

Le langage le plus couramment utilise avec ce framework est Javascript. Personnellement, j'utilise C++, et je n'ai pas eu à modifier mes habitudes pour développer pour XULRunner.

* La productivité doit être raisonnablement bonne et les scénarios simples doivent être simples à implémenter. Un bon outil pour le design serait un plus.

A l'époque où j'ai commencé à utiliser XULRunner, le principal frein à la productivité était le manque de documentation. Maintenant, j'ai assez d'expérience avec cet outil pour pouvoir me passer de documentation, donc je ne sais pas si les choses se sont améliorées. Pour ce qui est d'un outil de design, je ne saurais dire s'il en existe, n'ayant jamais eu besoin d'un tel outil.

* Une techno mâture, prête à l'emploi, sans lacunes évidentes, ne nécessitant pas de l'utilisateur qu'il finisse les 10% manquants du framework ou utilise des biblios pour ce faire.

Alors là, c'est l'un des points forts de XULRunner. Vu les liens très étroits qui l'unissent à Firefox, il en hérite toutes les qualités (et défauts). Je pense que l'on peut considérer Firefox comme mature, et, concernant les autres points, je pense que Firefox y correspond également, vu le nombre de modules disponibles ...

Quelques remarques cependant. Comme indiqué plus haut, le langage habituellement utilisé dans le cadre de XULRunner (comme pour le développement de modules destinés à Firefox) est Javascript. Non seulement j'utilise C++, mais en plus je ne l'utilise pas de la manière usuelle.
Normalement, on utilise C++ pour, en quelques sorte, étendre les fonctionnalités accessibles en Javascript, c'est-à-dire que les fonctions C++ sont normalement appelées à partir de Javascript (un mécanisme est prévu pour créer le 'wrapper' Javascript pour chaque chaque fonction 'C++'). Personnellement, j'ai fait le choix de tout contrôler à partir de mon composant C++. Concrètement, au chargement de chaque partie de l'interface, une fonction Javascript est lancée, qui n'est qu'un 'wrapper' vers une fonctions C++ de mon cru, déclarant tous les constituants de l'interface auprès de mon composants C++. A partir de là, je mets en place, toujours en C++, les différents gestionnaires d'évènements qui vont bien, et je peux ainsi gérer toute l'interface utilisateur en C++, sans n'avoir plus à écrire une seule ligne de Javascript. C'est pour cela que j'ai écrit plus haut que je n'ai pas eu à changer mes habitudes de codage, du fait que je m'affranchis de toutes les éventuelles contraintes auxquels on serait soumis si l'on utilise C++ de manière plus 'classique', voir si l'on développe en Javascript ...

[DonQuiche]

Bonjour Epeios et merci beaucoup pour cette réponse très argumentée.

Je dois dire que je n'avais pas songé à XUL. Pour le coup, j'ai pris le temps de me renseigner un peu. Premier constat, XUL offre l'accès à la fois à tout l'équipement html5 et à ses propres widgets, taillés pour le client desktop, ainsi qu'à de meilleurs structures de mise en page. Ça semblait donc bien parti.

Second constat, ça reste une API limitée à laquelle il faudrait ajouter de boulot : si leurs widgets offrent une certaine souplesse (possibilité d'intégrer n'importe quel markup en leur sein), les possibilités de personnalisation restent limitées puisqu'un bouton est prévu pour avoir une bordure extérieure, une bordure intérieur, et le contenu. Si l'on souhaite complètement en changer l'apparence et ajouter par exemple un glow animé, la stylisation CSS ne nous emmènera pas bien loin et il faudra coder tous ces comportements et modifier les markups à la volée, etc. Par rapport à WPF, le rapport de travail nécessaire sur l'UI serait sans doute de 1:3 à 1:5, Miguel de Icaza nous avait quand même sorti un gros troll en comparant les deux à l'époque. Sans parler des limites incontournables qui nous obligeront, pour certains effets, à tricher avec des graphiques pré-rendus et re-rendus pour chaque taille de contrôle, imposant au passage des limites contraignantes, comme ce serait le cas avec une solution html.

Cela dit, WPF posant malheureusement beaucoup de problèmes de performances, tearing, flous & co, ses avantages sont de toute façon ruinés et c'est la raison pour laquelle nous sommes prêts à envisager des API plus pauvres. Maintenant reste à savoir si cette solution offre des avantages par rapport à Gtk ou Titanium, ce qu'elle vaut par exemple dans le cas de structures complexes à animer (je crains que les performances ne soient pas meilleures qu'avec du html sous Firefox) et son support dans le futur. Enfin, l'UI même de Firefox n'est pas le meilleur argument pour elle.

Cela dit je prendrai peut-être quand même le temps d'y consacrer quelques heures, pour voir, même si je suis assez sceptique.

[ovh]

Juste pour info, pour quel genre d'application dois-tu concevoir une interface graphique si riche (et donc inhabituelle si on comprend bien tes posts) ?

[DonQuiche]

Sans rentrer dans les détails, c'est une application professionnelle à destination d'utilisateurs pointus, exigeants et pressés, plutôt à l'aise avec l'info mais sans plus, pour lesquels les outils sont très importants (domaine à forte innovation technologique) mais ne doivent surtout pas se mettre en travers de leur route (notre appli n'est qu'un outil parmi les très nombreux qu'ils ont à manier). Parmi les besoins de l'application, l'examen d'un dossier peut impliquer la recherche et le passage en revue de nombreux documents, images et vidéos dans un très court laps de temps.

Cela dit, je ne crois pas que nos besoins soient inhabituels. Légèrement avant-gardistes, peut-être, du moins dans un monde desktop plutôt conservateur.

Accessoirement, dans la mesure où il y a une pression vers ce genre d'UI, il s'agit aussi de rechercher la meilleure plateforme sur laquelle nous reposer pour des projets futurs.

[Mat.M]

* Développement Windows.
* Une UI rapide. Rapide, bon sang ! Plutôt genre "animons ces vingt images à 60 ips" que "ça rame quand on élargit le panneau de gauche avec trois boîtes de texte".
* Une UI riche et moderne : animations, contrôles personnalisés, personnalisation extrême de l'apparence.

eh ben soit VC++ et MFC soit win32...soit Qt et du bon multithreading utilisé à bon escient...

Plutôt genre "animons ces vingt images à 60 ips" que "ça rame quand on élargit le panneau de gauche avec trois boîtes de texte".
.

je ne connais pas WPF je suis assez allergique à tout ce qui est .NET
il est évident que si tu charges des system.drawing.pictures sur une Form avec des tas de contrôles et que le CLR regarde si tu n'as pas des system.exceptions toutes les x ms , que le Garbbage Collector récupère toute la mémoire allouée non désallouée ça risque de ramer

[Mat.M]

P Alors oui Picasa est une appli performante, fluide et attrayante graphiquement mais comme beaucoup de logiciels de traitement d'image actuels a été écrite dans un langage non managé et assez bas niveau ce qui fait que tu te coupes d'énormément d'éléments de productivité et de confort de dev apportés par les technos de dernière génération.

ah bon ?
D'après ce que je comprends de ce qui est écrit alors le C++ est un langage totalement improductif...
faudrait aller dire cela à l'entreprise qui m'avait embauché dernièrement qui fait de l'imagerie médicale.
90% du développement logiciel se fait en C++ allez je suis gentil 70-80 pour cent au minimum

[Mat.M]

Merci à tous pour vos réponses.

@Luckyluke34
Un concurrent de Picasa qui serait écrit en WPF, pour citer un exemple connu, ferait pâle figure à côté de l'original ; un comble pour une techno destinée aux UI riches !

c'est la grosse différence entre les logiciels "pros" développés en C++ où on peut accéder à la quintesscence de la machine et du système et les projets développés avec des langages de "préfabriqué" genre Java ou .NET
( ça y est au moins 10 "j'aime pas ")
Tu comprendras pourquoi chez Microsoft (voire chez Google) ils développent toujours la suite Ms Office ( Word, Access...) avec Visual C++
Je suis persuadé que dans Ms-Office t'a même pas une ligne de code en .NET...
bon c'est pas un éternel troll .NET vs C++

Alors est-ce que je cherche un mouton à cinq pattes ? Je ne sais pas. Je crois que Qt offre une stylisation via css, il faudrait que je voie en détail ce que ça donne. Et il se pourrait qu'il y ait ailleurs, côté Java par exemple, des API dont j'ignore l'existence ou dont je sous-estime les possibilités. Mais en 2011 il n'est tout de même pas impossible qu'il y ait mieux que l'abominable WPF.

je pense que Qt est une excellente alternative à WPF.
Si tu programmes de manière optimale tu vas avoir des résultats explosifs...
Qt c'est utilisé dans des systèmes de plateformes pétrolières norvégiennes ( eh oui Troll Tech c'est des norvégiens ) ; il faut des performances temps réel... donc Qt te satisfera pleinement ou sinon MFC voire Direct 3D..

Cela dit, WPF posant malheureusement beaucoup de problèmes de performances, tearing, flous & co, ses avantages sont de toute façon ruinés et c'est la raison pour laquelle nous sommes prêts à envisager des API plus pauvres.

c'est normal que tu obtiennes des performances médiocres...avec WPF tu ne contrôles absolument rien même pas les allocations mémoires, l'appel du traitement en lot du tracé graphique..
pour les problèmes de déchirement d'image ( tearing) c'est parce que tu ne peux pas accèder directement aux performances du matériel étant donné que .NET c'est du "managed code"..
en ayant un accès natif directement au matériel comme en C++ tu peux optimiser les performances...
c'est certain qu'avec WPF tu as une forte abstraction des possibilités de programmation c'est plus facile que de se casser la tête avec le GDI et SelectObject, CreateCompatibleBitmap et compagnie.
Mais WPF c'est une boite noire tu ne contrôles rien encore une fois.
WPF c'est bien pour les petits développements pour les petites représentations graphiques pas pour les projets lourds...

* Un développement propre : un développement objet, quelques paradigmes clairs, déployés et réutilisés partout dans le framework de façon cohérente, conçus pour faciliter les bonnes pratiques habituelles : séparation des responsabilités, réutilisation du code, etc.

je ne connais pas Qt je connais MFC et win32.
Mais Qt je pense est très bien foutu c'est toute une hierarchie de classes..
si tu as besoin des fonctionnalités d'un composant tu crées des nouvelles classes qui héritent du framework etc...

[el_slapper]

L'éternel débat entre productivité du programmeur et productivité de l'outil..... En bref, il faut choisir entre un langage rapide à développer mais qui présente des soucis de performances sur des applis lourdes, et un langage plus long à développer, mais qui donne au programmeur le contrôle nécéssaire pour aller vite.

Il n'y a pas de "bon" ou de "mauvais" outil, il n'y a que des outils, adaptés ou pas, à telle ou telle problématique. Après, dans ce cas précis, le managé semble avoir trouvé ses limites. Ca n'en fait pas un outil toujours mauvais. A mon sens, il vaut mieux avoir plus d'outils dans la boite à outils, et, devant chaque problème, se poser la question "quel est l'outil le plus adapté à ce problème précis?"

[Bluedeep]

WPF c'est bien pour les petits développements pour les petites représentations graphiques pas pour les projets lourds...

Cette phrase (entre autre) est totalement ridicule.

Il y a assez peu de corrélation (voire aucune) entre la lourdeur d'un projet (complexité fonctionnelle) et ses besoins en interfaces graphiques à haute performance. (dans les faits, je dirais presque que c'est le contraire).