Client lourd: WPF or not WPF?
mathias kluba
Vincent Bourdon
Envoyé de mon iPhone
Gauthier Segay
my two cents, /!\ je n'ai pas d'expérience sous WPF /!\, et mon
expérience winform n'est pas très étendue, mais je comprends bien les
pitfalls du mode de développement de 90% des application développées à
l'aide de designers winform
* ou la logique UI n'est pas du tout testable
* où la logique UI est mixée avec la logique métier et la plomberie
qui vient avec
* où les concepts UI ne sont pas du tout conceptualisés et factorisés
bref ce qui fini par rendre le code difficile à evoluer, je pense
qu'avec ce que tu décris mettre en oeuvre tu t'épargnes ces ecceuils
> au lieu d'un look & feel natif, il me fallait customizer le mien.
je me demande pourquoi resharper à décidé de refactoriser des écrans
en utilisant WPF, le rendu même si il reste proche du l&f natif est
pour moi dégradé, pareil pour VS2010, pareil pour les autres
applications desktop utilisant WPF.
WPF s'applique mal à ces besoins à mon goût. C'est bien pour le eye
candy / consumer line, c'est sans doute bien pour les développeurs
aussi, mais pour l'utilisateur qui doit faire tourner ses applications
de manière "productiviste" ça ne cadre pas très bien.
> on me dit que ça ramme sur les PC
>> si tu as une machine qui as 10 ans peut être moins
mon laptop (core i7 2.poussiere ghz) et carte graphique intégré intel
(les geeks huent) est très très poussif quand j'utilise nh profiler,
mais il fonctionne très bien avec monodevelop qui me semble beaucoup
plus lourd, je ne parle même pas des applications natives (hors
sujet), vs2010 tourne raisonablement mais je regrette qu'ils se soient
sentis obligés de changer une partie de l'UI (sans doute pour prouver
que WPF c'est la voie) plutôt que de rester en natif de ce côté et de
focaliser sur les vrai problèmes de l'outil.
WPF ça rame, si ça vient uniquement de la carte vidéo cela m'inquiète
car les perfs 3d/2d de la carte de mon laptop font certainement palir
beaucoup de gpu d'il y'a 10 ou 5 ans, je n'ai pas de problèmes pour
utiliser des programmes graphiques basés sur d'autre API, je pense
qu'en environnement de travail tu ne dispose pas nécéssairement de
beaucoup mieux que le chipset intégré, et je pense que WPF est
gourmand même avec une bonne carte graphique.
> autant faire une application Winform avec un WebBrowser intégré
c'est une piste qui est intéressante sous plusieurs aspects, notament
la portabilité de l'ui vers d'autres plateformes, ainsi que le levier
des outils qui sont à priori bien "connus" pour permettre
d'implémenter des bonnes pratiques de séparation UI, ceci dit je doute
que tu puisse rivaliser avec du winform (ou WPF) spécifique en terme
de performance et de facilité de maximiser l'expérience utilisateur
sans trop d'efforts (ou alors tu es un killer en sencha ou autre
frameworks js lourds). Il y'a dart aussi ;)
> je me demande si ça vaut le coup que je me mette au WPF maintenant
>> Pour le design métro wfp est la à 100% donc c'est pas encore mort.
comme tout ce qui à été un jour exposé par MS dans windows desktop,
WPF, Winform, MFC, l'api en C resteront là pour "toujours", ils ne
semblent pas être prêt a suivre la voie d'Apple qui (si je comprends
bien l'état actuel des choses) ne permet plus de faire tourner des
exécutables datant de system6,7,8,9 sous OSX dans ses dernières
versions.
> mais j'ai développé un mini framework "MVC"
c'est parfaitement gérable selon moi, il faut passer du temps a
conceptualiser les besoins et la surface d'intéraction entre ton code
et le framework UI, si tu veux un découplage propre, je ne vois pas
comment cela peut être fait à moindre cout avec d'autres frameworks
(je doute que le MVVM utilisé par les applications WPF soit vraiment
framework agnostic, c'est juste que ces patterns ont commencé à
emerger dans la communauté avec l'excitation qu'a présenté WPF).
un des points faibles de winforms, c'est l'absence d'un framework
déclaratif semblable au XAML/Glade, je pense qu'il est possible de
hacker mais en suivant sa propre voie (qui ne vaut certainement pas
l'effort pour une application)
> Est-ce que je dois vraiment jeter à la poubelle les Winforms et me plonger corps et âme dans WPF?
> Quel sont vos retour d'expérience?
> Si le modèle imposé par Microsoft du "tout Databinding" n'est plus, est-ce que leur nouveau modèle "MVVM" est vraiment le meilleur, ou connaissez-vous des alternatives?
j'espère que mes points de vues (non WPF informed) ne me font pas
passer pour un detracteur de WPF (je suis d'accord que le framework
est mieux pensé / plus moderne que winform, c'est indéniable), et
j'attends avidement que des pros du WPF nous fassent à leur tour part
de leur expérience.
le databinding, je pense qu'il n'y à pas de solution miracle, les
composants exposent tous une API qui est un peu trop bas niveau à mon
gout, il est bon d'avoir une conceptualisation découplage de sa
déclaration pour permettre au code d'être vraiment maintenable par la
suite, je doute que WPF soit une solution miraculeuse bien que cela
est sans doute un peu mieux par défaut qu'avec winforms (mais ça
dépend énormément des controles).
Je pense que Aspectize se frotte les mains en regardant ce thread ;)
2012/2/3 mathias kluba <mathia...@gmail.com>:
Radwane
vote est pour WPF)... Il y a effectivement une belle marche pour
passer de Winform à WPF, mais moi j'aime tellement pas le mode de
développement Winform que je suis peut être pas assez objectif (il y a
quelques raisons qui ont été cité par Segay).
Pour la performance à moins de faire beaucoup d'animation ou avoir
vraiment beaucoup de donnée, c'est pas très compliqué d'avoir une
application réactive.
Pour la pérennité de la techno, les interfaces métro reprennent le
background XAML de WPF, donc se que t'apprendra pour WPF (qui sera
toujours compatible Win8) sera valable sur WinRT.
Ce n'est certainement pas une technologie ultime mais y a quand même
une sacrée avancée par rapport à Winform, en terme de testabilité,
flexibilité...
Pascal
Concernant l'architecture MVC avec Winforms, j'avais fait quelques
recherches il y a quelques temps et trouvé pas mal d'informations sur
Stackoverflow.
Notamment :
http://stackoverflow.com/questions/654722/implementing-mvc-with-windows-forms
http://stackoverflow.com/questions/827692/is-mvc-popular-with-winform
D'après ce que j'avais lu, c'était plutôt MVP qui était utilisé.
Ceci dit, je suis dans le même cas que toi en terme d'expérience
Winforms/WPF, mais comme le dit Radwane, ce sera du WPF dans WinRT ou
en tout cas, quelque chose qui y ressemble. Donc, pour moi, il n'y a
pas à hésiter et il faut faire le pas vers WPF.
Rui Carvalho
Simon Mourier
Geoffrey DANIEL
Geoffrey DANIEL
Frédéric Fadel
Rui Carvalho
Rui.
Mathias Kluba
Simon Mourier
Nieve
seul de trouver le XAML un crime contre l'humanité ou au moins contre
les yeux?
Perso, tout comme je préfère albacore sur MSBuild, structure map sur
spring (en tant que IoC) ou Fluent NH sur le hbm, je préfère d’éviter
XAML
On Feb 15, 1:53 pm, Mathias Kluba <mathias.kl...@gmail.com> wrote:
> Hehe, en tout cas je vois que je ne suis pas le seul à hésiter avec WPF.
>
> Du coup je me dit:
> - soit WPF est encore mal connu et ça mérite une session ALT.Net (mais avec des exemples costauds, pas des hello world)
> - soit WPF n'est pas mature et il manque quelque chose pour être plus productif (mais quoi?)
>
> Le 15 févr. 2012 à 11:49, Rui Carvalho <r...@rui.fr> a écrit :
>
>
>
>
>
>
>
> > si Fredy commence à ressortir les .hta, c'est le début de la fin ;-)
>
> > (que j'aimais beaucoup à l'époque soit dit en passant)
>
> > Rui.
>
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> > * Mob ›› +33610047040
> > * Blog (fr) ››http://www.rui.fr
> > * Home ››http://www.artofnet.com
> > * Twitter ›› @rhwy
> > * G+ ››https://plus.google.com/117394683250045815434
> > * LinkedIn ››http://fr.linkedin.com/in/ruifr
>
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>
> > je ne voulais pas participer dans ce thread, parce que je trouve que WPF c'est trop de souffrance pour... mais puisque Simon s'y met, je ne peux qu'approuver.
>
> > sinon au début du thread il était question, d'embarquer un serveur web pour faire du web en mono-poste! si le but c'est du faire du HTML et du CSS pour l'IHM il y a aussi et toujours les .hta
>
> > à+,
>
> > Fredy
>
>
> > J'insiste sur le coté "de gestion".
>
> > Evidemment, si je veux écrire un jeu, une application vectorielle, un designer graphique sur lequel je veux zoomer, sur lequel je veux afficher des centaines de boîtes qui se chevauchent, alors WPF sera mon choix car il est infiniment plus performant graphiquement (quand on l'utilise bien).
>
> > Les Winforms imposent une structure, et un look standard (qui est celui de Windows en fait). Ok ce n'est pas toujours hyper beau et sexy, ça ne fait pas Web 3.0, mais le client s'en fiche souvent royalement, et on peut toujours agrémenter une appli Winforms (skins tierce partie par exemple, même si c'est souvent lent), ou intégrer certains visuels (interop WPF) si on le souhaite. Designer des forms ou des controls, c'est très rapide, on peut aussi designer des forms qui dérivent d'autres forms, etc... tout simplement parce que c'est une technologie qui ne mixe pas l'UI et le code.
>
> > En WPF les outils sont pourris. Il faut utiliser Blend que personne ou presque ne connait sur la place de Paris - oui on est en France :-), un graphiste professionnel, un ergonome, etc. pour arriver à quelque chose qui montre un intêret justement au delà d'une application Winforms.
>
> > En WPF, à l'origine, il n'y avait même pas de grille! Ca montre que l'esprit n'était pas à l'informatique de gestion. Une item de Treeview n'a même pas de notion d'icône graphique built-in. Soyons sérieux.
>
> > Attention, ne nous trompons pas, je trouve WPF génial, astucieux, extraordinairement élégant, mais très inapproprié aux applications de gestion en général, même si on peut y arriver en poussant très fort.
>
> > 2012/2/3 Rui Carvalho <r...@rui.fr>
> > Hello,
>
> > Cela fait très très longtemps que je n'ai pas eu l'obligation dans le cadre du taf de sortir du cadre web, mais le fait est que même si j'ai commencé à regarder wpf au moment des premières betas, quand je dois me faire une petite appli quick and dirty desktop pour rendre un service, comme Mathias, je laisse tomber et fait un windforms qui me donne envie de gerber en termes de design mais qui a l'avantage de ne pas être prise de tête.
>
> > Mais c'est mal, il faudrait prendre le temps de s'y mettre au moins pour le minimum car beaucoup de choses ne sont pas si mal que ça et c'est comme dit Vincent plus de la méconnaissance qu'autre chose.
>
> > Ceci étant:
> > - il y a des proj sur codeplex avec des wpf controls qui t'évitent de faire un min de custom
> > - pourquoi ne pas faire ça en silverlight (arg, je l'ai dit) ? depuis les dernières versions, tu peux faire tourner ton SL en standalone sur le bureau avec un bouzin qui est plus pratique à prendre en main, moins lourd et suffisant pour presque tous les besoins (vis a vis de wpf)
> > - je suis assez partisan du petit launcher webserver+html5. Je suis persuadé que l'on se tourne vers ce genre de chose d'une manière globale -> Html5 permet de faire des applis completes et déconnectées, cela fonctionne partout et le seul truc qui change d'une plateforme à une autre c'est le launcher.
>
> > Pour les techdays, de ce que je connais:
> > - Thomas sur les news asp.net 4.5
> > - Yann s'occupe de tout ce qui est magie noire et trucs bizarres (Hadoop sur azure ;-)
> > - je fais la pres sur les bonnes pratiques mvc.
>
> > ce serait pas mal de compléter la liste, si jamais il y en a d'autres pour pouvoir communiquer dessus ;-)
>
> > +
>
> > Rui.
>
> > ps: On se croise là bas Vincent?
>
>
> > Beaucoup de questions d'un coup!
>
> > Je comprend ton sentiment d'être perdu ou déconcerté avec wpf.
> > Maintenant c'est juste une méconnaissance de la techno et des produits comme Blend par exemple. Donc le truc c'est que si tu t'y intéresse jamais bas tu maîtrisera jamais ;)
>
> > Concernant la lenteur sur les machines actuelles ça tourne si tu as une machine qui as 10 ans peut être moins C'est sur.
>
> > Pour le design métro wfp est la à 100% donc c'est pas encore mort.
>
> > Moi jai une question. Y a des speakers aux techdays parmis vous ?
>
> > Vincent
>
> > Envoyé de mon iPhone
>
>
> >> Hello tout le monde!
>
> >> Je suis face à un dilemme et j'ai besoin de l'avis d'expert en la matière.
> >> J'ai commencé à faire du Winform à mes débuts, mais ça fait maintenant plus de 3 ans que je ne fais que du Web (ASP.Net, ASP.Net MVC, JQuery, etc).
>
> >> Aujourd'hui, j'ai besoin de faire une petite application "sans installation ni serveur", donc un client standalone lourd.
>
> >> J'ai par instinct et par habitude commencé avec une application Winform, car c'est idéal pour faire des maquettes.
> >> Hop hop hop, un peut de Databinding, et voila, j'ai un embryon d'application...
>
> >> Puis il fallait vraiment la coder, et ajouter des fonctionnalités, et le code tout pourris ne le permettait pas.
> >> C'est la que je me suis dit: "MVVM bien sûr! je refais tout en WPF!"
> >> Mais ça m'a vite découragé.
> >> Premièrement, à cause de mon inexpérience bien évidement.
> >> Ensuite, après avoir reproduit la même interface que celle en Winform, je n'avais pas du tout le même look & feel, et au lieu d'un look & feel natif, il me fallait customizer le mien.
> >> "Bizarre venant de quelqu'un qui fait des interfaces Web avec du CSS tous les jours" me diriez-vous.
> >> Mais la, je voulais vraiment que l'application ai un look standard sans aucun effort, ce qui n'était pas le cas.
>
> >> Ensuite, cette liberté de faire les interfaces "comme on veut" a un coût. Par exemple, j'avais l'habitude en Winform de configurer très très rapidement la Treeview, mais en WPF je ne trouve quasiment pas d'option.
Vincent Bourdon
d'une mauvaise utilisation des produits.
1) les grilles c'est mal ;p
2) le xaml tu ne le lit pas pas tu utilise blend et donc y a des outils
@+ Vincent b.
Envoyé de mon iPhone
Geoffrey DANIEL
Geoffrey DANIEL
in...@softfluent.com
Cela fait deux fois que je vois passer un "c'est mal" dans l'échange
(ici concernant les grilles, précédemment concernant les Winforms).
Perso, pour moi cette notion de bien ou de mal n'a pas de sens en
développement, surtout si on n'explique pas le problème que cela pose
dans un cas précis.
Concernant les Winforms, lorsque j'étais Microsoft, je me souviens
avoir accompagné des éditeurs de logiciels à Corp où le discours tenu
était l'urgence de migrer à WPF : "Winforms aura disparu dans 2 ans"
nous disaient les grands gourous de la division Developer (Vic
Gundotra est depuis parti chez Google). C'était en 2003. Ben de fait,
non, Winforms a encore toute sa place, surtout que le choix n'a rien
de binaire, on peut très bien comme l disait Simon héberger du WPF
dans du Winforms si on a besoin de vectoriel. L'important est
d'utiliser la techno qui convient aux besoins et contraintes que l'on
a.
Concernant les grilles, je comprends encore moins. Pour certaines
applications de gestion, c'est juste totalement illusoire de faire
autrement. La grille est le moyen le plus ergonomique et efficace de
saisir des données en masse. Je vous laisse aller expliquer aux
utilisateurs qui passent leur journée dans ce type d'applications
qu'ils vont devoir faire ligne par ligne. Bon courage !
Geoffrey, même avec un Smiley, je suis curieux de comprendre ce qui te
pousse à dire que c'est mal ? Il est où le problème ?
Mes 2 centimes,
Daniel
On 16 fév, 08:20, Geoffrey DANIEL <neurocyp...@gmail.com> wrote:
> Je rajouterais aussi quelque chose :
>
> 3) avec une bonne configuration de l'indentation du XAML dans VS, le XAML
> se lit beaucoup mieux
>
in...@softfluent.com
c'était mal (quel daube ces Newsgroups Google à lire ;))
Cela ne modifie pas le fond de ma question néanmoins.
>
> 3) avec une bonne configuration de l'indentation du XAML dans VS, le XAML
> se lit beaucoup mieux
>
Nieve
Est ce que tu sépare donc le design du dev? Je suppose que tu bosse
avec un styliste/designer qui utilise blend pendant que le dev
travaille sur le code behind? Ou est ce que ça devient assez commun de
trouver des devs qui font le deux? Si c'est juste pour faire un IHM
tout simple, y a pas vraiment un grand différence; j'ai croyais que
WPF c'était surtout pour créer des 'eye-candy' (qui est plus que
légitime bien entendu), mais peut être c'est juste ma méconnaissance
de cette techno.
On Feb 16, 6:22 am, Vincent Bourdon <evilz...@gmail.com> wrote:
> Je crois surtout que tout ça cela provient d'une méconnaissance et
> d'une mauvaise utilisation des produits.
>
> 1) les grilles c'est mal ;p
> 2) le xaml tu ne le lit pas pas tu utilise blend et donc y a des outils
>
> @+ Vincent b.
>
> Envoyé de mon iPhone
>
>
> read more »
Geoffrey DANIEL
Geoffrey DANIEL
Simon Mourier
Mathias Kluba
d'une part, je pense qu'un langage structurel et hierachique tel que le xml est la meilleur façon de définir des interfaces.
Le html est un xml particulier, glade pour gtk c'est du xml, les nib sous mac c'est du xml, la future version 4 d'eclipse aura ses interfaces decrites en xml.... javafx c'est du... javafx script, et c'est d'ailleurs un échec.
Certes, on a parfois besoin de créer des interfaces dynamiquement, et du coup on le fait par code. Mais pour ce qui est statiques, l'histoire à prouvé l'efficacité du xml.
Ce qui me choque le plus c'est de dire que "blend génère le xaml qu'on ne regarde pas".
Je me suis toujours battue contre les ex-développeur winforms qui généraient le html. Il est préférable pour la maintenance, la lisibilité et la performance de coder "à la main" ces interfaces.
Si le Xaml est un format trop complexe ou trop "bizarre" pour le maitriser à la main, c'est un problème propre au Xaml, pas au xml.
Je suis d'ailleurs d'accord pour dire que ce format (comme le format xml des msbuild) est complètement foireux...
Nieve
(sans succès) à évoquer tout à l'heure... Merci ;)
On Feb 16, 12:04 pm, Mathias Kluba <mathias.kl...@gmail.com> wrote:
> Pour ceux qui disent que le xaml c'est mal:
> d'une part, je pense qu'un langage structurel et hierachique tel que le xml est la meilleur façon de définir des interfaces.
> Le html est un xml particulier, glade pour gtk c'est du xml, les nib sous mac c'est du xml, la future version 4 d'eclipse aura ses interfaces decrites en xml.... javafx c'est du... javafx script, et c'est d'ailleurs un échec.
>
> Certes, on a parfois besoin de créer des interfaces dynamiquement, et du coup on le fait par code. Mais pour ce qui est statiques, l'histoire à prouvé l'efficacité du xml.
>
> Ce qui me choque le plus c'est de dire que "blend génère le xaml qu'on ne regarde pas".
> Je me suis toujours battue contre les ex-développeur winforms qui généraient le html. Il est préférable pour la maintenance, la lisibilité et la performance de coder "à la main" ces interfaces.
> Si le Xaml est un format trop complexe ou trop "bizarre" pour le maitriser à la main, c'est un problème propre au Xaml, pas au xml.
> Je suis d'ailleurs d'accord pour dire que ce format (comme le format xml des msbuild) est complètement foireux...
>
Vincent Bourdon
des gens vont pas apprécier ;p
Non sérieux si c'est pour faire des grilles y a un autre produit
surpuissant qui se nomme excel.
Sinon on utilise blend tout simplement parce que Microsoft veut ce
faire 2fois plus de fric.
Y a des trucs qui prenne 2sec dans blend et 3j dans VS.
Dans la prochaine version de VS y a des apports mais c'est toujours
pas blend. Et franchement 2 produits c'est ch...
Vincent
Envoyé de mon iPhone
Mathias Kluba
Je crois qu'on est tous d'accord pour dire que le code généré pour les winforms est trop verbeux...
mais ceci dit, il y a des approches de description d'interface par code plutôt sympa:
https://github.com/migueldeicaza/MonoTouch.Dialog
Il y a l'approche "fluent" et l'approche "par reflection".
Perso, je préfère la version par reflection...
Une autre alternative au xml serait le Json, mais la il n'existe pas de validation de schéma, comme le xsd pour le xaml.
Mais on peut imaginer une approche "mixte" : définir des objets "anonymes" en C# (ce qui ressemble fortement a du json) et les analyser par reflection.
Mais si on peut avoir l'équivalent de monotouch.dialog pour wpf, ça serait déjà bien...
Qui se lance sur ce projet open-source?
(ou est-ce que ça existe déjà??)
Le 16 févr. 2012 à 14:25, Nieve <niev...@gmail.com> a écrit :
Guillaume Collic
Je ne comprends pas, je ne vois aucun avantage à monotouch.dialog sur
xaml ? Le code contient plus de bruit (code -> new, etc) que le xaml
équivalent, sans être plus déclaratif pour autant et en apportant moins
de simplicité/souplesse (en xaml c'est par exemple génial de pouvoir
simplement changer un background avec un attribut textuel
Background="Orange", et si on veut quelquechose de plus complexe qu'une
couleur, genre un dégradé complexe on peut remplacer l'attribut par une
sous balise XML plus complète déclarant ce dégradé). Si tu aimes le
côté code, tu peux faire ton xaml en code, ça ressemblera.
Pour la forme, voila mon historique :
J'ai débuté winform et wpf en même temps. J'ai horreur des quelques
mois que j'ai eu de winform (une grosse application orientée grilles et
CRUD) pour plusieurs raisons (les souvenirs qui me reviennent :
difficile à merger en cas de modification, ne pousse pas à faire du
code propre, peu testable, supporte très mal les changements de DPI ce
qui pousse les utilisateurs a baisser la résolution de leurs écrans
modernes au lieu d'augmenter la définition pour voir plus gros ...) et
j'adore WPF. c'est propre, intuitif, puissant, facile a redimensionner,
et aussi adapté sur desktop que wp7 ou encore d'autres devices. Je
trouve que l'interface a une apparence native. Si on ne veut pas lire
le xaml, tout faire a la souris marche très bien. Si on veut lire le
xaml (ce que je conseil) il est facilement épuré sans fioriture, avec
juste ce qu'il faut de déclaré, et par la même occasion un plaisir a
versionner. J'ai commencé avec des applications perso desktop, puis des
utilitaires au travail, puis perso wp7, et maintenant
professionnellement sur table surface. Il y excelle, et je comprends
par contre de vos retours qu'une grosse application orientée grilles et
CRUD (ce que je n'ai pas fait en wpf) manque de composants clés en
main. Il n'y a pas des bibliothèques qui remplissent ce besoin ?
Bonne journée,
Guillaume, le rennais
Sent from my Windows Phone
From: Mathias Kluba
Sent: 16/02/2012 23:24
To: paris...@googlegroups.com
Cc: altnetfr
Subject: Re: [alt.net.fr] Re: Client lourd: WPF or not WPF?
Geoffrey DANIEL
Geoffrey DANIEL