Microsoft propose depuis vendredi soir deux nouvelles builds à destination des testeurs. La première est numérotée 17123 pour la branche Redstone 4, l’autre 17623 pour la branche Redstone 5.
Les deux ont en commun d’introduire un support initial du HEIF, un format d’image utilisé notamment par Apple, par défaut depuis iOS 11. Selon Microsoft, la demande est devenue régulière, le format se voulant plus économe en espace disque que le JPEG, à niveau similaire de qualité.
L’installation de ces builds ne suffit cependant pas. Il faut en plus avoir activé le Windows App Preview Program dans les options de l’application Photos, ce qui déclenche le téléchargement d’une version adaptée. Malheureusement, tout le monde n’a pas accès à ce réglage. Si vous l’avez, Photos proposera automatiquement de récupérer les extensions HEIF et HEVC depuis le Store.
Notez que l’on ne parle pour l’instant que d’ouverture des images en HEIF, pas de leur édition. Microsoft laisse entendre toutefois que la fonctionnalité arrivera plus tard.
Pour le reste, la build 17123 n’apporte que des corrections (il n’y a plus qu’un seul bug connu). Normal, puisque la branche RS4 débouche sur la mise à jour majeure 1803 pour Windows 10, qui sera distribuée le mois prochain.
La build 17623 intègre en revanche d’autres nouveautés, notamment une icône dans la zone des notifications pour débrancher en sécurité un GPU externe. Plusieurs améliorations sont également présentes pour Windows Defender Application Guard, comme de meilleures performances et la possibilité de télécharger un fichier depuis une session WDAG d’Edge.
Puisque l’on parle du navigateur, Microsoft va lancer un test qui risque de faire grincer quelques dents : dans la build 17623, les utilisateurs de Courrier auront peut-être la surprise de voir les liens s’ouvrir dans Edge au lieu de leur navigateur par défaut.
Il est probable que ce petit changement agacera bon nombre de testeurs. L’éditeur évoque la sécurité comme raison principale, mais la décision ressemble surtout à du « vieux Microsoft », quand l’entreprise aimait tout verrouiller autour de ses solutions.
Commentaires (8)
#1
Toujours cette foutue dyslexie quand je lis “préversions” à coté de windows 10.
dans la build 17623, les utilisateurs de Courrier auront peut-être la surprise de voir les liens s’ouvrir dans Edge au lieu de leur navigateur par défaut.
Ca ne s’appelle pas une surprise mais un bug. Microsoft, comme à son habitude, appellera surement cela une fonctionnalité avec sans doute une excuse de sécurité, bla bla bla…
#2
c’est une version alpha de windows pour des fonctionnalité qui sortiront dans 6 mois, ils le testent ensuite le fixeront, rien d’anormal…
#3
C’est marrant cette ouverture des liens internet avec Edge au lieu du navigateur par défaut. Ça fait presque penser au menu démarrer qui mélange des liens Edge & bing avec les résultats locaux.
A quand l’interdiction d’avoir un navigateur par défaut autre qu’Edge ? (pour notre sécurité)
#4
Je me fait l’avocat du diable, mais il me semble que le moteur de rendu de Edge est le moteur de rendu de Windows pour de l’HTML/CSS/javascript.
Ensuite, Courrier, si j’ai bon souvenir est une application UWP, donc passe par les API de la plateforme. Quid de savoir si les autres navigateurs s’interface avec cette API.
#5
Les autres navigateurs ont l’API, c’est un simple lien. D’ailleurs, aujourd’hui, ça marche très bien.
Et s’ils n’avaient pas l’API, il suffirait de la publier pour que les autres navigateurs puissent (ou pas), l’implémenter. Aucune raison technique de le bloquer, c’est juste de l’abus de position.
#6
J’attends la pré-release moi, puisque je ne peux pas basculer quand je veux entre les Ring.
#7
Je parle de l’API UWP, il faudrait que les navigateurs y soit déclaré comme capable d’ouvrir ces liens.
Ma première hypothèse général est que Courrier demande à l’API UWP d’ouvrir un lien. L’API ouvre le lien avec Edge. Du coup, ma première question serait de valider cette hypothèse.
Ensuite, si l’hypothèse précédente est validé, il nous manque une étape : est-ce que le choix de Edge se fait comme pour Android, par association de protocole avec l’outil.
Si oui, est-ce qu’il est possible de déclarer un autre outil ?*
Si oui, est-ce qu’il existe un autre outil ?
* : La grosse limitation que je connais par rapport à UWP, c’est que pour être disponible sur le store, toutes applications vouant rendre du HTML/Javascript doit utiliser le moteur de rendu de l’API. Il est possible cependant de proposer des application UWP sans être disponible sur le store, mais bon, ni firefox ni chrome n’ont réellement proposer de truc là dessus (peu d’intérêt pour trop de contrainte). L’extension de la question est du coup de savoir s’il est possible de se déclarer à l’API comme compatible avec certain protocole sans pour autant être une application UWP.
#8