Un post de Lars Knoll sur le blog Qt de Nokia fait le point sur la future version Qt 5. Dans ce texte Lars indique que Qt 4 est sorti en juin 2005 et que depuis cette époque beaucoup de chose ont changés dans le paysage informatique. Selon lui il est temps dévoluer vers Qt 5.
Certes la transition se veut moins traumatisante que le passage de Qt 3 à Qt 4 puisque la compatibilité sera assurée au niveau du code source. En revanche l'ABI sera modifiée donc les applications devront être recompilés (ce qui dans le monde du libre n'est pas un handicap).
Les grands objectifs sont donc:
- Facilité de migration de Qt 4 vers Qt 5
- Rendre plus facile la création d'applications
- Profiter mieux des ressources de la carte graphique
- Intégration avec le web
Pour atteindre ces objectifs très généraux des changements techniques vont intervenir dans Qt. A lire le texte on comprend bien que C++ n'est plus trop en odeur de sainteté. Le forcing va être fait sur JavaScript et l'interface sera basée sur le framework déclaratif Qt Quick et sur QML:
We should expect that over time all UIs will be written in QML
we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++
En dépit des phrases rassurantes de Lars on est en droit de considérer qu'il s'agit là d'un gros changement à digérer. Certes le décollage du marché des smartphones fait saliver tout le monde mais passer ainsi d'un modèle entièrement C++ à un modèle QML+JavaScript ne se fera pas en un jour.
En ce qui concerne les autres points le projet WebKit2 (version multi-process de WebKit) sera intégré à Qt 5 ainsi que le moteur JavaScript V8 de Google.
Tout le code sera basé sur le projet LightHouse qui promet une meilleure abstraction de la plate-forme sous-jacente. La compatibilité avec OpenGL 2.0 sera obligatoire puisque tous les widgets seront basés dessus.
D'autre part QWidget aura sa propre bibliothèque séparée ce qui est considéré comme plus propre.
Au niveau du support des différents OS, Lars annonce que les développeurs ne vont que se concentrer sur Linux (Wayland et X11), Mac OSX et Windows. Pour les autres ils ne seront intégrés "que si nous trouvons des équipes pour faire le travail". Une phrase assez cryptique indique également que Qt offrira "des fonctions différenciées en fonction des OS".
Puisque le développement de Qt se faisait jusque là dans un mode assez fermé (avec TrollTech ou Nokia qui tenaient exclusivement les rênes) un changement à là aussi été décidé. Le post de Lars Knoll indique que Qt 5 sera développé "in the open" et que tous les développeurs auront un statut égal (même si peu de détails additionnels sont fournis). Le repository du code ne sera pas fait à partir de serveurs Nokia et les discussions se dérouleront sur des mailing list ouvertes.
Un document pdf un peu plus détaillé que le post a été publié ici.
Actuellement, et puisque les changements ne sont pas considérés comme trop radicaux, le calendrier prévoit la première béta de Qt 5 avant la fin de l'année 2011 et la release finale en 2012.
# Zut c'était pas le bon jour pour les predictions...
Posté par Maclag . Évalué à 10.
Parce que j'allais dire qu'en 2013, on sortira KDE5.0, et on aura une nouvelle vague de migration vers Gnome, mais moins dans la douleur, parce que d'ici là, Gnome, qui sera tombé complètement dans le giron d'Ubuntu, utilisera des bouts de Qt4.
Non, je suis méchant et trollesque (alors qu'en plus je tape ce message dans une fenetre Konqueror, sous KDE), mais Javascript, tout ça, c'est une bonne nouvelle... pour les EFL!
-----------> [ ]
# QML peut il remplacer les widgets?
Posté par ecyrbe . Évalué à 4.
QML c'est bien pour permettre à un designer web de faire une interface.
Cependant, il y a un truc que j'ai encore du mal à voir.
Est-ce qu'il y a un truc dans QML pour réutiliser le style des widgets actuels, ou bien on doit réinventer le bouton à chaque fois? Est-ce que tous les widgets de Qt sont implémenté dans QML, ou bien on doit tout se retaper?
Parce que si c'est pour refaire ses widgets à chaque projet, moi je trouve qu'au final on perd plus de temps d'un côté qu'on y gagne de l'autre.
[^] # Re: QML peut il remplacer les widgets?
Posté par Martin Peres (site web personnel) . Évalué à 3.
https://www.youtube.com/watch?v=nj5jzv6njKg et http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ sont tes amis ;)
[^] # Re: QML peut il remplacer les widgets?
Posté par ecyrbe . Évalué à 2.
Ah, c'est chouette, merci pour les liens.
Ça fait pas encore partis officiellement de Qt, donc pour le moment je vais vais rester sur les widgets classiques, mais en tout cas, c'est prometteur.
S'ils arrivent à le fournir de base dans Qt, on pourra effectivement imaginer avoir un Qt5 qui repose sur du QML.
[^] # Re: QML peut il remplacer les widgets?
Posté par Martin Peres (site web personnel) . Évalué à 1.
Ils seront inclus dans Qt5, c'est marqué sur le blog post.
Je suis vraiment curieux de voir des benchmarks pour voir si scenegraph apporte des perfs même dans le rendu d'interfaces graphiques classiques. J'ai pas envie de sacrifier des performances...
Sinon, QML va permettre d'apporter des interfaces organiques? (transitions douces) et KDE va pouvoir faire son propre set the widget QML comme ça, on aura un comportement unifié et cohérent entre les applis KDE :)
[^] # Re: QML peut il remplacer les widgets?
Posté par Damien Thébault . Évalué à 1.
Il me semble que pour l'instant les widgets de base ne sont pas (tous) dispo, mais que chacun peu se faire les siens.
Il est ensuite possible de réutiliser de widgets qui ont déjà été créés, de les instancier et de les manipuler facilement.
# libqxt
Posté par fredix . Évalué à 1.
Je suis un noob en Qt, mais il n'y aurait pas un intérêt à intégrer la libQxt qui proposent des modules plutôt sympathiques.
# Vers du Mozilla like ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
QML +CSS, du js, avec des composants en C++...
Aller, encore quelques petits efforts et on fera du XUL-like. Finalement, la plateforme Mozilla et XUL a de l'avenir malgré ses 12 ans d'age.. :-)
Et sinon, embarquer V8 n'est apparemment pas une super idée pour le moment (c'est le gars de Nginx qui le dit). Alors que SpiderMonkey est quasi aussi performant, et propose du javascript plus évolué (iterateur, generateur, array comprehension etc). Ceci dit, le choix de V8 est assez naturel puisque webkit est utilisé..
[^] # Re: Vers du Mozilla like ?
Posté par un_brice (site web personnel) . Évalué à 5.
Le gars de Nginx dit que V8:
* termine le process quand il n'y a plus de RAM (ce qui gène NginX car il est mono-process)
* nécessite 2ms pour la création d'une requête (ce qui gène NginX car il est mono-thread)
* ne supporte la compilation native que pour amd64, i386 et arm
Ces arguments semblent indiquer que V8 n'est pas adapté pour remplacer les modules permetant de scripter NginX genre lua-nginx-module .
Ces arguments n'impliquent pas :
* que V8 n'est pas adapté pour scripter des applications en général
* que V8 n'est pas adapté pour créer un langage de script serverside
[^] # Re: Vers du Mozilla like ?
Posté par Corentin Chary (site web personnel) . Évalué à 6.
De plus ce commentaire à été écrit il y'a six mois. Depuis, http://code.google.com/p/v8/issues/detail?id=510#c15 à changé pas mal de choses.
# Quelques précisions
Posté par moi1392 . Évalué à 4.
D'après ce que j'en ai compris, n'hésitez pas à compléter/me corriger
Pour ce qui est de la compatibilité au niveau source code, elle sera le plus possible préservée, mais il pourra y avoir quelques modifications.
En particulier, le retrait pur et simple de Qt3Support et du code de support disséminé un peu partout dans Qt (oui, il y a encore du Qt3 support dans pas mal d'applications qui ont fait le portage qt3->qt4 à la va vite)
Pour ce qui est de la gestion du rendu, le coeur du système ne sera plus l'architecture basé sur QPainter mais un scenegraph piloté par QML.
Cette partie sera la plus optimisée (pour optimiser les performances sur les plateformes mobiles je suppose) et le système QWidget/QPainter se basera dessus.
De plus, toute la partie QWidget sera dans une lib à part, pour permettre de n'embarquer que la partie QML pour les systèmes embarqués qui auront tout codé en QML.
OpenGL (ES) 2.0 obligatoire (au pire via un rendu logiciel comme mesa ou gallium)
Abstraction de l'OS faite par le sous projet Lighthouse (je n'ai pas beaucoup d'infos dessus, donc je laisse les autres en parler)
[^] # Re: Quelques précisions
Posté par Thomas Monjalon . Évalué à 3.
Lighthouse, c'est une excellente nouvelle pour l'embarqué. Ça va permettre un support beaucoup plus large des différentes accélérations matérielles avec Qt sans passer par X11.
Il y a d'autres précisions ici : linuxembedded.fr.
# Égalité de traitement
Posté par rewind (Mastodon) . Évalué à 2.
ça commence bien :
http://qt.gitorious.org/qt/qt5/blobs/master/README
[^] # Re: Égalité de traitement
Posté par Gof (site web personnel) . Évalué à 10.
-nokia-developer permet
1) d'utiliser les miroirs git interne à la place des dépots publics.
2) est l'équivalent de -developer-build -confirm-licence dans le configure
(les employés de nokia n'ont pas besoin de confirmer la licence)
Bref, rien de bien différent avec ces options.
Par ailleurs, si tu lis le blog, le "in the open" n'a pas encore commencé. Mais il est prévu que ce soit finalement le cas à partir de juin pour la rencontre des contributeurs.
[^] # Re: Égalité de traitement
Posté par rewind (Mastodon) . Évalué à -10.
Non mais moi je veux bien, mais là, ça assure pas. Le fait qu'il n'y ait que ce README dans le dépôt (en dehors des submodules) fait qu'on va aller le lire. Ensuite, qu'il y ait une option pour faire plusieurs choses à la fois, pourquoi pas, mais il faut l'appeler autrement que nokia-developper. Enfin, sur ce que tu dis, les dépôts publics ne sont pas les dépôts officiels puisqu'il y a les dépôts internes. Donc, même si à l'heure actuelle on comprend bien pourquoi, là il y a un problème de communication sur la future version.
[^] # Re: Égalité de traitement
Posté par Albert_ . Évalué à 6.
Il n'y a pas de probleme de communication il y a une TODO liste qui n'est pas encore fini. Il faut arreter de pinailler parfois.
# C++
Posté par phoenix (site web personnel) . Évalué à 5.
De mon coté, j'aime bien continuer à écrire mon application en C++ entièrement et faire mes GUI avec QtDesigner. J'espère ne pas devoir faire un jour des mélanges de C++, JavaScript et QML, ...
J'espère que la partie Widget et QtDesigner va continuer d'évoluer...
[^] # Re: C++
Posté par gnumdk (site web personnel) . Évalué à 5.
Je ne pense pas que le C++ soit mort...
QML va surtout concerner la partie Smart Phone et pour KDE plasma.
Mais pour le reste, les applications seront à mon avis majoritairement en C++.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.