Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Oui, Microsoft travaille bien sur un framework graphique unifié

Et la firme embauche pour accélérer son développement

Oui, Microsoft travaille bien sur un framework graphique unifié

Le 22 juillet 2014 à 13h45

Microsoft travaille sur un framework commun capable de servir au développement d’applications pour tous les supports, qu’il s’agisse des ordinateurs, des tablettes, des téléphones ou de la Xbox One. Le nom de ce framework n’est pas encore connu mais il représente dans tous les cas une étape marquante vers un système unique, qui pourrait être Threshold.

windows framework ui threshold

Un framework unique pour l'ensemble des supports 

Tous les signes pointent actuellement vers une unification de la plateforme Windows. Microsoft a commencé par fusionner les comptes développeurs pour Windows et Windows Phone, avant de proposer les applications universelles, capables de fonctionner indifféremment sur les versions 8.1 des deux plateformes. Plus récemment, ce sont les ressources pour les développeurs qui ont été concentrées en un lieu unique. Désormais, la firme prépare l’étape suivante.

 

Dans une récente offre d’emploi, dénichée par h0x0d, la firme cherche un ingénieur pour travailler avec l’équipe XAML, qui « construit l’infrastructure d’interface au cœur du système One Microsoft ». L’annonce ajoute : « Notre framework est utilisé par des centaines de milliers de développeurs, dont de nombreuses équipes de Microsoft », tout en précisant qu’il fera « partie intégrante » du succès des plateformes et de l’écosystème.

 

L’offre d’emploi est particulièrement précise sur les missions qui attendent l’ingénieur :

  • Permettre aux développeurs d’utiliser une seule interface pour tous les supports : ordinateurs, téléphones, tablettes et Xbox (la mention « One » n’est pas présente)
  • Créer des contrôles « riches » qui procureront aux utilisateurs un vrai « plaisir » d’utilisation
  • L’extension des capacités de la plateforme pour accroitre la productivité des développeurs, à savoir publier plus d’applications, plus rapidement
  • Une augmentation radicale des performances pour que les interfaces restent parfaitement fluides, même quand elles deviennent complexes

Pourquoi un seul framework ?

Pourquoi créer un « UI framework » unique ? Parce qu’actuellement, les technologies permettant de bâtir les interfaces se choisissent en fonction des plateformes. Il est tout à fait possible d’utiliser le XAML, qui est justement le langage bâti par Microsoft pour concevoir des interfaces de manière complètement séparée du reste du code, consacré au fonctionnement proprement dit de l’application. Mais selon que l’on développe pour du Windows classique, du Windows Store, pour Windows Phone ou pour la Xbox, les technologies ont beau être semblables, ce ne sont pas les mêmes.

 

Avec Windows Threshold, Microsoft a l’occasion de faire un grand pas vers le Graal longtemps cherché par l’entreprise : une même base technique pour tous les supports. Il n’est pas certain que cet éventuel Windows « 9 » soit ce fameux Windows, mais de très nombreuses rumeurs parlent d’une interface qui sera spécifique à chaque environnement. La firme pourrait profiter de cette occasion pour revoir complètement le socle technologie du bureau, en proposant justement un nouvel environnement qui, s’il se destinera aux ordinateurs classiques, apparaitra comme beaucoup plus moderne.

 

Quoi qu’il en soit, Microsoft mentionne clairement un système « One Microsoft ». Dans un tel contexte d’unification, la firme veut certainement dire que le framework graphique sera au cœur de cette plateforme. Il existe de nombreuses rumeurs actuellement, mais nous nous concentrons ici sur celles qui recoupent directement des informations « concrètes », notamment dans les offres d’emploi. Aussi, même si beaucoup, comme Mary Jo Foley et Paul Thurrott, parlent d’une bêta pour cet automne et d’une sortie de Windows Threshold pour le printemps prochain, les pincettes restent de rigueur.

 

Un seul compte développeur, un seul site pour toutes les ressources, des applications universelles. Il semble donc que l'étape suivante soit le framework graphique.

Commentaires (78)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







Thoscellen a écrit :



Pour le coup, c’est plutot les interfaces utilisateurs que les technos employés qui m’intéressent, cad me donner envie avec un OS agréable a utiliser, ergonomique. Google et Apple font rêver les gens avec de belles fonctionnalités, alors Microsoft, a quand ?

Ca commence a venir avec Windows Phone et leur SDK/API pour le Lockscreen, l’arrivée de la barre de notifications et autres améliorations. Mais je trouve que la concurrence vends mieux son ergonomie.





Je me dis qu’une fois les outils de développement suffisamment mature ils pourront justement plus facilement montrer la cohérence entre les différents devices … Mais c’est vrai que pour l’instant ca manque de lien … Y’a juste les données, historique, mot de passes qui sont synchro via OneDrive. Mais iOS 8 et Yosemite vont surement taper un grand coup dans la fourmilière pour faire bouger Microsoft et Google (ces derniers ont d’ailleurs déjà commencé a syncho les notifications d’Android sur ChromeOS)


votre avatar







Adrian Shephard a écrit :



Non en fait je retire ce qui serait vraiment bien c’est de pouvoir écrire des interfaces entièrement en html/javascript. Comme ça on pourrait utiliser les outils qu’on veut, que ça soit pour générer du html ou javascript, et arrêter de se demander à longueur de temps pour quelle plateforme on écrit.





C’est possible avec les interfaces ModernUI de MS si je ne me trompe pas… Et on peut dev dans visual studio. Ca a été pas mal poussé au début, mais je ne sais pas où ça en est dans la mesure où c’est pas du XAML.



Sinon je me suis toujours demandé pourquoi ils ont séparé silverlight du WPF de RT… Une API unifiée aurait été tellement plus simple pour tout le monde…


votre avatar







hadoken a écrit :



NON, pitié NON…



Le javascript est un langage immonde pas du tout prévu pour faire de vraies applications. Ramener cette horreur pour des applications qui n’ont pas les requirements du web (i.e. tourner dans n’importe quel browser) est une hérésie. Où comment se fouetter soit même avec du code dégueux. Je vais pas relancer ce débat mais cette chose est un immondice sans nom à éviter à tout prix.





L’idéale serait peut etre d’avoir le code fonctionnel en C# ou C++/CX mais avec une interface faite en HTML/CSS/Javavscript ?


votre avatar

Ca fait surtout penser à plasma 5 qui vient de sortir.



Quand on voit que ce que veut faire MS existe partiellement depuis 4 ans chez Kde, et totalement depuis qq jours, c’est à pleurer que ce bureau parte d’aussi bas dans les PDM.



http://blog.jospoortvliet.com/2014/01/building-converging-uis.html

votre avatar







arno53 a écrit :



L’idéale serait peut etre d’avoir le code fonctionnel en C# ou C++/CX mais avec une interface faite en HTML/CSS/Javavscript ?





Le xaml offre plus de possibilité que le couple HTML/CSS pourquoi alors utiliser une technologie faite pour le web même si au niveau syntaxe les 2 peuvent se ressembler.


votre avatar







youtpout978 a écrit :



Le xaml offre plus de possibilité que le couple HTML/CSS pourquoi alors utiliser une technologie faite pour le web même si au niveau syntaxe les 2 peuvent se ressembler.





Le seul avantage du HTML/CSS c’est que ça marche partout. Coder le moteur en C++/C# et l’interface en HTML/CSS est un bon compromis.


votre avatar







hadoken a écrit :



NON, pitié NON…



Le javascript est un langage immonde pas du tout prévu pour faire de vraies applications. Ramener cette horreur pour des applications qui n’ont pas les requirements du web (i.e. tourner dans n’importe quel browser) est une hérésie. Où comment se fouetter soit même avec du code dégueux. Je vais pas relancer ce débat mais cette chose est un immondice sans nom à éviter à tout prix.





+1000



Faut faire crever ces techno faite a la va vite …


votre avatar







hadoken a écrit :



NON, pitié NON…



Le javascript est un langage immonde pas du tout prévu pour faire de vraies applications. Ramener cette horreur pour des applications qui n’ont pas les requirements du web (i.e. tourner dans n’importe quel browser) est une hérésie. Où comment se fouetter soit même avec du code dégueux. Je vais pas relancer ce débat mais cette chose est un immondice sans nom à éviter à tout prix.





Trop tard, le débat est relancé. C’est quoi ton problème avec JS?


votre avatar







charon.G a écrit :



Le seul avantage du HTML/CSS c’est que ça marche partout. Coder le moteur en C++/C# et l’interface en HTML/CSS est un bon compromis.





Comment gérer tout ce qui est binding et autre possibilité offerte par le xaml, à la fin on aura un html avec plein de nouveau attribut pas forcément compatible avec tous les navigateurs pour le coup.

Ou faudrait une classe intermédiaire qui s’occupe de faire ça mais ça ne ferait que complexifier les choses.

Je ne suis pas contre pouvoir faire du HTML/CSS pour faire des apps mais pas pour que ça remplace XAML, toute façon on aura surement la possibilité de faire ces apps en HTML/CSS/JS sur cette nouvelle UI.


votre avatar







youtpout978 a écrit :



Comment gérer tout ce qui est binding et autre possibilité offerte par le xaml, à la fin on aura un html avec plein de nouveau attribut pas forcément compatible avec tous les navigateurs pour le coup.

Ou faudrait une classe intermédiaire qui s’occupe de faire ça mais ça ne ferait que complexifier les choses.

Je ne suis pas contre pouvoir faire du HTML/CSS pour faire des apps mais pas pour que ça remplace XAML, toute façon on aura surement la possibilité de faire ces apps en HTML/CSS/JS sur cette nouvelle UI.





Il ne s’agit pas de remplacer le XAML. Mais vu que le HTML/CSS est très répandu et marche partout, ça reste intéressant d’avoir les deux.

Perso avec ma-config.com j’utilise une séparation architecturale similaire depuis dix ans.


votre avatar







youtpout978 a écrit :



Comment gérer tout ce qui est binding et autre possibilité offerte par le xaml, à la fin on aura un html avec plein de nouveau attribut pas forcément compatible avec tous les navigateurs pour le coup.

Ou faudrait une classe intermédiaire qui s’occupe de faire ça mais ça ne ferait que complexifier les choses.

Je ne suis pas contre pouvoir faire du HTML/CSS pour faire des apps mais pas pour que ça remplace XAML, toute façon on aura surement la possibilité de faire ces apps en HTML/CSS/JS sur cette nouvelle UI.







Soit MS prépare un backend html5 capable d’interpréter son xaml sur toutes les plate-formes web (comme pour gtk) sans avoir à installer un runtime binaire et là ils peuvent être fiers (et espérer gagner des pdm)



Soit ils ont juste réussi à unifier le xaml entre les différents environnement win*box et il n’y a pas lieu de se réjouir (on se poserait plutôt la question de savoir pourquoi ce n’est pas comme cela depuis le début)



Soit la réponse D.


votre avatar







gokudomatic a écrit :



Trop tard, le débat est relancé. C’est quoi ton problème avec JS?





pas de vraie POO. Passer entre différents langage de haut niveau est souvent pas super complique tellement les concepts sont relativement proches. Avec le javascript c’est toujours une autre paire de manche… De ce cote vivement l’arrivée de l’ECMA Script 6.


votre avatar







gokudomatic a écrit :



Trop tard, le débat est relancé. C’est quoi ton problème avec JS?







Faire une application avec JS, c’est comme faire une bande-dessinée avec notepad. <img data-src=" />





Sinon, j’aime bien le principe de séparation XAML/C# (qui n’est pas sans rappeler celui de DFM/Delphi). Mais faudrait vraiment optimiser les performances de rendu XAML. Sur des plateformes embedded, c’est vraiment limite si on ne tape pas dans la dernière génération de celeron ou i3.


votre avatar







charon.G a écrit :



Il ne s’agit pas de remplacer le XAML. Mais vu que le HTML/CSS est très répandu et marche partout, ça reste intéressant d’avoir les deux.

Perso avec ma-config.com j’utilise une séparation architecturale similaire depuis dix ans.





Ça revient à faire une espèce d’ASP pour du client lourd parce qu’actuellement ils se font pas chier les apps HTML/CSS/JS ne font que se lancer avec le moteur d’IE.


votre avatar







youtpout978 a écrit :



Ça revient à faire une espèce d’ASP pour du client lourd parce qu’actuellement ils se font pas chier les apps HTML/CSS/JS ne font que se lancer avec le moteur d’IE.





En fait pour WinRT comme l’a indiqué arno53 au dessus tu peux déjà coder un composant WinRT en C++ ou C# et un autre composant WinRT en HTML/JS/CSS et les faire communiquer ensemble.


votre avatar







charon.G a écrit :



En fait pour WinRT comme l’a indiqué arno53 au dessus tu peux déjà coder un composant WinRT en C++ ou C# et un autre composant WinRT en HTML/JS/CSS et les faire communiquer ensemble.





Par l’intermédiaire du JS ?


votre avatar







Zorak Zoran a écrit :



A prendre avec les pincettes d’usage :

theverge.com The VergeC’est pas du tout la nouvelle interface mais juste une version de travail 1 an avant la sortie supposé.

Par exemple voila une image de windows 7 M1 datant de 2008 :

http://i1-news.softpedia-static.com/images/news2/Installing-Windows-7-Milestone-…


votre avatar

En lisant le sous titre je me demande si Microsoft a lu le

Mythical Man-Month de Fred Brooks



Une référence pourtant

<img data-src=" />

votre avatar







Zorak Zoran a écrit :



A prendre avec les pincettes d’usage :

theverge.com The VergeCa semble vrai mais les changements majeurs d’interfaces sont sur une autre branche de développement qui n’a pas encore été mergé avec celle-ci … Du coup l’interface général du Bureau de Windows 9 reste un mystère … Mais concernant ce nouveau menu, je le trouve trop classique … Pourquoi ne pas le faire monter jusqu’au haut de l’ecran comme dans ce concept <img data-src=" /> Bon celui-ci est sensé être flexible et s’élargir si il y’a beaucoup de LiveTiles mais je suis un peu déçu pour l’instant …


votre avatar







arno53 a écrit :



Pourquoi ne pas le faire monter jusqu’au haut de l’ecran comme dans ce concept <img data-src=" /> Bon celui-ci est sensé être flexible et s’élargir si il y’a beaucoup de LiveTiles mais je suis un peu déçu pour l’instant …





Excellent concept en effet, le meilleur des 2 mondes :)


votre avatar

On verra ce que ça va donner mais MS y aura mis le temps pour arriver à ça.

votre avatar







arno53 a écrit :



Par contre j’ai l’impression qu’il y’a pas mal de critique sur les performances du XAML … True or not ?







Oui ET non.

Je n’ai pas programmé en Silverlight, mais mon expérience avec WPF c’est qu’il est particulièrement ardu de faire du code rapide, lisible, maintenable et qui respecte le MVVM, le design pattern qui sous-tend WPF.



C’est dommage parce que l’idée de base est bonne. Du WPF bien fait c’est très beau… Mais c’est vite lent. Donc on l’optimise, et ce faisant, on le massacre.



D’ailleurs la très grande personnalisation de WPF c’est super cool, mais ça permet à des développeurs de produire des monstres vraiment horribles, en terme de lisibilité.



Je sais pas, peut-être ce qui serait bien c’est un framework un peu plus strict mais mieux optimisé, et qui intègre les patterns Controller (pour l’instant on n’a que le View-Model qui devient vite surchargé) et Service, comme angularJS (mon autre expérience avec le MVVM), pourrait mieux marcher.



A vrai dire je n’ai pas trop d’idée sur comment faire un framework graphique de qualité, mais c’est vrai que c’est vraiment évident que ça manque dans le monde Microsoft.


votre avatar

C’est pas demain la veille.



Déjà qu’ils sont pas foutus d’uniformiser leurs propres interfaces dans leur produit phare de développement (fenêtre propriété des projets dans Visual studio suivant que c’est du VB ou du c#) et qu’ils nous ont sorti des composants de base différents suivant que t’étais en XAML ou en silverlight…

votre avatar

en somme un XNA étendu au delà du jeu vidéo?

votre avatar







DDReaper a écrit :



C’est pas du tout la nouvelle interface mais juste une version de travail 1 an avant la sortie supposé.

Par exemple voila une image de windows 7 M1 datant de 2008 :

http://i1-news.softpedia-static.com/images/news2/Installing-Windows-7-Milestone-…





+1 les premières versions ressemblent toujours à l’os précédent. Ca devrait changer. Surtout que d’après des contacts de neowin, on verrait nettement la différence graphique entre 8 et 9. ils disent même qu’il y aurait plus de différences entre le bureau de 8 et 9 qu’entre le bureau de 7 et 8.


votre avatar







Adrian Shephard a écrit :



A vrai dire je n’ai pas trop d’idée sur comment faire un framework graphique de qualité, mais c’est vrai que c’est vraiment évident que ça manque dans le monde Microsoft.







Non en fait je retire ce qui serait vraiment bien c’est de pouvoir écrire des interfaces entièrement en html/javascript. Comme ça on pourrait utiliser les outils qu’on veut, que ça soit pour générer du html ou javascript, et arrêter de se demander à longueur de temps pour quelle plateforme on écrit.


votre avatar







arno53 a écrit :



Ca semble vrai mais les changements majeurs d’interfaces sont sur une autre branche de développement qui n’a pas encore été mergé avec celle-ci …





Pour le coup, c’est plutot les interfaces utilisateurs que les technos employés qui m’intéressent, cad me donner envie avec un OS agréable a utiliser, ergonomique. Google et Apple font rêver les gens avec de belles fonctionnalités, alors Microsoft, a quand ?

Ca commence a venir avec Windows Phone et leur SDK/API pour le Lockscreen, l’arrivée de la barre de notifications et autres améliorations. Mais je trouve que la concurrence vends mieux son ergonomie.


votre avatar







Adrian Shephard a écrit :



Non en fait je retire ce qui serait vraiment bien c’est de pouvoir écrire des interfaces entièrement en html/javascript. Comme ça on pourrait utiliser les outils qu’on veut, que ça soit pour générer du html ou javascript, et arrêter de se demander à longueur de temps pour quelle plateforme on écrit.





Avec WinRT depuis 8 tu peux écrire une application entièrement en javascript/HTML5 si tu veux.

La version 2 de winJS est multiplateforme


votre avatar

Il est évident que le XAML sera le langage de programmation pour tous les futurs développements Microsoft (hors ASP.Net bien sur). Le XAML est vraiment mûr depuis le temps (6 ans), et est déjà en place sur de très nombreuses plateformes : .Net (WPF), Silverlight, Windows Phone, WinRT…etc.



Il suffit d’abattre les problématiques techniques liées aux versions des binaires (assemblies) et les limitations qui en découlent (par exemple le XAML de Silverlight n’est (pour simplifier) qu’un sous ensemble de celui pour WPF) pour avoir vraiment qu’une unique librairie (assembly “neutre” commune à toutes les plateformes et partage à 100% du code).









Adrian Shephard a écrit :



Oui ET non.

Je n’ai pas programmé en Silverlight, mais mon expérience avec WPF c’est qu’il est particulièrement ardu de faire du code rapide, lisible, maintenable et qui respecte le MVVM, le design pattern qui sous-tend WPF.

…





Je ne suis pas d’accord. WPF repose sur des bases techniques bien différentes de celles de Winforms, et notament c’est géré en bas niveau par le GPU. WPF c’est carrément mieux que GDI+. MVVM il faut s’y faire mais ce n’est pas plus compliqué que n’importe quel autre design pattern (MVC, MVP…). Et c’est à 95% la même philosophie que angularJS au fait.


votre avatar







Adrian Shephard a écrit :



Non en fait je retire ce qui serait vraiment bien c’est de pouvoir écrire des interfaces entièrement en html/javascript. Comme ça on pourrait utiliser les outils qu’on veut, que ça soit pour générer du html ou javascript, et arrêter de se demander à longueur de temps pour quelle plateforme on écrit.





NON, pitié NON…



Le javascript est un langage immonde pas du tout prévu pour faire de vraies applications. Ramener cette horreur pour des applications qui n’ont pas les requirements du web (i.e. tourner dans n’importe quel browser) est une hérésie. Où comment se fouetter soit même avec du code dégueux. Je vais pas relancer ce débat mais cette chose est un immondice sans nom à éviter à tout prix.


votre avatar







arno53 a écrit :



Pourquoi ne pas le faire monter jusqu’au haut de l’ecran comme dans ce concept <img data-src=" /> Bon celui-ci est sensé être flexible et s’élargir si il y’a beaucoup de LiveTiles mais je suis un peu déçu pour l’instant …







Merci pour le lien, longue lecture mais passionnante.


votre avatar







arno53 a écrit :



Pour Ubuntu, est ce que les apps sont sandboxé par défaut ? Ca serait a la limite le point faible de la solution si ce n’est pas le cas … Enfin le plus gros problème reste les part de marché et la visibilté <img data-src=" />





Oui elles sont sandboxé.


votre avatar







youtpout978 a écrit :



Par l’intermédiaire du JS ?





En interne tous les objets WinRT sont des objets COM+. Quand tu appelles une méthode WinRT. Tu vas au final appeler un objet COM+ par projection. Toutes les api WinRT sont référencées par du métadata WinMD. je t’invite à lire le dossier NXI sur Windows 8 tout est expliqué en détail.



source


votre avatar

(tout ces termes techniques qui sortent…)



Peut-être une version de windows spécial jeux? <img data-src=" />

votre avatar

Youpi, ils ont ré-inventé java <img data-src=" /> …

votre avatar

One framework to rule them <img data-src=" />

votre avatar







fullsun a écrit :



(tout ces termes techniques qui sortent…)



Peut-être une version de windows spécial jeux? <img data-src=" />





De ce que j’ai compris, MS va enfin faire une interface qui s’adaptera en fonction de la machine.

En gros, ils vont enfin unifier tout ça pour que tout soit plus simple un peu comme Apple et Google.


votre avatar







arno53 a écrit :



L’idéale serait peut etre d’avoir le code fonctionnel en C# ou C++/CX mais avec une interface faite en HTML/CSS/Javavscript ?





Je ne pense pas. Je pense que pour du Windows il faut coder en C# (ou C++ pour des cas particuliers) / XAML. HTML/CSS/JS sont des langages pour le web, pas pour les applications qui ne sont pas des applications web.

La promesse “écrire du HTML5 pour coder une appli c’est bien c’est compatible sur toutes les plateformes” est un mensonge, chaque plateforme a ses spécificités et vouloir faire des applications avec des langages faits pour le web et espérer que çà marche nickel dans toutes les applis natives (desktop Win32, android, Win8, WP, iOS…) est louable, mais ce sera un échec.







charon.G a écrit :



Le seul avantage du HTML/CSS c’est que ça marche partout. Coder le moteur en C++/C# et l’interface en HTML/CSS est un bon compromis.





C’est le seul avantage en effet. Alors pourquoi trainer cette horreur alors que le “çà marche partout” n’est pas un pré-requis de Microsoft pour son framework graphique ? Laisser l’option de pouvoir le faire (cf. projections WinRT) est toujours bien ; se baser là dessus pour construire le prochain framework graphique pour toutes les applis Windows serait un suicide.







gokudomatic a écrit :



Trop tard, le débat est relancé. C’est quoi ton problème avec JS?





Mon problème ? Tous les problèmes du monde. C’est une horreur. Un déchet qu’on ne se traine que pour une unique raison : c’est le seul truc supporté par tous les browsers.

Lien FR avec quelques exemple (ne pas s’arrêter au titre) :http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/

Sinon tu googles “javascript sucks”, “javascript flawed” etc.

Tout le monde construit un truc sur javascript pour éviter d’en écrire tellement c’est pourri (dart, typeScript…).


votre avatar







hadoken a écrit :



Je ne suis pas d’accord. WPF repose sur des bases techniques bien différentes de celles de Winforms, et notament c’est géré en bas niveau par le GPU. WPF c’est carrément mieux que GDI+. MVVM il faut s’y faire mais ce n’est pas plus compliqué que n’importe quel autre design pattern (MVC, MVP…). Et c’est à 95% la même philosophie que angularJS au fait.





WPF a de gros problème de perf, entre autre car la couche d’accès GPU qui est derrière a été fait avec les pieds.



L’utilisation du XAML est bien plus propre dans WinRT, mais si ils arrivent à concevoir directement dans DirectX12 le support du XAML, là on pourrait avoir des perfs vraiment sympa.



Mais clairement, avoir des perfs en WPF (de vrai perf, pour faire du quasi temps réel) c’est très difficile pour l’instant. On est guère mieux que GDI+ (mais WPF a bcp d’autres avantage que les perfs bien sur).


votre avatar







arno53 a écrit :



Pour Apple y’a pas vraiment de mouvent d’unification pour l’instant … Cocoa et Cocoa Touch reste assez éloigné l’un de l’autre d’après ce que j’ai compris et il est pas possible de récupérer une grosse partie de l’App iOS pour la porter vers Mac… Apple se contente juste de proposé ses apps (Plan) ou certaines fonctionnalité sur ses 2 support.



Pour Google, ils ont annoncé à la Google I/O que les apps Android tourneront sur Chrome OS mais ils n’ont pas plus détaillé que ça <img data-src=" /> C’est soit les apps Android qui tournent dans NaCl sur Chrome(OS) ce qui serait vraiment très intéressant soit juste que le nom de l’application qui pointe vers la version Android (Java) et vers la version Web App (javascript/html ou en C via NaCl je crois) mais là pour le coup d’un point de vu développement ca change pas grand chose <img data-src=" />



Pour Ubuntu, est ce que les apps sont sandboxé par défaut ? Ca serait a la limite le point faible de la solution si ce n’est pas le cas … Enfin le plus gros problème reste les part de marché et la visibilté <img data-src=" />



En tout cas si Microsoft peut enfin unifier tout ce qui touche au XAML en prenant les points fort de WPF et Silverlight ca va vraiment devenir intéressant … Il faudra surement attendre 2020 et la fin de support de Windows 7 pour que ça soit massivement utilisé (et a condition que ca soit retroporté sur Windows 8) mais c’est deja un bon pas en avant …



Par contre j’ai l’impression qu’il y’a pas mal de critique sur les performances du XAML … True or not ?







les rumeurs disent que win9 sera une maj gratuite pour win7/8. La base installée devrait rapidement être beaucoup plus grande que celle d’iOS. Nul besoin d’attendre 2020 donc.





concernant XAML et les perfs tout dépend de l’implémentation.



la toute première techno exploitant du XAML était WPF.

il est accéléré matériellement et beaucoup plus performant que GDI+. Mais les performances sont loin d’être aussi bonnes qu’elles pourraient l’être.



le modèle interne de WPF est taillé pour fournir une certaine compatibilité avec les technos Windows legacy (GDI, automation, COM,…) et donc WPF a une certaine lourdeur comparé à Silverlight qui n’a pas eu à supporter ces technologies.

au niveau du rendu, WPF datant de 3ans avant la sortie de Direct2D, il utilise son propre moteur de rendu et a pas mal de défauts (les ellipses par exemple sont très lentes à dessiner car constituées de centaines de triangles dessinés par le GPU).



Silverlight et WINRT utilisent l’accélération matérielle pour la composition et la mise en cache des bitmaps, mais pas pour le rendu des éléments de base qui se fait toujours en software.



paradoxalement, la plupart du temps Silverlight et WinRT/XAML sont plus performants que WPF.



MS a annoncé que winRT/XAML allait bientôt utiliser direct2d et sera donc entièrement accéléré matériellement. Je pense que c’est l’api dont il est question dans cette news.



en attendant, ça peut paraitre dingue, mais à part utiliser direct2d directement en c++, le moteur de rendu le plus performant pour les interfaces graphiques en WinRT et desktop, c’est HTML/JS via le moteur de rendu d’IE10/11.



sinon pour revenir à WPF, faute de mieux je reste toujours assez fan.



j’ai même réalisé une alternative à l’explorateur Windows en WPF.

je me suis heurté à pas mal de soucis de perf, notamment sur les Intel Atom Clover Trail dont la partie graphique est lente et supporte très mal WPF (alors que les applis winRT sont beaucoup plus fluides sur la même machine).



http://www.julien-manici.com/immersive_explorer/


votre avatar

Cette nouvelle API ne sera pas du luxe. Si seulement ils pouvaient carrément lourder XAML (le truc le plus verbeux au monde) et nous filer un vrai langage avec un vrai éditeur qui fonctionne vraiment après dix ans…









seb2411 a écrit :



Ils peuvent forker QT sinon <img data-src=" />





Le moteur de Qt est excellent. Mais les mécanismes de templating de WPF sont supérieurs, entre autres. Deux époques différentes, deux approches différentes. Qt Quick peut-être mais je ne sais pas à quel point celui-ci a progressé et s’il est aujourd’hui une panacée.



Après il faudrait encore offrir une vraie interface native pour dotnet et JS (et pas juste une biblio vaguement maintenue), parce que le C++ pour le développement de nouvelles applis c’est has been en général.









Bejarid a écrit :



WPF a de gros problème de perf, entre autre car la couche d’accès GPU qui est derrière a été fait avec les pieds.





Non, parce que les GPU sont optimisés pour rendre vingt persos de 10k polys, cent arbres de 1k polys, et instancier mille fois le même brin d’herbe. Pas pour afficher dix mille caractères indépendants de 100 polys chacun, cinquante mille rectangles tous différents de 2 polys chacun, etc. Je ne dis pas que le moteur ne peut pas être amélioré mais enfin le rendu 2D reste un art délicat.



Et si WinRT est plus rapide, c’est que des fonctionnalités ont été sacrifiées pour simplifier le processus de rendu et l’accélérer (clippings non-rectangulaires, bitmap effects, OpacityMask, VideoBrush, RadialGradientBrush, etc). Entre le beurre et l’argent du beurre ils ont choisi. Par contre je suis d’accord pour dire qu’aujourd’hui html reste la solution la plus performante mais ce n’est pas la panacée non plus. Au final je tire quand même d’excellentes choses de WPF. Ca reste une plaie à utiliser et correctement exploiter mais le résultat peut définitivement être à la hauteur des attentes.







Seazor a écrit :



Ca fait surtout penser à plasma 5 qui vient de sortir.



Quand on voit que ce que veut faire MS existe partiellement depuis 4 ans chez Kde, et totalement depuis qq jours, c’est à pleurer que ce bureau parte d’aussi bas dans les PDM.



http://blog.jospoortvliet.com/2014/01/building-converging-uis.html





J’avoue que ça donne davantage envie que XAML. Je ne suis même pas sûr que ce soit moins puissant.


votre avatar







HarmattanBlow a écrit :



Non, parce que les GPU sont optimisés pour rendre vingt persos de 10k polys, cent arbres de 1k polys, et instancier mille fois le même brin d’herbe. Pas pour afficher dix mille caractères indépendants de 100 polys chacun, cinquante mille rectangles tous différents de 2 polys chacun, etc. Je ne dis pas que le moteur ne peut pas être amélioré mais enfin le rendu 2D reste un art délicat.





C’est pas faux, mais WPF reste énormément en retrait au niveau de l’exploitation du GPU par rapport à WinRT.

J’ai passé pas mal de temps à analyser le comportement de WPF et de WinRT, à voir les différents appels à Direct3D qui sont faits et WinRT est bien plus efficace. Quand t’as WPF qui n’est pas capable de réexploiter la moindre géométrie, qui crée un nombre incalculable de textures intermédiaires, fait autant de draw calls qu’il y a d’objets à dessiner,… tu vois rapidement qu’il y a pas mal de possibilités d’optimisations. Les draw calls sont un véritable problème de WPF qui est basé sur Direct3D9 et où l’overhead d’un appel était non négligeable.

A côté de ça, une appli WinRT va rassembler un gros paquet d’opérations en un seul draw call pour rendre des objets qui peuvent exploiter le même PS. Toutes les formes similaires sont rendues en une seule passe (en rassemblant un ensemble de visuel dans une même texture).

Et c’est bien là comme tu le dis que le GPU peut s’exprimer : beaucoup plus de polygones à traiter d’un coup, et moins d’appels.



Bref, WPF a bien mal vieilli et le peu de support de MS ces 5 dernières années ne lui ont pas vraiment fait de cadeaux. En espérant voir des choses intéressantes sur ce point.


votre avatar







HarmattanBlow a écrit :



Non, parce que les GPU sont optimisés pour rendre vingt persos de 10k polys, cent arbres de 1k polys, et instancier mille fois le même brin d’herbe. Pas pour afficher dix mille caractères indépendants de 100 polys chacun, cinquante mille rectangles tous différents de 2 polys chacun, etc. Je ne dis pas que le moteur ne peut pas être amélioré mais enfin le rendu 2D reste un art délicat.



Et si WinRT est plus rapide, c’est que des fonctionnalités ont été sacrifiées pour simplifier le processus de rendu et l’accélérer (clippings non-rectangulaires, bitmap effects, OpacityMask, VideoBrush, RadialGradientBrush, etc). Entre le beurre et l’argent du beurre ils ont choisi. Par contre je suis d’accord pour dire qu’aujourd’hui html reste la solution la plus performante mais ce n’est pas la panacée non plus. Au final je tire quand même d’excellentes choses de WPF. Ca reste une plaie à utiliser et correctement exploiter mais le résultat peut définitivement être à la hauteur des attentes.





[mode d’jeuns]

Comment que t’y connais rien en GPU ça fait pitié mec !

[/mode d’jeuns]



Un GPU c’est faire pour tourner lentement mais parallèlement, comme les pixels des écrans. Au contraire d’un CPU qui doit enchainer vite. Donc chaque synchro est une perte sèche.



Il n’est pas question de 2D ou de 3D (la 3D de WPF est encore pire que sa 2D en terme d’optimisation), mais bien de DrawCall qui sont permanents et quasi tous inutiles. La première critique que tout le monde à fait (y compris des gens de chez MS) c’est l’absence totale de regroupement des formes dessinnées. Toutes les autres BU de MS ont fait mieux, par exemple IE9, sortie à peine après WPF, qui lui aussi fait appel à DirectX, mais nettement mieux. Les gens qui ont fait WPF avaient juste pas le niveau en moteur graphique. Ceux qui ont fait WinRT (potentiellement les mêmes mais plus expérimentés) l’avaient bcp plus, d’où des perfs incomparables.



Cesse de jouer au plus malin et renseigne-toi un peu avant de parler d’un sujet dont manifestement tu n’as même pas les bases.


votre avatar







jmanici a écrit :



[quote:5099198:arno53]



[…]



j’ai même réalisé une alternative à l’explorateur Windows en WPF.

je me suis heurté à pas mal de soucis de perf, notamment sur les Intel Atom Clover Trail dont la partie graphique est lente et supporte très mal WPF (alors que les applis winRT sont beaucoup plus fluides sur la même machine).



http://www.julien-manici.com/immersive_explorer/







Jolie travail, je teste ça des que je peux <img data-src=" />


votre avatar







Crysalide a écrit :



Qt existe, pourquoi réinventer la roue ?







Qt n’a rien à voir avec ce qu’ils veulent faire …



Ils cherchent plutôt un framewok a la Win32/MFC (mêmes fonctions d’API partout, même look & feel, même outils, juste les flags/options qui diffèrent), mais plus du côté C# WPF … ce qu’il n’ont pas ou presque pas …



votre avatar







Bejarid a écrit :



[mode d’jeuns]

Comment que t’y connais rien en GPU ça fait pitié mec !

[/mode d’jeuns]



Un GPU c’est faire pour tourner lentement mais parallèlement, comme les pixels des écrans. Au contraire d’un CPU qui doit enchainer vite. Donc chaque synchro est une perte sèche.



Il n’est pas question de 2D ou de 3D (la 3D de WPF est encore pire que sa 2D en terme d’optimisation), mais bien de DrawCall qui sont permanents et quasi tous inutiles. La première critique que tout le monde à fait (y compris des gens de chez MS) c’est l’absence totale de regroupement des formes dessinnées. Toutes les autres BU de MS ont fait mieux, par exemple IE9, sortie à peine après WPF, qui lui aussi fait appel à DirectX, mais nettement mieux. Les gens qui ont fait WPF avaient juste pas le niveau en moteur graphique. Ceux qui ont fait WinRT (potentiellement les mêmes mais plus expérimentés) l’avaient bcp plus, d’où des perfs incomparables.



Cesse de jouer au plus malin et renseigne-toi un peu avant de parler d’un sujet dont manifestement tu n’as même pas les bases.









IE9 sorti à peine après WPF?



WPF est sorti en 2006, et était en développement depuis 2002.



IE9 est sorti en 2010 en s’appuyant sur Direct2D et DirectWrite apparus en 2009 avec win7.



il y a quand même pas mal d’années entre ces technos, et on peut pardonner à l’équipe du .net Framework de ne pas avoir eu l’expertise d’une équipe entièrement dédiée à la création d’une API graphique.



je ne pense pas qu’il faille s’attendre à des améliorations aux niveau de WPF. MS ne voudra pas prendre le risque de casser la compatibilité.



l’avenir c’est WinRT/XAML, qui lui contrairement à WPF va évoluer régulièrement avec chaque nouvelle version de Windows.



j’espère juste qu’on aura la possibilité de l’utiliser sur le desktop (hors sandbox) comme api graphique en remplacement de WPF.



ce serait dommage que les applis pro qui peuvent pas migrer vers WinRT à cause de la sandbox ne puissent pas profiter des améliorations de perf.


votre avatar



ce serait dommage que les applis pro qui peuvent pas migrer vers WinRT à cause de la sandbox ne puissent pas profiter des améliorations de perf.





au passage c’est déjà possible sous win8.1 via les applis hybrides, mais c’est trop contraignant:

-le sideloading doit être activé

-pas encore de support fenêtré pour les applis WinRT.

votre avatar







Bejarid a écrit :



Il n’est pas question de 2D ou de 3D (la 3D de WPF est encore pire que sa 2D en terme d’optimisation), mais bien de DrawCall qui sont permanents et quasi tous inutiles.





C’est exactement ce que j’expliquais : que le problème était dans le nombre d’objets indépendants à dessiner.



Et s’il est facile de dire “batch, batch, batch”, c’est en pratique difficile à faire quand tu as un arbre d’objets avec des attributs de rendu composés et difficilement isolables (masque d’opacité appliqués à un groupe d’objets, transformations lourdingues à faire sur le CPU puisque geo shader inutilisable, etc), que tu dois veiller à mettre en cache certaines parties du rendu et que tu dois en plus veiller à rendre le texte après avoir dessiné le fond de façon à pouvoir faire ton subpixel aliasing.



Mais bon, j’imagine qu’il est plus défoulant de sortir un “lol mé kom y son trop nuls mé comme t tro nul toi.”







Strimy a écrit :



A côté de ça, une appli WinRT va rassembler un gros paquet d’opérations en un seul draw call pour rendre des objets qui peuvent exploiter le même PS. Toutes les formes similaires sont rendues en une seule passe (en rassemblant un ensemble de visuel dans une même texture).





Oui mais comme je le disais ils ont aussi supprimé des fonctionnalités pour ça : par exemple les masques d’opacité ou le clipping non-rectangulaire qui rendent difficile le regroupement d’objets (nécessité de composer les shaders et fragmentation des batches, voire nécessiter de diviser certains objets ou de faire des calculs géos sur CPU), les bitmap effects personnalisés, etc. Ils ont simplifié de beaucoup le problème pour mieux le digérer.



Après il est certain que ce n’est pas la même génération, qu’ils ne visaient pas le même matériel, n’utilisaient pas les mêmes API et que le moteur n’a pas été mis à jour depuis. A l’époque où WPF est sorti la moitié des matériels n’avaient pas de pilotes installés et il fallait se borner à dx9.



Je m’insurgeais simplement contre l’idée que leur moteur serrait simpliste et qu’ils auraient simplement fainéanté. Les contraintes étaient très difficiles. Cela dit leur moteur batche quand même. Pas aussi souvent que possible mais il le fait.


votre avatar







seb2411 a écrit :



Ils peuvent forker QT sinon <img data-src=" />







QuickTime ? Aucun intérêt, mais Qt (qui se prononce cute) yep pourquoi pas !

Avec une interface en QML, ça devrait marcher sur toute les plateformes <img data-src=" />


votre avatar







youtpout978 a écrit :



En tout cas je ne me vois pas faire autre chose que du C# langage que j’ai choisit il y a 4 ans de ça au détriment de JAVA et ce choix je ne le regrette pas aujourd’hui parce qu’il me permet de faire du Web, du bureau et même du mobile (même multiplateforme avec mono) sans que la différence du code derrière soit énorme entre les plateformes.







Marrant, j’ai fait, depuis des décennies, le choix du C++, et je ne le regrette pas, pour C# j’ai beau me forcer (parce que j’ai des guru de C# pas loin qui ne jurent que par ça et qui peuvent m’aider) au final je refais tous mes softs en C++, d’une part parce que ça me donne le contrôle absolu de la façon dont il se déroule (ce qui est pour moi primordial), mais aussi parce que j’ai pas besoin de hacker le langage pour arriver à mes fins (voir les dizaines d’attributs C# pour arriver à quelque chose, sans parler du unsafe, ou des wrapper infâmes), et enfin parce qu’il est compatible C et donc n’importe qui, dans n’importe quel langage, n’importe quelle plateforme, peut recompiler et utiliser mes API … C# franchement à part remplacer VB et avoir une porte vers le web, bof bof … mono étant une vraie (mauvaise) blague …


votre avatar







catseye a écrit :



Marrant, j’ai fait, depuis des décennies, le choix du C++, et je ne le regrette pas, pour C# j’ai beau me forcer (parce que j’ai des guru de C# pas loin qui ne jurent que par ça et qui peuvent m’aider) au final je refais tous mes softs en C++, d’une part parce que ça me donne le contrôle absolu de la façon dont il se déroule (ce qui est pour moi primordial), mais aussi parce que j’ai pas besoin de hacker le langage pour arriver à mes fins (voir les dizaines d’attributs C# pour arriver à quelque chose, sans parler du unsafe, ou des wrapper infâmes), et enfin parce qu’il est compatible C et donc n’importe qui, dans n’importe quel langage, n’importe quelle plateforme, peut recompiler et utiliser mes API … C# franchement à part remplacer VB et avoir une porte vers le web, bof bof … mono étant une vraie (mauvaise) blague …







A chacun son langage de prédilection, j’utilise rarement d’API externe avec C# à part celle de win32 et j’ai toujours réussi à m’en sortir dans ce cas là.

Mais dans certain cas l’utilisation du c# n’est pas une bonne idée un logiciel de retouche photo ou vidéo en c# n’est pas forcément la panacée ou seulement pour la partie graphique.



Mono semble viable pour la partie mobile en tout cas, j’ai vu des boites réaliser des projets Android avec cette techno et c’est aussi utilisé dans Unity.


votre avatar







arno53 a écrit :



On en reparle sur la news du bilan financier de MS …





Je viens de regarder. Concernant IIS, MS est encore loin derrière Apache, même si MS monte en puissance. Concernant le big data, les gros sont Amazon et Google, et eux utilisent de la techno Linux.


votre avatar







youtpout978 a écrit :



Non il parle du J# qui a été rapidement abandonné.





Grâce à toi YoutPout, je sais à qui j’ai affaire.


votre avatar







jmanici a écrit :



IE9 sorti à peine après WPF?



WPF est sorti en 2006, et était en développement depuis 2002.



IE9 est sorti en 2010 en s’appuyant sur Direct2D et DirectWrite apparus en 2009 avec win7.



il y a quand même pas mal d’années entre ces technos, et on peut pardonner à l’équipe du .net Framework de ne pas avoir eu l’expertise d’une équipe entièrement dédiée à la création d’une API graphique.





WPF a été developpé par une équipe spécifique, constitué exprès, pas par l’équipe BCL (celle qui gère le coeur de .Net). Ensuite le WPF qu’on connait aujourd’hui est celui de la version 3.5.1, (après ça n’a plus évolué) sortie le 18/11/2008. Ca fait donc un an et demi avant la sortie du moteur d’IE9, c’est pas franchement énorme, et pourtant le gap technique était clairement là (surtout au niveau des drawcall, le truc le plus simple à analyser).



Mais non, je n’accuse pas l’équipe WPF d’avoir salopé le boulot, c’est juste que clairement ils n’avaient ni les compétences ni le temps pour optimiser la chose. A coté, t’as l’équipe IE9 qui a obtenu de l’équipe DirectX de l’aide, et qui donc a réussit. Et WinRT a continué sur ces acquis.



C’est bien pour ça que je disais que tout gain de perf passera par une intégration plus forte entre le framework graphique et une équipe de MS qui s’y connait en moteur graphique (en priorité l’quipe DirectX donc). Et pour le faire correctement, rien de mieux que de le mettre dans les specs de départ… Ca tombe bien, DirectX12 est encore en developpement !



Tous les espoirs sont donc permis.


votre avatar







HarmattanBlow a écrit :



Les contraintes étaient très difficiles. Cela dit leur moteur batche quand même. Pas aussi souvent que possible mais il le fait.





Même dans les cas simples (tu places 5 cercles noir opaques sur une page blanche, opaque) il ne batch pas (et dessine 5 cercles séparé). Et ce même sur une machine DX11 avec pilote ou je ne sais quoi : ce n’est pas géré du tout. La même chose avec la béta 1 d’IE9 ne fait qu’un seul dessin.



Après oui, ils avaient des contraintes importantes, genre 80% de leurs réunions tournaient autour du “mais comment on va faire bouger les dev de winforms à WPF alors qu’on a déjà pas réussit réussit à récupérer ceux qui étaient parti sur VB6 ?!”. Au final, le résultat est quand même une grande avancé (vectoriel &gt; bitmap), mais ne vient pas nous dire que WPF est optimisé, ce n’était pas leur principal soucis, et ça s’est senti.


votre avatar

En fait il essaient d’unifier les API graphiques du XAML ?

votre avatar







HarmattanBlow a écrit :



J’avoue que ça donne davantage envie que XAML. Je ne suis même pas sûr que ce soit moins puissant.





L’avantage du XAML n’a rien à voire avec la puissance du langage… le XAML n’est qu’une syntaxe qui est LARGEMENT assistée avec Visual Studio et, même si je ne connais pas ton… “Plasma”… je pense que l’intellisense encore naissante de MS, les IDE visuels qui n’existent quasiment pas dans la concurrence… tout cela marque largement la différence !



Attention, je ne dis pas que je ne sais pas me casser les couilles pendant plusieurs jours pour que l’interface soit redimensionnable à la perfection…. je dis juste qu’avec Visual Studio ça prend 5 mins… et l’DE a bien d’autres atouts !


votre avatar







Bejarid a écrit :



WPF a été developpé par une équipe spécifique, constitué exprès, pas par l’équipe BCL (celle qui gère le coeur de .Net). Ensuite le WPF qu’on connait aujourd’hui est celui de la version 3.5.1, (après ça n’a plus évolué) sortie le 18/11/2008. Ca fait donc un an et demi avant la sortie du moteur d’IE9, c’est pas franchement énorme, et pourtant le gap technique était clairement là (surtout au niveau des drawcall, le truc le plus simple à analyser).



Mais non, je n’accuse pas l’équipe WPF d’avoir salopé le boulot, c’est juste que clairement ils n’avaient ni les compétences ni le temps pour optimiser la chose. A coté, t’as l’équipe IE9 qui a obtenu de l’équipe DirectX de l’aide, et qui donc a réussit. Et WinRT a continué sur ces acquis.



C’est bien pour ça que je disais que tout gain de perf passera par une intégration plus forte entre le framework graphique et une équipe de MS qui s’y connait en moteur graphique (en priorité l’quipe DirectX donc). Et pour le faire correctement, rien de mieux que de le mettre dans les specs de départ… Ca tombe bien, DirectX12 est encore en developpement !



Tous les espoirs sont donc permis.









même en version 3.5.1 il n’y a pas eu changement en profondeur par rapport à la toute première version de WPF (3.0). Tout le boulot autour de WPF remonte à 2006 et avant.



mais bon je pense qu’à cette époque WPF devait déjà être conçu comme technologie de transition. Le but était pas d’avoir des perfs optimales, mais quelque chose qui puisse être utilisable par des développeurs Windows en entreprise qui peuvent pas jeter le legacy par la fenetre du jour au lendemain.



déjà en 2003 à l’époque de Longhorn on parlait déjà de modèle d’applis sandboxées. Ca a mis 10ans à se concrétiser avec WinRT. Et MS devait savoir déjà en 2006 que .net/WPF elle même ne serait pas utilisé comme API pour ce nouveau modèle d’application en l’état.

mais les idées autour de WPF et l’expérience de MS auront permis de faire mieux avec D2D et WinRT/XAML en évitant les erreurs de l’équipe WPF (plus jamais de BitmapEffect!)



au passage, WPF a été conçu pour être accéléré matériellement par du hardware directx9… Et directx7!

en fait un membre de l’équipe wpf avait dit à l’époque que tout à l’intérieur de WPF était basé sur les limitations de direct3d 7. Et il était question avec WPF4 de se baser uniquement sur dx9, mais apparemment ce développement n’a pas eu lieu.



donc effectivement on est assez loin de direct3d 10 et de direct2d en terme d’efficacité.


votre avatar







AxelDG a écrit :



L’avantage du XAML n’a rien à voire avec la puissance du langage… le XAML n’est qu’une syntaxe





Bien sûr, je parlais de l’ensemble techno + langage, cela me semblait évident. En pratique les deux sont indissociables même si n’importe qui pourrait développer un autre langage.





même si je ne connais pas ton… “Plasma”… je pense que l’intellisense encore naissante de MS, les IDE visuels qui n’existent quasiment pas dans la concurrence… tout cela marque largement la différence !



Je ne connais que peu “Plasma” et bien plus les technos XAML que j’ai utilisé régulièrement depuis la sortie de WPF jusqu’au Windows Store plus récemment. Suffisamment pour dire que l’outillage Xaml est une bouse infâme qui plante avec les trois quarts des projets WPF sur lesquels je travaille, m’affiche dans ces cas-là des centaines voire des milliers d’erreurs fantômes, est incapable de proposer la complétion de code neuf fois sur dix, et que l’éditeur WYSIWYG fonctionne tous les 29 févriers. Donc j’ai un peu de mal à te voir vanter les mérites de l’éditeur intégré à VS (même si dans certains petits projets ça fonctionne à peu près correctement) et je suis bien convaincu que n’importe quel concurrent fait mieux.



J’ai également assez d’expérience avec XAML pour dire que celui-ci est insupportablement et inutilement verbeux (et l’alternative consistant à coder l’UI en C# n’est pas réaliste), qu’il y a des lacunes (pas de support pour l’adaptation dynamique à des tailles différentes d’écrans, transitions Windows Store laissant à désirer, etc) et que le modèle MVVM nécessite toujours de faire appel à des plomberies plus ou moins heureuses mais toujours très lourdes. La techno derrière reste bonne, là n’est pas la question, c’est d’ailleurs celle que je privilégie, mais XAML est un boulet, VS un impotent avec cette techno, et il y a encore du travail pour la faire murir.



Pour le reste VS était un très bon IDE, très innovant, mais qui depuis quelques années souffre d’un nombre croissant de bogues dans les fonctions de base, notamment en étant de moins en moins apte à comprendre les erreurs de l’utilisateur et à faire avec. Pendant ce temps la concurrence ne chôme pas et ce qui était autrefois innovant est aujourd’hui un standard. Bref, autant dire que MS a intérêt à s’activer parce que leur techno est quasi-exclusive à la plateforme MS, que celle-ci est en perte de vitesse et que même si leur plateforme reste techniquement supérieure l’écart s’est fichtrement réduit et les plateformes concurrentes ont dépassé MS sur de nombreux points, qu’il s’agisse de JS+html, d’Apple, de Qt Quick, etc.


votre avatar







arno53 a écrit :



Ca semble vrai mais les changements majeurs d’interfaces sont sur une autre branche de développement qui n’a pas encore été mergé avec celle-ci … Du coup l’interface général du Bureau de Windows 9 reste un mystère … Mais concernant ce nouveau menu, je le trouve trop classique … Pourquoi ne pas le faire monter jusqu’au haut de l’ecran comme dans ce concept <img data-src=" /> Bon celui-ci est sensé être flexible et s’élargir si il y’a beaucoup de LiveTiles mais je suis un peu déçu pour l’instant …









sleipne a écrit :



Excellent concept en effet, le meilleur des 2 mondes :)



Cà a de l’allure… <img data-src=" />

Ce que j’attends surtout c’est une ergonomie vraiment retravaillée et une prise en charge matérielle sans faille… parce que w8/8.1, certes très stable, pêche sur ces 2 points.


votre avatar

La première pensée que j’ai lu en lisant l’article de Vincent-à-la-sword-brillante, c’est : “pourquoi MS reproduit-il la même erreur ?”. Je m’explique. On a vu que Windows8 est loin de faire l’unanimité avec son interface pensée tactile pour une utilisation clavier+souris. Il est vrai que le menu démarrer avait sérieusement besoin d’une réforme, je m’en rends bien compte quand sur mon W7 je n’y vais que pour créer un raccourci sur le bureau ; le menu bien rangé de Cinnamon est parfait à mes yeux (du coup pas besoin de raccourcis sur le bureau). Là, MS semble penser aux développeurs, en leur tenant un discours “vous n’aurez plus qu’une seule toolbox à apprendre, pour développer partout”. Ça va certainement faire plaisir aux recruteurs qui vont encore plus corvéer leurs développeurs et n’auront plus à gérer séparément les pros du PHP et les pros du noyau temps réel. Je vois au contraire se pointer une baisse globale de la qualité et des performances, et ce pour plusieurs raisons :

-1 : un truc généraliste fait tout médiocrement, un truc spécialiste ne fait qu’un truc, mais le fait mieux (en principe, il y a des contre-exemples comme le noyau linux par exemple qui réussit l’exploit d’être généraliste, de tourner sur tout et de rester performant). C’est vrai pour la toolbox qui va devoir faire d’un coté du tactile sur écran rikiki de téléphone et en même temps du gros progiciel géré au clavier et à la souris sur écran de PC. On a vu ce que ça a donné avec W8.

-2 : les développeurs qui tomberont dans cette techno ne se spécialiseront pas dans un domaine particulier, et donc ne seront pas capables d’optimiser

-3 : ça rajoute encore une couche d’abstraction au dessus du système, qui, là encore, comme dit dans les posts précédents à propos de WPF, ne permet pas d’optimiser.

On dirait que l’obsession de MS est de créer un mille feuille de ses systèmes, pour éloigner de plus en plus le matériel, le noyau et à l’autre bout l’utilisateur. Midori semble tenir du même acabit, avec un code noyau développé en C#, un spinoff de C++ lui même dérivé du bon vieux C de Kernighan, Ritchie et Thompson. C’est peut-être une bonne idée commercialement, je doute que ça en soit une techniquement.

votre avatar







CaptainDangeax a écrit :



-3 : ça rajoute encore une couche d’abstraction au dessus du système, qui, là encore, comme dit dans les posts précédents à propos de WPF, ne permet pas d’optimiser.



On dirait que l’obsession de MS est de créer un mille feuille de ses systèmes, pour éloigner de plus en plus le matériel, le noyau et à l’autre bout l’utilisateur. Midori semble tenir du même acabit, avec un code noyau développé en C#





ça remplace une couche d’abstraction par une autre ça n’en rajoute pas..

Les amélioratons prévu pour DX12 ont justement pour but de réduire cette couche d’abstraction API/Materiel.



Ce nouveau framework sera à fortiori basé sur ce nouveau DX ( ou pas si c’est compatible win 8/.1 mais avec les rumeurs d’update gratuite tout ça ..) donc tant que rien est annoncé, difficile de leur lancer la pierre..



Concernant Midori, sans dire de bêtise , c’est pas du c#, mais un autre langage M# ( Tada on change une lettre ça change tout ! ), proche syntaxiquement certes, donc on ne peut pas se baser sur les perfs du c# pour dire si ça sera bien ou pas. Charon l’explique bien et en parle depuis plusieurs années.


votre avatar







Adrian Shephard a écrit :



Non en fait je retire ce qui serait vraiment bien c’est de pouvoir écrire des interfaces entièrement en html/javascript. Comme ça on pourrait utiliser les outils qu’on veut, que ça soit pour générer du html ou javascript, et arrêter de se demander à longueur de temps pour quelle plateforme on écrit.





Le problème c’est que le html / javascript ça reste pas mal dépendant du navigateur pour l’instant.


votre avatar







Firefly’ a écrit :



ça remplace une couche d’abstraction par une autre ça n’en rajoute pas..

Les amélioratons prévu pour DX12 ont justement pour but de réduire cette couche d’abstraction API/Materiel.



Ce nouveau framework sera à fortiori basé sur ce nouveau DX ( ou pas si c’est compatible win 8/.1 mais avec les rumeurs d’update gratuite tout ça ..) donc tant que rien est annoncé, difficile de leur lancer la pierre..



Concernant Midori, sans dire de bêtise , c’est pas du c#, mais un autre langage M# ( Tada on change une lettre ça change tout ! ), proche syntaxiquement certes, donc on ne peut pas se baser sur les perfs du c# pour dire si ça sera bien ou pas. Charon l’explique bien et en parle depuis plusieurs années.





Oui et midori c’est tout le contraire de rajouter des couches d’abstractions. ils reprennent de zero des concepts qui ont plus de 30 ans sur les OS. Et midori serait surtout beaucoup plus léger que windows.



Pour WinRT je me souviens qu’ils ont viré certains features de WPF comme les bitmap effect justement car elles n’étaient pas accélérés par le GPU. Après je doute que faire la même chose en GDI soit meilleur niveau performance et je ne parle même pas de la complexité du code.


votre avatar







CaptainDangeax a écrit :



La première pensée que j’ai lu en lisant l’article de Vincent-à-la-sword-brillante, c’est : “pourquoi MS reproduit-il la même erreur ?”. Je m’explique. On a vu que Windows8 est loin de faire l’unanimité avec son interface pensée tactile pour une utilisation clavier+souris. Il est vrai que le menu démarrer avait sérieusement besoin d’une réforme, je m’en rends bien compte quand sur mon W7 je n’y vais que pour créer un raccourci sur le bureau ; le menu bien rangé de Cinnamon est parfait à mes yeux (du coup pas besoin de raccourcis sur le bureau). Là, MS semble penser aux développeurs, en leur tenant un discours “vous n’aurez plus qu’une seule toolbox à apprendre, pour développer partout”. Ça va certainement faire plaisir aux recruteurs qui vont encore plus corvéer leurs développeurs et n’auront plus à gérer séparément les pros du PHP et les pros du noyau temps réel. Je vois au contraire se pointer une baisse globale de la qualité et des performances, et ce pour plusieurs raisons :

-1 : un truc généraliste fait tout médiocrement, un truc spécialiste ne fait qu’un truc, mais le fait mieux (en principe, il y a des contre-exemples comme le noyau linux par exemple qui réussit l’exploit d’être généraliste, de tourner sur tout et de rester performant). C’est vrai pour la toolbox qui va devoir faire d’un coté du tactile sur écran rikiki de téléphone et en même temps du gros progiciel géré au clavier et à la souris sur écran de PC. On a vu ce que ça a donné avec W8.

-2 : les développeurs qui tomberont dans cette techno ne se spécialiseront pas dans un domaine particulier, et donc ne seront pas capables d’optimiser

-3 : ça rajoute encore une couche d’abstraction au dessus du système, qui, là encore, comme dit dans les posts précédents à propos de WPF, ne permet pas d’optimiser.

On dirait que l’obsession de MS est de créer un mille feuille de ses systèmes, pour éloigner de plus en plus le matériel, le noyau et à l’autre bout l’utilisateur. Midori semble tenir du même acabit, avec un code noyau développé en C#, un spinoff de C++ lui même dérivé du bon vieux C de Kernighan, Ritchie et Thompson. C’est peut-être une bonne idée commercialement, je doute que ça en soit une techniquement.


Le but de Microsoft est de gagner de l’argent en gagnant des part de marché.



Windows a toujours été un système d’exploitation populaire et bien implanté chez les particuliers. Et Microsoft a toujours utilisé cet atout pour gagner les autres part de marché dans les autres segments (entreprise, serveurs, console, etc.).



Le but de Microsoft en faisant une plate-forme unique est que tous les développeurs actuellements compétents sous Windows le soient aussi instantanément sous Windows Phone. (C’était déjà le même but avec Windows CE, puis WIndows Mobile.) Ce qui signifie davantage d’applicaitons sur cette plate-forme, des compétences largement disponibles, et donc des coût de développement moindre, et tout ça pour faire pencher le choix de la plate-forme vers Windows Phone plutôt qu’Android ou iOS.



Tu parles d’optimisation, mais qui en a besoin ?

95% du développement en France ce sont des application de gestion, dont on se fout de l’optimisation. Ça coûte moins cher d’acheter un PC plus puissant que de payer des programmeurs à optimiser un algo de tri des numéro de facture. Après que ça soit de l’optimisation pour afficher des effets de dégrader ou de brillance, franchement on s’en fout.



Sinon puisque tu parles du langage, ce qu’on voit actuellement c’est que Microsoft revient sur son langage de prédilection : le C++ (Tous les Windows sont programmés en C++). Lire par exemple cet article.


votre avatar







Mudman a écrit :



Tu parles d’optimisation, mais qui en a besoin ?

95% du développement en France ce sont des application de gestion, dont on se fout de l’optimisation. Ça coûte moins cher d’acheter un PC plus puissant que de payer des programmeurs à optimiser un algo de tri des numéro de facture. Après que ça soit de l’optimisation pour afficher des effets de dégrader ou de brillance, franchement on s’en fout.



Sinon puisque tu parles du langage, ce qu’on voit actuellement c’est que Microsoft revient sur son langage de prédilection : le C++ (Tous les Windows sont programmés en C++). Lire par exemple cet article.





Tu fais les questions et les réponses. Tu demandes qui a besoin d’optimisation ? Les possesseurs de trucs sur batterie justement, les téléphones mobiles et les tablettes où le but est d’avoir le code le plus efficace possible, car moins de cycle CPU égale moins de consommation de jus et donc plus d’autonomie. Mais là, je vois une contradiction. Un nouveau framework pour les unir tous, et pour développer en quel langage ? C++ compilé donc plus efficace ? C# semi interprété donc plus de cycles machines ? VBA ? Non c’est pour déconner que j’écris VBA… Encore un nouveau truc avec un mille-feuille de couches d’interprétation ? Et puis de toute façon, c’est plateforme MS only. MS est largement majoritaire sur le PC de bureau, mais si on compte tout ce qui est vendu et qui a un processeur, leur part de marché n’est plus que de 14%… La mobilité, l’embarqué, le temps réel, le serveur web, le big data, le gros serveur de calcul qui poutre sont des marchés où MS n’est qu’un outsider. Alors le développeur qui se spécialise sur cette nouvelle techno MS, il y a des chances qu’il ait du taf’, certes, mais fait-il le meilleur choix pour sa carrière ?

Je reviens sur le C#. Je trouvais bizarre que MS n’utilise pas cette plateforme pour ses propres applis (par exemple Office). Là s’ils reviennent au C++ est-ce donc qu’ils tuent le C# (ou qu’ils le laissent mourir comme ils ont laissé mourir leur version maison de Java) ?


votre avatar







CaptainDangeax a écrit :



Tu fais les questions et les réponses. Tu demandes qui a besoin d’optimisation ? Les possesseurs de trucs sur batterie justement, les téléphones mobiles et les tablettes où le but est d’avoir le code le plus efficace possible, car moins de cycle CPU égale moins de consommation de jus et donc plus d’autonomie. Mais là, je vois une contradiction. Un nouveau framework pour les unir tous, et pour développer en quel langage ? C++ compilé donc plus efficace ? C# semi interprété donc plus de cycles machines ? VBA ? Non c’est pour déconner que j’écris VBA… Encore un nouveau truc avec un mille-feuille de couches d’interprétation ? Et puis de toute façon, c’est plateforme MS only. MS est largement majoritaire sur le PC de bureau, mais si on compte tout ce qui est vendu et qui a un processeur, leur part de marché n’est plus que de 14%… La mobilité, l’embarqué, le temps réel, le serveur web, le big data, le gros serveur de calcul qui poutre sont des marchés où MS n’est qu’un outsider. Alors le développeur qui se spécialise sur cette nouvelle techno MS, il y a des chances qu’il ait du taf’, certes, mais fait-il le meilleur choix pour sa carrière ?

Je reviens sur le C#. Je trouvais bizarre que MS n’utilise pas cette plateforme pour ses propres applis (par exemple Office). Là s’ils reviennent au C++ est-ce donc qu’ils tuent le C# (ou qu’ils le laissent mourir comme ils ont laissé mourir leur version maison de Java) ?







Je pense que le C# vivra encore longtemps même s’ils l’abandonnent dans 5 ans les anciens projets codé dessus continueront d’exister encore des décennies pour certain, et bon le concept du langage est assez proche d’autre langage ce qui permet de pouvoir passer sur d’autre langage assez facilement.



Je ne suis pas sur qu’un programme développé en C# soit plus énergivore qu’un autre développé en Java pour Android, et souvent ces programmes ne sont pas des monstres dévoreur de batterie comme peuvent l’être certain jeu qui eux sont souvent développé en c++ donc pas sur que tu vois une grosse différence si demain toutes les applis sont développé en c++ plutôt qu’en C#.

Et bon que ça soit un programme codé dans n’importe quel langage il est souvent possible de l’optimiser mais ça c’est plus dépendant du dev que du langage en lui même.



En tout cas je ne me vois pas faire autre chose que du C# langage que j’ai choisit il y a 4 ans de ça au détriment de JAVA et ce choix je ne le regrette pas aujourd’hui parce qu’il me permet de faire du Web, du bureau et même du mobile (même multiplateforme avec mono) sans que la différence du code derrière soit énorme entre les plateformes.


votre avatar







CaptainDangeax a écrit :



Tu fais les questions et les réponses. Tu demandes qui a besoin d’optimisation ? Les possesseurs de trucs sur batterie justement, les téléphones mobiles et les tablettes où le but est d’avoir le code le plus efficace possible, car moins de cycle CPU égale moins de consommation de jus et donc plus d’autonomie. Mais là, je vois une contradiction. Un nouveau framework pour les unir tous, et pour développer en quel langage ? C++ compilé donc plus efficace ? C# semi interprété donc plus de cycles machines ? VBA ? Non c’est pour déconner que j’écris VBA… Encore un nouveau truc avec un mille-feuille de couches d’interprétation ?





Eh … Entre Apple,Google et MS c’est bien ce dernier qui se soucie le plus de l’autonomie … Y’a qu’a voir le fonctionnement de WinRT, le rassemblement d’alarme dans le noyau présent depuis Windows 7 (2009) et là ou Apple n’a retravaillé ce point qu’a partir de OS X Mavericks (2013), l’utilisation toujours plus massive de l’accélération matériel etc …



Et puis de toute façon, c’est plateforme MS only. MS est largement majoritaire sur le PC de bureau, mais si on compte tout ce qui est vendu et qui a un processeur, leur part de marché n’est plus que de 14%… La mobilité, l’embarqué, le temps réel, le serveur web, le big data, le gros serveur de calcul qui poutre sont des marchés où MS n’est qu’un outsider. Alors le développeur qui se spécialise sur cette nouvelle techno MS, il y a des chances qu’il ait du taf’, certes, mais fait-il le meilleur choix pour sa carrière ?



On en reparle sur la news du bilan financier de MS …



Je reviens sur le C#. Je trouvais bizarre que MS n’utilise pas cette plateforme pour ses propres applis (par exemple Office). Là s’ils reviennent au C++ est-ce donc qu’ils tuent le C# (ou qu’ils le laissent mourir comme ils ont laissé mourir leur version maison de Java) ?



Eh le Java de MS c’est le C# non ?

Sachant qu’ils sont en train de faire un OS quasi-entièrement en un dérivé du C#, je ne pense pas qu’il soit en train de mourir … bien au contraire …



votre avatar







arno53 a écrit :



Eh le Java de MS c’est le C# non ?

Sachant qu’ils sont en train de faire un OS quasi-entièrement en un dérivé du C#, je ne pense pas qu’il soit en train de mourir … bien au contraire …







Non il parle du J# qui a été rapidement abandonné.


votre avatar

Ils peuvent forker QT sinon <img data-src=" />

votre avatar

N’empêche sur le coup, On peut reprocher beaucoup de choses à Ubuntu mais ils avaient bien vu venir le truc d’avenir …



Microsoft et son concept d’interface unifiée ( un SDK pour les dominer tous ).

Google idem, et je serai pas étonnée que Chrome OS ne s’enrichisse encore dans les années à venir pour par ex permettre à des trucs genre Android Studio de marcher ;) )

Apple : idem, mais ils prennent leurs temps, et c’est pas plus mal. Lentement mais sûrement

votre avatar

Les applis metro sur Xbox One, voilà qui rendrait cette console bien intéressante à mes yeux…

votre avatar

Je suis hyper curieux de voir ce que va être la nouvelle interface de MS sur Windows 9 ^^

votre avatar







Thoscellen a écrit :



Je suis hyper curieux de voir ce que va être la nouvelle interface de MS sur Windows 9 ^^







A prendre avec les pincettes d’usage :

theverge.com The Verge


votre avatar

Qt existe, pourquoi réinventer la roue ?

votre avatar

Il leur a juste fallu 5 ans pour comprendre ça…



C’est pas gagné.



Moi j’aimerai qu’il fasse l’inverse dans l’environnement pro et qu’il nous vire Modern UI

votre avatar







romainsromain a écrit :



N’empêche sur le coup, On peut reprocher beaucoup de choses à Ubuntu mais ils avaient bien vu venir le truc d’avenir …



Microsoft et son concept d’interface unifiée ( un SDK pour les dominer tous ).

Google idem, et je serai pas étonnée que Chrome OS ne s’enrichisse encore dans les années à venir pour par ex permettre à des trucs genre Android Studio de marcher ;) )

Apple : idem, mais ils prennent leurs temps, et c’est pas plus mal. Lentement mais sûrement





Pour Apple y’a pas vraiment de mouvent d’unification pour l’instant … Cocoa et Cocoa Touch reste assez éloigné l’un de l’autre d’après ce que j’ai compris et il est pas possible de récupérer une grosse partie de l’App iOS pour la porter vers Mac… Apple se contente juste de proposé ses apps (Plan) ou certaines fonctionnalité sur ses 2 support.



Pour Google, ils ont annoncé à la Google I/O que les apps Android tourneront sur Chrome OS mais ils n’ont pas plus détaillé que ça <img data-src=" /> C’est soit les apps Android qui tournent dans NaCl sur Chrome(OS) ce qui serait vraiment très intéressant soit juste que le nom de l’application qui pointe vers la version Android (Java) et vers la version Web App (javascript/html ou en C via NaCl je crois) mais là pour le coup d’un point de vu développement ca change pas grand chose <img data-src=" />



Pour Ubuntu, est ce que les apps sont sandboxé par défaut ? Ca serait a la limite le point faible de la solution si ce n’est pas le cas … Enfin le plus gros problème reste les part de marché et la visibilté <img data-src=" />



En tout cas si Microsoft peut enfin unifier tout ce qui touche au XAML en prenant les points fort de WPF et Silverlight ca va vraiment devenir intéressant … Il faudra surement attendre 2020 et la fin de support de Windows 7 pour que ça soit massivement utilisé (et a condition que ca soit retroporté sur Windows 8) mais c’est deja un bon pas en avant …



Par contre j’ai l’impression qu’il y’a pas mal de critique sur les performances du XAML … True or not ?


votre avatar



Avec Windows Threshold, Microsoft a l’occasion de faire un grand pas vers le Graal longtemps cherché par l’entreprise : une même base technique pour tous les supports.





C’est peut-être le Graal de l’entreprise Microsoft…



Mais pour le reste du monde, le Graal ca serait d’unifier Windows Home/Pro, IOS, Android, Wordpress/joomla et PlayStation… <img data-src=" />

Oui, Microsoft travaille bien sur un framework graphique unifié

  • Un framework unique pour l'ensemble des supports 

  • Pourquoi un seul framework ?

Fermer