Sailfish OS et Wayland la solution «futureproof»

L'organisation de Sailfish OS
L’organisation de Sailfish OS

Maintenant que Jolla a annoncé que Sailfish OS allait utiliser Wayland, il est intéressant de regarder pourquoi ce choix technique a été fait.

Un monde de robots

Il ne faut pas se voiler la face, Android domine actuellement le marché du mobile, et il est devenu une norme pour ce marché. La plupart des développements, tant matériels que logiciels, gravitent autour de cet OS. Même si les créateurs d’applications hésitent parfois à cibler cette plateforme, les constructeurs de matériel ont très souvent tendance à ne supporter qu’Android, un peu comme avec Windows dans le monde des PC.

Mais à la différence de l’OS aux fenêtres multicolores, Android est Open-source, ce qui a permis la création d’une grande communauté. Cette dernière, faite d’entreprises, mais aussi de développeurs enthousiastes a certainement contribué à l’évolution et à l’adoption de l’OS. Mais elle permet aussi d’en faire profiter le monde Linux.

Car Android, en plus d’avoir la bonne idée d’être Open-Source, partage aussi certains composants avec Linux, comme le noyau, ou encore le compilateur. Cependant, il est tout de même assez éloigné, et il est difficile de faire cohabiter les deux mondes. C’est pourtant ce qu’à fait le désormais célèbre Carsten Munk, qui a créé une couche d’adaptation, permettant de relier les drivers écrits pour Android à un système Linux classique comme Mer. Cette libhybris aura ensuite été reprise et améliorée par Canonical, et est maintenant aussi utilisée par OpenWebOS.

Un lourd passé

Jolla a d’abord commencé par travailler avec une base X et Qt 4, comme celle dans le N9. X est un logiciel bien connu du monde de Linux, car utilisé par toutes les distributions, et souvent source de bugs.

Il faut dire que X a une longue histoire. Développé lorsque la plupart des ordinateurs étaient des mainframes Unix, et les écrans composés que de quelques milliers de pixels, X ensuite été adapté et étendu pour s’adapter à l’informatique moderne. Typiquement, une extension largement utilisée est la capacité à dessiner des fenêtres directement avec OpenGL. Cette capacité n’a pas pu être réalisée directement, mais uniquement sur l’aspect rendu.

X conserve donc toutes les informations sur la position et la taille des fenêtres en mémoire, non visible, pour uniquement gérer les interactions avec la souris par exemple, et dessine via OpenGL les fenêtres via le GPU. Ce qui fait que la représentation des fenêtres est dédoublée. Il est alors impossible d’effectuer des rotations aux fenêtres, car seul la surface OpenGL peut tourner, et la représentation interne ne peut pas. Si l’on faisait tourner la surface uniquement, les coordonnées ne vont plus correspondre avec la représentation interne, et l’interaction avec la fenêtre, impossible.

La complexité que X a reçu au fil des ans en fait aussi un dinosaure buggué, bourré de lignes de codes qui sont probablement obsolètes, et de bugs. De plus, cette complexité fait qu’il est assez difficile d’obtenir des performances correctes sur du matériel mobile par exemple.

C’est pourquoi Wayland a été créé. Pour offrir une solution simple et extensible pour l’affichage. Cette simplicité permettrait d’avoir de meilleures performances sur un matériel limité, et l’extensibilité permettrait une certaine liberté dans les implémentations.

Et c’est bien ces deux aspects qui ont séduit le développeur de libhybris, qui s’est contenté de traduire les fonctions utilisés par Android pour partager des surfaces OpenGL en une extension Wayland.

Voici une vidéo étrange, où on voit des fenêtres wayland dans un environnement de type Quake.

S’adapter, vite !

Le support de Wayland par libhybris, et Qt5 n’étaient qu’un projet de recherche, et la base Qt4 + X11 devait être la base prévue pour le lancement, mais depuis le lancement de Jolla, de nombreuses choses se sont passées.

Premièrement, Wayland a été publié en version stable après plusieurs années de travail, et Qt 5 a aussi été publié en version stable, un peu avant cette année. Le support de Wayland par Qt est aussi considéré stable avec la sortie de Qt 5.1. Avec l’apport de Canonical, la libhybris s’est aussi améliorée. Des catastrophes se sont aussi passés, comme la fermeture de STE.

Alors, il n’y a pas beaucoup eu de choix pour Jolla: s’adapter, et vite ! Rapidement, la solution X11 et Qt4, qui semblait robuste au début, commença a perdre tous ses avantages, et la solution Qt 5 et Wayland s’imposa d’elle même.

Alors ils ont décidé de migrer toute leur architecture vers Qt 5, comme ce qui a été vu durant le travail effectué sur Nemo, afin qu’elle soit plus parée pour le futur, plus  «futureproof».

Cette migration semble bien être la norme maintenant, car Canonical essaie aussi de se débarrasser de X dans Ubuntu, en utilisant leur propre solution Mir (qui est très proche de Wayland), et Samsung et Intel considèrent aussi l’adoption de Wayland dans Tizen.

PS: Je n’ai volontairement pas parlé de X11, de Xorg, de XFree86, ou encore des protocoles. L’histoire aurait été bien plus longue, et il est possible que j’ai fait des imprécisions, juste pour la simplifier un peu.

PPS: Une super vidéo technique comme je les aime: pourquoi Wayland (conférence)

A propos de Sfiet_Konstantin

Développeur Qt, fan du N950 et du N9, et ayant un regard critique dans le monde de la mobilité et leurs interfaces graphiques, j'ai aussi été stagiaire chez Jolla durant l'été 2013.

58 commentaires à propos de “Sailfish OS et Wayland la solution «futureproof»

  1. Tant mieux que Jolla suive le mouvement, X fait partie des « boulets » que peut se trainer l’informatique (il était tant que les bios des PC passe en efi)

    et pour le coup sa me rassure car il s’occupe vraiment de leur petit bébé pour le parer à l’avenir.

    Est ce que ça pourrais prendre du retard du coup?

  2. Globalement c’est plutôt rassurant tout ça (enfin de ce que j’en comprends parce que je suis pas franchement un cador en technique) mais quelque part et de façon assez égoïste, ça fait un peu peur aussi: avec ces changements « de dernière minute », je suppose que le travail autour de la stabilité de cette architecture est important et que tout ce qui est finition (je pense notamment au travail sur le premier device lui-même, en ce qui concerne Jolla) risque d’être moins léché.
    Sans compter que les partenariats seront moins efficaces (développer dans un nouveau contexte, même si ce contexte est plus puissant, c’est perturbant, on perd ses repères… on fait forcément des bourdes…)

    Toi, vous, qui êtes plus à même de juger ce genre de choses, vous en pensez quoi? Est-ce que le Jolla device et son environnement logiciel ne risquent pas d’en pâtir? Est-ce qu’il ne va pas manquer quelques mois de maturation du système si la sortie du Jolla Phone est maintenue pour fin 2013?

    • Je comprends pas pourquoi ce serait égoiste. Et la stabilité de Wayland est au rendez-vous vu que c’est d’une simplicité déconcertante, bien plus que X11.

      Évidemment, il y a du travail pour porter sur la nouvelle architecture, mais libhybris est là, Qt 5 est là etc.

      Pour les développeurs annexes, disons que rien ne change. On a Qt 5, qui a des changements, mais minimes, par rapport à Qt 4, et c’est tout. Que ce soit du X ou du Wayland en dessous, on s’en fiche un peu.

      • Egoïste parce que plus dans l’esprit « futureproof » de l’article mais juste dans l’esprit « pour mon Jolla phone que j’ai précommandé moi personnellement en tant qu’individu » 😉

        Ok, pour le reste, on va se dire qu’ils connaissent leur taff et que tout va bien se passer 🙂

        • Bah c’est aussi égoiste que Ubuntu et consorts. Pour moi, un choix technologique ne peut pas vraiment être égoiste.

          Et j’ai expliqué pour les développeurs tiers que ça changerait pas grand chose 🙂 Pour les partenaires de longue date par contre, peut-être plus.

          • Ah non, je comprends ta question alors. On s’est pas compris, c’est ma question qui était égoïste parce que je ne voyais que l’impact pour moi 🙂

      • Que cet argument de courte vue est agaçant (mais je te rassure, c’est toujours le premier qu’on me sort, alors je suis un peu rodé … ) : en ce moment toutes les applications graphiques unix (linux, solaris, BSD, IBM-aix, etc) sont compatibles X11 (elles n’ont pas le choix, l’affichage passe par X-Window / X11R7) … Demain elles ne le seront plus, elles seront juste compatible wayland et ton XWailand partira aux oubliettes de l’histoire ; Il aurait fallu que le protocole X11 soit constitutif de wayland, pas que wayland daigne accepter un serveur X11 ; j’en veux pour preuve la situation sur OSX : va faire de l’export display d’une application Quartz/aqua/OpenGL, alors que tu n’as aucun mal pour faire tourner un OSX-intel XGimp sur un mac standart et l’afficher sur un debian arm ou un OSX PPC … C’est pas paske Ubuntu, Apple et M$ font la même connerie (juste pour des raisons de contrôle de licence : va appliquer une licence par machine quand l’affichage de ton application est exporté sur une autre machine) que ce n’est pas une connerie.
        Pour l’instant Wayland reste une régression.

        • En essayant de rester constructif, et de ne pas se baser sur un unique argument, qui est l’impossibilité (?) de faire de l’export display avec Wayland, j’aimerais bien savoir pourquoi Wayland est une régression, surtout dans le monde actuel.

          L’article parle des avantages de Wayland pour un appareil mobile, qui a besoin de hautes performances dans un environnement contraint, et non d’un serveur UNIX, ou d’un Desktop. Effectuer du remote desktop sur le Jolla phone me semble pas être une priorité numéro 1.

          Il ne faut pas non plus oublier que Wayland permet, via son protocole très simple, de profiter de l’accélération matérielle plus simplement, ce dont a besoin un appareil mobile, ce que X permet de faire, mais bien plus difficilement.

          Enfin, la vidéo que j’ai posté à la fin de l’article montre bien que malgré cet avantage de faire de l’export display de X, celui-ci le fait mal, et que les ingénieurs de Wayland travaillent sur quelque chose ressemblant à VNC, donc de l’export display.

          Pour sacrifier l’export display sur tant d’avantages (surtout que l’usage de l’export display me semble peu pertinant sur le Jolla phone), je ne vais pas appeler ça une régression.

          • lu sur linuxfr :

            [Q]
            Ça, si j’ai bien compris, ce n’est pas le problème de Wayland mais des applications qui utilisent ce qu’elles veulent pour rendre leur buffer (une carte consommatrice ou une autre). C’est donc ces dernières qui devront gérer de manière intelligente.

            [R]
            Exactement.
            Il suffira qu’une application ne supporte pas un changement de contexte pour que l’on ne puisse pas éteindre un GPU. Cela dit, on pourra toujours lancer une appli sur le GPU de son choix.

            [R]
            Et si le dev ne fait rien de particulier, on aura un bon comportement par défaut?

            [R]
            Ça dépendra des bibliothèques utilisées.

            voila, voila voila, le retour des lib publique à usage unique …
            Personnellement j’appelle ça un bon gros bordel ou chacun ira de sa solution perso et finira par mettre le souk !

          • pour reprendre tes arguments,
            X fait très bien l’export display : aucun mal a afficher un OSX Xgimp s’éxecutant OSXintel ne disposant d’aucun desktop (kde, lxde, hildon, gnome, twm), sur un linuxbox PPC/KDE, aucune difficulté à afficher Duke Nukem3D tournant dans une dosbox sur mon N900 et s’affichant sur ma linux box PPC http://n900.frenchboard.com/t656-un-petit-duke3d
            Et je peux aussi enregistrer des cas de figures ou VNC est à la ramasse : rien qu’en me connectant sur cette machine sans desktop ou en ne voulant afficher qu’une seule application et pas tout le bureau de la machine distante … Quand on veut noyer son chien on dit qu’il a la rage

            la consommation de ressource …. Attend je cherche mon N900 : moins de 1% du cpu … y-a pire.

            opengl et le compositeur de X-org sont quasiment les même que ceux de Wayland : match null.

            « surtout que l’usage de l’export display me semble peu pertinent sur le Jolla phone »,
            l’usage n’est pas à sens unique et le contraire peut parfaitement l’être : http://n900.frenchboard.com/t624-export-display-de-votre-n900-vers-votre-linux-box ;
            j’ai déjà reconfiguré mon N900 de la sorte alors que j’étais fort loin de mon smartphone … ah bin c’est plus possible, le protocole est supprimé et les applis son « wayland lib » ! Mais bon pour tous ceux qui viennent du paradigme window$, l’usage de l’export display vous est complètement étranger, donc ça ne sert à rien …

            bref on va tous se fader de lancer un bureau à distance via VNC (donc toute la couche desktop hildon/KDE/Gnome/etc), juste pour exécuter une appli à distance ; multiplie ça par 50 utilisateurs et tu as les horreurs de VNC/terminal desktop sur un petit réseau : ça c’est de l’optimisation !

            bref, c’est juste la fausse bonne idée ! Surtout avec les solutions cloud qui se précisent (lancer une appli du cloud, l’afficher sur ta Xwindow box sans aucun autre intermediaire qu’un commande « ssh -X -e « … plus facile je ne vois pas ! )

            être constructif ne signifie pas renoncer à ce qu’on utilisait ou le faire mal avec des outils inadapté : pour ça WP fait parfaitement l’affaire.

            Mais bon, Wayland c’est parfait pour gérer les licence applicatives par machine, donc c’est bon pour le business, donc c’est bon tout court.

          • peut-être pour un smartphone l’export display ce n’est pas l’essentiel. mais par exemple il sera possible lancer une version desktop ubuntu sur ubuntu edge. et quoi?..

          • En fait, j’ai même pas envie de m’étendre sur ce sujet. Il a été rabaché tellement de fois lorsque Wayland a été annoncé que bon, ça me saoule un peu. Ah et puis, le même sujet a été râbaché aussi lors de la sortie de Qt5, qui annonçait qu’il ne supportait plus SSH+X vu que toute l’architecture passait sous OpenGL.

            Et qu’on ne me brandisse pas la sacro-sainte license GNU de X comparé à la BSD de Wayland pour dire: bouh, Wayland peut être utilisé pour faire des applications commerciales, c’est pas bien du tout.

            Si il y a une chose indéniable, c’est que X est lourd. X a du passé, et donc beaucoup de code, qui, pour Jolla, est difficile à patcher, à maintenir. De son côté, Wayland est léger, facile à étendre et sans trop de bugs, puisqu’il n’y a pas beaucoup de lignes de codes. En plus, Wayland se débarasse de la phase de communication vers le serveur X, qui doit communiquer avec le compositeur, donc rien que ça permet d’avoir des performances plus élevées (notamment grâce à une latence moindre).

            On trouvera bien d’autres solutions pour le partage de bureau, vu que c’est un besoin. Si VNC ne semble pas adapté (pour moi, il est correct), les ingénieurs de Wayland développent un protocole proche de VNC intégré à Wayland, donc on va retrouver un équivalent de notre SSH +X si on donne assez de temps à ces ingénieurs.

            Sujet clos ?

  3. La vidéo de la conf est très intéressante et accessible plus ou moins à tous (moyennant quelques connaissances techniques sur X, même si le gars explique plutôt bien). Je l’ai regardé hier soir avant de dodo, bien sympa et très claire.
    Qui dit meilleures performances dit aussi certainement meilleure autonomie.
    J’ai trouvé ça en faisant une recherche rapide : http://www.phoronix.com/scan.php?page=news_item&px=MTM0OTE . Un petit moment qu’ils expérimentent dessus en fait !

    (N’empêche j’ai gagné une bière sur un pari avec cette annonce 🙂 )

    • J’ai trouvé la vidéo ce matin. Elle m’a bien plu, car j’ai pu redécouvrir certains principes de Wayland que j’avais un peu oublié. (Je suis pas hyper calé sur tout ce qui touche à X et WL, mais je me soigne)

      Et le lien de la libhybris oui, on en parlait avec Carsten en décembre sur IRC 🙂

  4. @Sfiet_Konstantin. merci pour la leçon 🙂 on parle que le meilleur c’est l’ennemi du bien 🙂 mais je suis calme. c’est mieux de corriger quelque chose au début pour éviter des problèmes plus tard.
    il me semble qu’il est plus compliqué faire des modifications du hardware.

  5. Dans l’article vous dites : « Des catastrophes se sont aussi passés, comme la fermeture de STE. »

    Jolla pensait utiliser une puce STE pour son smartphone ?

      • bon. par ex. on fera Mir pour Ubuntu 14.04. et quoi? les applis pour les versions précédentes ne seront pas compatibles avec celle? ou ce n’est pas le cas? et il me semble que le sous-système audio est aussi assez compliqué.

        • Ils ont une couche XMir pour supporter les applis fait pour X, tout comme Wayland a XWayland. La couche audio, je ne connais pas assez.

          Remarque, Jolla ne va probablement pas s’occuper de XWayland, car il n’en n’ont pas besoin. Un port communautaire est envisageable par contre.

          • Mouais, on veut bien me le répéter, mais cette histoire de Mir, pour moi, ça reste juste que Canonical veut développer le truc en interne.

            Wayland et Mir se ressemblent énormément (juste une histoire de qui crée le buffer si je ne m’abuse).

          • Sfiet,

            Si tu ne l’as pas déjà croisé, voilà un article (en anglais) qui décrit assez bien le côté bancale de la license de Mir : http://mjg59.dreamwidth.org/25376.html

            En résumé, Canonical se sert de la GPLv3 et de leur CLA, pour empêcher quiconque de pouvoir distribuer Mir dans un produit, ou de travailler dessus (genre ajout de drivers), sans passer par eux. Il n’acceptent les contribution que si on leur « offre » le code, qu’il puissent lui changer la license et le revendre sans que la personne ayant fourni la contribution puisse faire de même. Personne ne va donc y contribuer, excepté Canonical.

            Tout l’inverse de Wayland donc. Heureusement que Jolla a une politique plus respectueuse vis à vis du monde open-source.

          • @Zeta

            Pour Mir il y a aussi le fait qu’ils veulent maîtriser le développement de Mir. Ce n’est pas dans le sens « dictatorial totalitaire » du terme que beaucoup de libristes se plaisent à donner à Canonical. C’est pour éviter que le code de Mir ne parte dans tous les sens et devienne un beau bordel en moins de temps qu’il ne faut pour le dire. C’est sûr que ça fait pas très « communauté », mais dans 10, 20 ou 30 ans Mir sera peut-être encore fringant comme au premier jour là où Wayland sera lourd et indigeste, comme l’état actuel de X qui est si bien décrit par Sfiet_Konstantin. Et là on ne pourra que dire « merci ! » aux structures mises en place par Canonical pour assurer la qualité de leurs logiciels au quotidien.

          • Please tout le monde: laissez cet article troll-free. Allez continuez la guèguère Mir Wayland autre part 🙂

            (Pour une fois que je fais un effort d’équité, que je parle de Mir et de Wayland sans en dénigrer un, on troll quoi …)

        • Une petite idée du bordel qu’est l’audio sous linux : Alsa, PulseAudio, Gstreamer, etc. : http://blogs.adobe.com/penguinswf/files/penguinswf/linuxaudio.png

          En relisant quelques messages dans la mailing list Fedora au sujet d’un potentiel passage à Wayland (la discussion date de 2010 au moins), j’ai vu un truc interessant:
          L’un des gars pointe du doigt que l’on ne crée plus vraiment d’application pour X, mais pour Qt ou Gtk. Le support de X, wayland, directFB, windows ou OS X est fourni par ces toolkits. Donc tant que ce sont des applications faits sur ces frameworks (Qt en particulier), le passage d’un gestionnaire de fenêtre à un autre ne pose pas vraiment de problèmes au developpeur de l’application. Reste que Mir semble une très mauvaise idée et restera cantonnée à Ubuntu à cause de la license qu’il y ont posé.
          Wayland reste la solution d’avenir vers laquelle beaucoup se tourne. Par ex, plutôt que de fournir l’accélération graphique au serveur X11 de la raspberry pi, il ont préféré investir sur le support de wayland, avec XWayland pour la compatiblité avec les applis X (http://www.raspberrypi.org/archives/4053).

          • @air-dex
            Mon objectif ici n’est pas de basher canonical (je pourrais dire qu’ils ne contrôlent pas non plus que le noyau ne parte pas dans tous les sens), ce qui ne servirait à rien, mais plutôt approuver le choix de Jolla d’utiliser Wayland et pas Mir (surtout qu’ils ne pourrait pas!).

            Quand à la vision à 10/20 ans de Mir ou de Wayland, perso je m’en fout… Ce qui m’importe c’est que le soft actuel soit adapté au matériel actuel, pas à celui d’il y a 20 ans. Si dans 10 ans on remplace Wayland parce que les processeurs et GPU n’auront plus rien a voir avec maintenant et que ça permet de se débarrasser de la moitié du code en améliorant les perfo, je serais à 100% pour. Et c’est Qt qui s’occupera de gérer ce changement, pas moi (ou alors très peu de mon côté).

            Si on reprend l’exemple de la raspberry pi, voilà ce qu’on peut espérer comme gain de batterie en lecture de vidéo a se débarrasser de X et profiter du matériel de 2013 : « we found a 20% runtime difference — from 4 hours to a bit over 5 — when watching videos using the overlay, compared to pumping them through GL ES » (http://ppaalanen.blogspot.co.uk/2013/05/weston-on-raspberry-pi-accelerated.html)

          • Pour moi, Canonical, c’est le Microsoft du libre… comme ça je résume bien. J’oublie pas les coups foireux du passé…

    • je suis désolé du doublon, quand je poste une reponse en mode web depuis mon n9 ca bug (en envoyant la reponse j’ai un message d’erreur me disant que je ne peux aller a l’url, mais apparemment le message part quand même).

      merci pour la reponse (vague 😆 ) sfiet 😉

  6. Ça a le mérite de faire rentrer Sailfish dans le rang pour ce qui est de Qt. Là où le Qt Project s’efforce de faire passer le monde à Qt 5, Qt Quick et ses QtControls universels, Jolla et Sailfish allait sur du Qt 4 et une bibliothèque maison « Silica » pour Qt Quick. Et perso je trouve ça assez ingrat de la part des jeunes loups Jolla et Sailfish, surtout quand Digia et le Qt Project les mettent à l’honneur dans leur vidéo promotionnelle de Qt 5 ( http://jollafr.org/sailfish-mis-en-avant-pour-la-sortie-de-qt-5-0/ ). Cela n’enlève rien ni aux qualités de Sailfish et de sa Scroll UI, ni à celles des composants de Silica, mais ceci devait être dit.

    Les évènements récents décrits par Sfiet_Konstantin ont réglé le problème de la version de Qt. Il ne reste plus désormais que le « problème Silica ». À noter toutefois qu’il n’y a pas que Sailfish qui a un « problème Silica ». Ubuntu Touch est exactement dans la même situation que l’OSpadon avec ses « Ubuntu.Components », mais aussi BB10 et son « Qt Cascades » qui est encore pire.

    • Au pire, on pourra toujours faire un port partiel de Silica vers Qt Quick Controls. Il suffit de « wrapper » les composants Silica dans des composants Quick Controls. Évidemment le port sera pas parfait, mais on aura l’idée.

      Moi, ce qui me dérange, c’est l’absence de ifdefs pour le code QML (ce qui est de toute façon impossible à implémenter à cause du fait que ce soit un langage interprété).

      • Je vais te répondre la même chose que je t’ai répondu sur Twitter il y a quelques temps. Ce port partiel c’est à Jolla et Sailfish de le faire, pas aux développeurs d’applications.

        Pour les différents QtQuick Controls (j’abrège en QQC), Digia et le Qt Project auraient très bien pu garder « QtDesktop » pour les QQC bureau (comme c’était le cas jusqu’ici, les QQC Desktop ayant été un projet annexe jusqu’à Qt 5.1), faire un « QtAndroid » pour les QQC d’Android, un « QtiOS » pour ceux d’iOS… Mais le fait est qu’ils ont choisi d’uniformiser ça avec « QtQuick.Controls ». Tous les composants graphiques courants (boutons saisie de texte…) ont le même nom en QML quelque soit la plateforme par le choix des instances dirigeantes de Qt. Chaque nouvel OS désirant être supporté par Qt se doit donc de respecter les choix du Qt Project. Or si Tizen le fait, on ne peut hélas pas en dire autant de Sailfish, Ubuntu Touch et BB10. Rien n’empêche ces 3 OS là de proposer une bibliothèque annexe de composants graphiques QML spécifiques à leurs OS pour les développeurs voulant optimiser leur appli pour l’OS en question. Au contraire ce serait une très bonne idée. 😀 Mais que ces OS là aient au moins l’aimabilité de proposer leurs versions des composants graphiques courants en QML parmi les QtQuick Controls de Qt. Des librairies « Sailfish.Silica » (au hasard ^^) pour l’OSpadon, « Ubuntu.Components » pour Ubuntu Touch et « Qt Cascades » pour BB10 ne sont bienvenues que si elles se cantonnent au rôle d’extras pour développeurs avides d’optimisation pour un OS donné (comme les « Pull Menus » de Sailfish). Rien n’empêche aussi Qt de faire la même chose pour les OS qu’il supporte déjà.

        Certains ici ont peut-être développé des applis QML pour Symbian et MeeGo. Je suis sûr qu’ils auraient aimé avoir ce « QtQuick.Controls » au lieu des 2 irréconciliables « com.nokia.symbian » et « com.nokia.meego ». Cela leur aurait évité de devoir copier-coller (et modifier en double en cas de bug) une partie non négligeable de leur code. Ayons une pensée émue pour ces gens là à qui « QtQuick.Controls » simplifiera grandement la vie.

        « Moi, ce qui me dérange, c’est l’absence de ifdefs pour le code QML (ce qui est de toute façon impossible à implémenter à cause du fait que ce soit un langage interprété). »

        Bienvenue au club. Ça permettrait de faire les bons imports. Après Qt 5.1 apporte un bon début de réponse au problème avec un attribut QML « Qt.platform.os » en lecture seule ( http://qt-project.org/doc/qt-5.1/qtqml/qml-qtqml2-qt.html#platform-prop ). À voir ce que cela donne dans le code.

        PS : cf. http://qt-project.org/wiki/Tizen et http://qtfortizen.blogspot.fr/ pour ceux que le port de Qt sur Tizen intéresseraient

  7. Je vais faire un petit HS et je m’en excuse.

    Dans le milieu qui gravite autour de Nokia, on parle beaucoup de photo, à base de pureview, d’OIS, ce super mega-techno.

    En ce qui concerne Jolla, je doute que l’on puisse s’attendre à quelque chose de renversant. Ça sera sans doute des composants sur étagère, moyenne gamme, et puis je ne pense pas que ce soit la priorité pour l’équipe de Jolla… mais à la limite, peu importe.

    Ce qui m’intéresse en fait, c’est le niveau d’ouverture de Sailfish.

    Si on reprend l’exemple de la photo, pensez-vous que Jolla pourrait laisser des développeurs indépendants – par exemple les même qui ont développé l’excellent Gimp – améliorer le traitement logiciel de la partie photo ?

    Là, je présente l’exemple de la photo, mais la question reste valable pour le reste, que ce soit la gestion de l’énergie, le réseau ou un éventuel cryptage…

    Qu’en pensez-vous ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*