TImaniac a écrit 6420 commentaires

Après vérification il y a beaucoup plus qu'un parseur XML, il y a toutes les libs de base du Framework .NET existant, mais c'est pas sur le même repo, d'où la confusion :
https://github.com/Microsoft/referencesource
Même si ce repo n'évoluera pas, il est destiné à alimenter le repo .NET Core.

L’œil est facilement trompé et de plus il est plutôt difficile de rester objectif.

En même temps c'est le but d'une vidéo non ? Donner une illusion de réel en mouvement à ta rétine.

Ben déjà t'as Office sous Android, pas encore aussi complet que sous Windows mais il avance. De là faire un lien entre Android et Linux il n'y a qu'un pas que je ne franchirai pas.

C' est vrai pour ce qui concerne la nouvelle brique qui s'appelle .NET Core, mais j'ai essayé de montrer dans la dépêche que cette libération s'inscrit dans une démarche plus large qui regroupe d'autre parties essentielles de la stack web : le nouveau compilateur Roselyn et le framework ASP.NET, libérés récemment, qui ne se limite pas à 2 ou 3 classes.
Bref c'est pas uniquement des mots, juste une étape logique supplémentaire pour proposer une stack complète.

Si tout le code était là, il aurait fallu utiliser le passé composé : "Microsoft a libéré". S'ils avaient l'intention de le faire mais que rien n'était là, il aurait fallu utiliser le futur : "Microsoft libérera". Là on parle bien d'une libération "en cours", d'une action qui se déroule en ce moment, ce qui correspond parfaitement à l'utilisation du présent, ce qui explique ton constat : ce n'est que le début, quelques bibliothèques pour le moment.

J’espère que pour Microsoft, ce n'est pas non plus une façon déguisée d'abandonner ses technos.

Bof, il y a une grosse différence : Adobe a "donné" à un tiers le code d'une plateforme existante. Là Microsoft met à disposition des technos nouvelles en cours de développement.

Donc il n'est pas question d'utiliser des parties de ce code pour un autre projet ou même de modifier son runtime "officiel".

Si, la seul contrainte, c'est que ton projet reste compatible avec le standard ECMA-335. Pour ce qui n'est pas couvert par le standard ECMA (les autres API MS), il faut que ca reste compatible avec la doc officielle de MS.

Tu as raison de signaler que c'est une limite importante, qui empêche théoriquement un concurrent de faire un dérivé non compatible (genre le conflit Google/Oracle autour de Java), mais ca laisse tout de même la possibilité de faire plein d'améliorations : correction de bugs, améliorer les performances, faire un portage vers une autre plateforme, etc.

C'est justement parce que Mono a échoué à sortir .NET de la niche Microsoft qu'on en est arrivé là.

Mono est sans doute le runtime alternatif le plus utilisé sur Android et iOS, notamment à travers le moteur de jeu Unity… Si c'est pas sortir de la niche Microsoft ça.

Ce que vise MS à travers cette ouverture de code, et que ne vise pas Icaza avec Xamarin, ce sont les serveurs.

Asp.net 5 tourne déjà sous Linux, suffit de voir la doc d'install sur github, il y a la procédure d'install pour Linux de proposée : https://github.com/aspnet/home
Ce qui manque pour le moment, c'est le runtime de MS, pour le moment il faut le runtime Mono.

La menace des brevets plane toujours;

https://github.com/dotnet/corefx/blob/master/PATENTS.TXT

Mouais enfin là Samsung n'arrête pas de payer à cause de la validité des brevets mais parcque Samsung estime que le rachat de Nokia par MS modifie les conditions de leur contrat. Ne connaissant pas ce contrat, difficile de dire si les autres constructeurs peuvent se permettre de prendre le même chemin que Samsung.

C'est exactement le contexte de cette annonce : Samsung a arrêté de payer depuis quelques mois, MS attaque et a dû publier des chiffres, d'où ce journal.

Windows 8 cela disparait de tous les pc que je vois. En fait la premiere chose que TOUT le monde demande lorsqu'un pc arrive avec ce truc c'est "mets moi windows 7 s'il te plait".

Y'a ta vision et la réalité :

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=11&qpcustomb=0&qpsp=164&qpnp=25&qptimeframe=M

se fermer les autres marches

Tu te fermes rien du tout : vous vous rendez pas compte que le coût de dev c'est peanuts à côté des coûts marketing et le test/validation d'un business model. S'ils font pas direct une appli cross-platfrom, c'est juste parcque c'est pas un besoin en soit : quand y'a plus qu'à recoder une appli sur une autre plateforme une fois le business model et le succès testé, c'est juste aligner quelques K€, OSEF des gains du Framework compatible.

Ils ont oublié Modern UI ;-)

J'ai dis "Windows". C'est toi qui n'est pas moderne, Microsoft a abandonné cette appellation depuis longtemps :)

Qui utilise Xamarin ?

D'après leur site 15 000 clients.

Il me semble qu'à l'heure actuelle il est impossible d'avoir une application telle que celle que tu décris : c'est à dire qui soit "platform look compliant" et "plateform specific"

CQFD.

C'est pour cela qu'aujourd'hui les décideurs se concentrent généralement sur 1 ou 2 plateforme dans un premier temps. Etre cross-Platform n'est pas une fin en soit : l'objectif est déjà de tester une appli sur un périmètre précis (exemple typique : iOS), tout en s'assurant que la première impression laissé soit la bonne.

Bref, à budget équivalent, mieux vaut peaufiner une application native sur une seule plateforme que de chercher à faire du cross-Platform.

Le reste ferait des compromis que tu sembles vouloir rejeter.

Ou comment s'assurer que son application fera un bide.

Ca c'est pour les OS grands public. Après comme je l'ai dit plus haut, Qt peut avoir un intérêt dans l'embarqué, là où l'utilisateur n'a que peu d'attache/habitude avec un écosystème.

Et si moi, développeur d'application, je juge que la meilleure façon de parcourir les infos de mon application, c'est verticalement, même sous windows phone, est-ce que je dois sacrifier mon point de vue au nom de la sacrée saint cohérence ergonomique ?

Non tu fais ce que tu veux. Par contre si tu veux que ton application "plaise" à tes utilisateurs, il te faut faire des choix qui ne sont pas forcement identique d'une plateforme à l'autre : les habitudes des utilisateurs varient en fonction de leur plateforme.

Des avantages et des inconvénients sont présents dans les deux camps. Je pense par exemple à Blender qui propose une IHM très singulière

C'est l'autre solution : si tu as des choix esthétiques et ergonomiques fortement marqués, léchés qui contribuent à l'identité de ton application, oui tu peux te permettre d'avoir quelque chose de très similaire sur chaque plateforme. Mais autant dire que c'est très très loin d'être un luxe que peuvent se permettrent 90% des applications que tu trouves sur les stores. Et en général quand tu as ce "luxe", c'est que tu as des moyens, et franchement tu te poses même pas la question d'utiliser Qt : tu parts sur du natif.

A la bourre ?

Nan attend je peux le relancer :)

personnellement je pense que le bon Framework c'est Xamarin.
L'intro du site parle d'elle même :
"Create native iOS, Android, Mac and Windows apps in C#."

Ben si la dernière justement : intégré "Facebook Messenger", application en code natif, dans l'application "Facebook" devenait une obligation.
Imagine le résultat s'ils avaient choisient Qt pour l'application "Facebook" : non seulement c'est compliqué techniquement mais en plus on aurait une expérience utilisateur différente d'une partie à l'autre de l'appli. Tout simplement pas acceptable.

désolé mais je vois pas le truc

Je pense qu'on ne parle pas de la même chose. Tu semble considérer uniquement les OS desktop. Là le débat est beaucoup plus large et intègre Android, iOS et Windows RT (8 et Phone), plateforme maintenant supportées par Qt.
Tout mes exemples d'intégration concernent ces plateformes "modernes", qui vont remplacer à terme les anciennes plateformes : qu'on soit d'accord ou pas, les Google, Apple et Microsoft poussent ces nouveaux environnements, ce qui impliquent des contraintes d'intégration nouvelles, pour des raisons à la fois techniques mais aussi d'attente utilisateur en terme d'expérience.

Peux-tu être plus précis ?

Ben par exemple regarde l'appli 20 minutes sur Windows Phone :
http://screenshots.fr.sftcdn.net/fr/scrn/3346000/3346508/20minutes-fr-02-321x535.png
L'application utilise les codes de design Windows Phone : ensemble des contenus dans une page (panorama) qui défile horizontalement.

Maintenant la même chose sur iOS :
http://actu.meilleurmobile.com/wp-content/uploads/2012/07/20minutes-200x300.jpg
Défilement vertical, menu en haut, etc.

Il y a à la fois des différences graphiques, des différences d'ergo, de navigation, d'architecture d'enchaînement des écrans.

Sans parler de l'intégration avec l'OS : personnalisation de l'écran d'accueil pour afficher les dernières news, téléchargement en background dans un agent "controllé" par l'OS pour éviter le réveille de toute l'application et ainsi avoir un contrôle fin sur les jobs qui tournent, leur durée de vie, la gestion de la batterie, etc.
```

Pour MacOSX je ne sais pas mais pour Android la raison en est tout simplement parceque Qt ne supporte pas encore cette plateforme?

Ben si :
http://qt-project.org/doc/qt-5/winrt-support.html

Amusant de voir que malgre le fait que Microsoft le rende de pire en pire ils ne sont toujours pas passe a C#…

A ton avis elle est faite en quoi l'appli Skype pour Windows 8 et Windows Phone ? Un indice : c'est pas du Qt ;)

la discussion partait d'une application "métier" dont le commanditaire n'a pas les moyens de se payer 2 GUI, d'où l'intérêt financier théorique d'une appli cross-Platform.
Il est évident que Facebook a les moyens d'offrir une expérience optimale à ses utilisateurs et que le coût est un détail insignifiant.
D'ailleurs ils ont conservé une partie en HTML5 pour les parties de code qui change très souvent (lié au site web), bref rien à voir avec une question de coût encore une fois.

Entre autre, si tu lis leur histoire officielle, les raisons sont multiples :
- performances (web vs native)
- performances (architecture, rien à voir avec la techno)
- intégration d'une application existante écrite en code natif : Facebook Messenger

https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920