La nouvelle version de Qt (prononcer « cute » comme mignon en anglais), le framework en C++ derrière KDE et bien d'autres applications libres, est sortie. Celle-ci est la dernière version majeure de la branche 4.x et la prochaine sera la branche 5.
Merci à Gof, Nÿco, _PhiX_ et reno pour leur aide lors de la rédaction de cette dépêche.
Nouveautés
Qt Platform Abstraction (QPA)
C'est une restructuration de la pile graphique afin de faciliter le portage vers différents systèmes de fenêtrage et périphériques. Ce sera l'une des fondations de Qt 5. C'était le but du projet Lighthouse qui a été fermé puisque l'objectif est accompli.
QPA remplace le port de Qt pour Embedded Linux : auparavant, le code de Qt était parsemé de #ifdef pour chaque plate-forme, ce qui rendait difficile de porter Qt sur une nouvelle plate-forme. Dans le cas de Qt pour Embedded Linux, beaucoup de clients utilisent leur propre gestionnaire d'affichage (par dessus le framebuffer par exemple) et il fallait faire beaucoup de modifications dans Qt lui-même pour intégrer ces plates-formes. QPA est une abstraction qui permet de mettre tout le code spécifique à l'affichage dans un plugin, rendant ainsi beaucoup plus facile le portage et la maintenance vers de nouvelles plates-formes ou systèmes graphiques.
C'est ainsi que des ports (non officiels pour le moment) on pu être développés très rapidement par la communauté : pour Android (Necessitas), IOS ou encore QNX/blackberry.
Threaded OpenGL support
Le rendu OpenGL concurrent via plusieurs threads est grandement facilité.
Multithreaded HTTP
Les requêtes HTTP sont maintenant effectuées dans un thread séparé. Cela devrait rendre les applications graphiques plus fluides puisque les accès réseau ne se dérouleront plus dans la boucle principale d'événements.
Optimized file system access
La pile du système de fichier a été modifiée en profondeur afin d'améliorer les performances des opérations d'entrées/sorties grâce à une réduction des appels systèmes et une meilleure utilisation des données en cache. Les résultats de ces améliorations peuvent être constatés sur toutes les plates-formes.
QtWebKit 2.2.1
Le module qui utilise le moteur de rendu HTML WebKit.
Support de nouvelles fonctionnalités du nouveau standards C++11
- Il est maintenant possible d'initialiser les QList ou les QVector avec liste de valeurs en accolades:
QStringList maList = {"hello", "world"};
- Les objets Qt supportent la sémantique move qui permet du code plus rapide.
- QtConcurrent supporte les expressions lambdas
QList<QImage> images = ...
QFuture<void> future = QtConcurrent::map(images, [](QImage &image) {
// scale les images dans différent threads.
image = image.scaled(100,100);
});
Et après
Pendant ce temps le développement de Qt 5 suit son cours :
Ouverture du développement
Contrairement au développent des précédentes versions de Qt qui étaient contrôlées par Nokia, Le développent de Qt 5 est totalement ouvert. Tous les contributeurs sont égaux et il n'y a plus de différence entre les employés de Nokia et les autres.
Mise à jour en douceur
Le but de cette nouvelle version majeure est de faire les changements internes nécessaires à la mise à niveau de Qt et qui casse la compatibilité binaire. Mais de gros efforts sont faits pour garder au maximum la compatibilité source, permettant une mise à jour facile (contrairement à la migration de Qt3 vers Qt4)
QML
- Les interfaces en QML sont maintenant considérées au même niveau que les interfaces réalisées avec QWidget. Le code des QWidget est sorti de QtGui pour être maintenant dans sa propre librairie.
- Beaucoup d'efforts sont fait sur le développement de QML pour le rendre encore plus rapide et riche.
QPA
QPA est utilisé même sous Windows ou Mac OS. Et sous Linux, il y a des plugin pour X11 (utilisant XCB, au lieu de XLib utilisé sous Qt 4), et Wayland
Aller plus loin
- Annonce de la sortie (201 clics)
- Journal de patrick_g à propos de Qt 5 (567 clics)
# Preums
Posté par mosfet . Évalué à 1.
Est ce que Qml peu être utilisé pour faire des interfaces desktop ?
En fait j'ai trouvé une partie de la réponse ici mais je voudrais savoir si a terme ce sera la pratique recommandée.
En clair si je commence a développer une application aujourd'hui est ce que je dois me mettre a QML au coder à l'ancienne ?
[^] # Re: Preums
Posté par Gof (site web personnel) . Évalué à 7.
Oui et non:
Le développement de QML a été très focalisé sur le mobile.
Mais des efforts sont fait, avec les "desktop components" pour permettre d'utiliser QML sur le desktop, comme le montre le lien vers lequel tu pointe.
Les desktop components sont toujours à un stade Alpha, mais ils fonctionnent déjà plutôt bien.
Si ton application est une application open source que tu fais pour le plaisir, je recommande d'utiliser QML (parce que c'est un véritable plaisir). Tu rencontrera surement quelque bugs, mais ça fait partie du jeu. Tu peux es reporter et améliorer le produit.
Par contre, si tu fais une application commerciale, alors je pense qu'il est préférable de se baser sur des valeurs sûres, et d'utiliser QWidget. Au risque de devoir refaire l'interface dans quelques années. (Pas parce que QWidget ne fonctionnera plus, mais parce que QML sera bien meilleur pour des interfaces qui n'ont pas l'air de venir des années 2000)
[^] # Re: Preums
Posté par Jean Roc Morreale . Évalué à 2.
Le souci comme toujours c'est le passif, qu'importe l'apport de QML si pour y passer il faut refaire et revalider plus d'une centaine d'écran différent (la génération automatisée de l'ui a ses limites), retraduire et revalider une dizaine de milliers de chaînes, etc.
Pour Qt5, l'objectif est de faire tourner qtwidget sur le Scenegraph.
# Punaise.... Qt ... Cute...
Posté par Graveen . Évalué à 3.
Je me fouetterais 'tain :D
[^] # Re: Punaise.... Qt ... Cute...
Posté par Niniryoku . Évalué à 1.
?
Bits.nytimes.com
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Punaise.... Qt ... Cute...
Posté par Graveen . Évalué à 5.
ouais. Mais ca doit faire 5 ans que je passe à côté d'un truc évident comme ça.
Rien que pour ça, cette news illumine mon quotidien. Les pisse-froid qui ont moinsé la manifestation évidente de mon étonnement enfantin ne récoltent que mon mépris :)
[^] # Re: Punaise.... Qt ... Cute...
Posté par Marotte ⛧ . Évalué à -3. Dernière modification le 19 décembre 2011 à 23:22.
Bah pas si évidente (à vrai dire j'ai pas compris, et je comprends toujours pas), c'est pourquoi je t'ai moinssé...
[^] # Re: Punaise.... Qt ... Cute...
Posté par Spyhawk . Évalué à 2.
T'es mignon, hihi.
[^] # Re: Punaise.... Qt ... Cute...
Posté par Maclag . Évalué à 5.
Moi je te plusse à condition que tu te fouettes pour de vrai sur la place publique.
Grande gueule va!!
-----------> [ ]
# sémantique move: précision
Posté par GeneralZod . Évalué à 9.
La sémantique move permet surtout d'éviter des recopies inutiles , ce qui effectivement se traduit par des performances améliorées. La présentation la plus claire que j'ai trouvé pour comprendre cette fonctionnalité phare de C0x n'est autre que cette entrée de la FAQ de Bjarne Stroustrup
[^] # Re: sémantique move: précision
Posté par Gof (site web personnel) . Évalué à 3.
Une autre explication: http://cpp-next.com/archive/2009/09/move-it-with-rvalue-references/
À noter cependant que les classes de Qt sont partagées: la plupart implémentent le "copy on write". Ce qui veux dire que Qt évite déjà beaucoup de copie inutile.
Mais grâce à la sémantique du move, le code est quand même plus rapide car les opérations atomiques nécessaire à implémenter le compteur de référence peuvent être optimisées.
[^] # Re: sémantique move: précision
Posté par alice . Évalué à 3.
Du coup, c'est le copy on write qui est inutile :-)
[^] # Re: sémantique move: précision
Posté par barmic . Évalué à 3.
Non ce sont des choses différentes qui ont des objectifs différents :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: sémantique move: précision
Posté par lmg HS (site web personnel) . Évalué à 1.
Le COW sur les chaines et autres classes en C++ est avant toute une optimisation tournée vers les perfs. On pouvait y gagner sur les sorties de fonctions quand le (N)RVO ne s'appliquait pas, ou les stockages dans des conteneurs/tableaux.
Du coup avec l'arrivée de la sémantique de déplacement en C++, le seul intérêt restant est effectivement le partage de mémoire.
Vu le surtout à l'exécution (lock atomique qui n'est pas si gratuit que cela -> http://www.gotw.ca/gotw/045.htm), je doute que le COW soit maintenu à termes dans Qt (quoiqu'ils n'ont toujours pas ni namespace ni exceptions ...). D'ailleurs, si la chaine standard du C++11 a été rendue incompatible avec le COW, c'est bien tout sauf involontaire: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm
Le problème est que le partage de chaine serait le bienvenu sur les chaines immuables. Avec le COW, on a une sorte de tout-terrain qui certes passe partout, mais qui consomme plus.
[^] # Re: sémantique move: précision
Posté par GeneralZod . Évalué à 2.
Si le COW et le move permettent d'éviter des copies inutiles, il y a une subtilité, le COW permet à plusieurs objets de partager un état initial commun mais qui peut changer (donc on ne réalise la copie qu'au moment opportun), le move à deux objets d'échanger ce même état sans passer par un objet intermédiaire (un swap quoi) en te permettant de manipuler des références sur les rvalues.
Les deux techniques sont complémentaires, même si il est possible que dans certains cas, Qt remplace le COW par la sémantique move.
[^] # Re: sémantique move: précision
Posté par lmg HS (site web personnel) . Évalué à 0.
Le move n'est pas un swap. C'est comme son nom l'indique : un transfert de contenu et de responsabilité.
Complémentaire ? Où ? Dans les cas d'utilisation initiaux du COW ? C'est à dire /in/ et /out/ de fonction, nullement. Le COW n'était qu'un palliatif à un (N)RVO pas toujours appliqué, à des rvalue-references inexistantes, et à des utilisateurs qui ne veulent pas apprendre à se servir de "const&". Concrètement, les besoins de partage de chaines sont des plus réduits, ou trop simplistes (le COW n'a aucun rapport avec les chaines qui ne sont que des vues à l'intérieur de chaines plus importantes -- il pourrait (presque), mais n'a jamais été utilisé pour cela à ma connaissance -- cf les iterator_range utilisables sur boost.split: http://www.boost.org/doc/libs/1_48_0/doc/html/string_algo/usage.html#id3115768)
Les rvalue-reference vont rendre caduc le besoin technique majeur qui a conduit au COW dans les implémentations de QString et de certaines (pré 2011) de std::string -- par "besoin technique", je n'inclue pas les utilisateurs qui préfèrent s'en tenir à un sous-ensemble du langage très réduit, limite pré-98, et qui préfèrent donc copier en entrée/sortie de fonction.
[^] # Re: sémantique move: précision
Posté par Gof (site web personnel) . Évalué à 2.
L'objectif de Qt est aussi de rendre la programmation en C++ plus aisée.
Et c'est plus facile d'utiliser du COW que des rvalue reference au bons endroits.
Par exemple:
# QPA, enfin
Posté par reno . Évalué à 4.
D'après Wikipedia XCB a été commencé en 2001, la version 1.0 est sorti en 2006, Qt devrait utiliser XCB finalement avec la release 5.0 prévue pour 2012.
Bon, ce n'est pas spécifique à Qt, apparemment il y a du travail actuellement pour les EFL aussi sur ce sujet, mais la durée pour cette évolution laisse songeur, non?
[^] # Re: QPA, enfin
Posté par claudex . Évalué à 3.
Je n'y connais absolument rien dans le domaine mais ce n'est peut-être que depuis récemment que le passage de Xlib à xcb vaut vraiment la peine, même si xcb était déjà stable.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: QPA, enfin
Posté par Troy McClure (site web personnel) . Évalué à 2.
Peut etre que finalement XCB n'était pas si "nécessaire" que ça et que tout marche plutot bien avec la libX11
[^] # Re: QPA, enfin
Posté par reno . Évalué à 4.
Toi, tu n'es pas aller voir le lien que j'ai donné sur l'utilisation d'XCB par les EFL.
Gain indiqué dans l'article:
-lancement d'une application dans un tunnel ssh: 6s avec XLib, 1s avec XCB
-utilisation mémoire des EFL divisé par trois.
Donc, a priori, c'est intéressant..
[^] # Re: QPA, enfin
Posté par claudex . Évalué à 2.
Ce qui est vrai en 2011 ne l'était pas forcément avant.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: QPA, enfin
Posté par Littleboy . Évalué à 1.
Et donc tu as des donnees ou articles a nous faire partager sur le sujet?
[^] # Re: QPA, enfin
Posté par barmic . Évalué à 2.
Je pense que l'intérêt a était réduis du fait de la réécriture de la xlib en XCB, mais par design le gain est limité fasse à l'utilisation directe de XCB.
La question principale que je me pose c'est : « Est-ce qu'il reste pertinent de passer à XCB si on quitte X11 pour Wayland ? ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: QPA, enfin
Posté par Maclag . Évalué à 2.
Est-ce qu'on va vraiment quitter X11?
Si la décision n'est pas sure, combien de temps on attend avant de décider qu'on peut prendre une décision?
[^] # Re: QPA, enfin
Posté par barmic . Évalué à 1.
Il semble bien :
https://linuxfr.org/users/armorique/journaux/ubuntu-abandonne-x-pour-wayland#comment-1179014
Peut être qu'ils préfère travailler sur EGL.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: QPA, enfin
Posté par Gof (site web personnel) . Évalué à 1.
X11 restera sur desktop pendent encore quelques années. Simplement à cause du trop grand nombre d'application qui utilisent X11 qui vont être difficile à porter.
Il va y avoir une période de transition avec compositeur wayland par dessus X. (c'est ce que fera kwin: http://community.kde.org/KWin/Wayland )
Qt va utiliser Wayland pour l'embarqué uniquement dans un premier temps.
[^] # Re: QPA, enfin
Posté par reno . Évalué à 6.
1) le nombre de concurrent d'X morts-nés sont assez nombreux et Canonical qui dit vouloir passer à Wayland n'a pas de développeur qui bosse sur Wayland, donc la transition (quoique probable) est loin d'être assurée: Intel bosse dessus OK, mais Intel ce sont des vrais girouettes (cf Maemo).
2) Wayland ne remplace X que pour le cas local, il reste l'affichage en distant et X a l'avantage de fournir aussi une compatibilité avec l'existant.
En conclusion, si Wayland arrive un jour, pour l'entreprise au moins il ne fera que fournir un complément à X donc améliorer le support d'X reste intéressant.
[^] # Re: QPA, enfin
Posté par claudex . Évalué à 4.
Il y a des projets pour avoir une transparence réseau pour Wayland, le fait que ça n'arrivera pas avec la première release ne veut pas dire que ça n'arrivera jamais.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: QPA, enfin
Posté par Maclag . Évalué à 2.
Wayland ne pourrait-il pas être écarté au profit d'une révision majeure de X? (genre qui n'a pas peur de casser un peu la compatibilité pour se débarrasser de la masse morte...)
Parce que je pense que ce sera plus simple de porter vers un Xorg2.0 qui casse quelques trucs plutôt que vers un Wayland sur lequel il faut tout recommencer, je me trompe?
[^] # Re: QPA, enfin
Posté par barmic . Évalué à 3.
https://linuxfr.org/users/armorique/journaux/ubuntu-abandonne-x-pour-wayland#comment-1179014
Il semble qu'une partie des développeurs X cherchent a effectuer la transition vers Wayland.
L'utilisation de la combinaison des deux sera une étape transitoire il me semble.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: QPA, enfin
Posté par reno . Évalué à 2.
Dans le monde de l'entreprise, uniquement si la transparence réseau fournie par X est remplacé par quelque chose d'autre qui fonctionne "aussi bien", et même quand le client et le serveur utilisent des toolkit différents.
# Réseau: lapin compris.
Posté par Grunt . Évalué à 2.
C'est des "accès réseau" ou juste des "requêtes HTTP"? Il ne s'agit pas franchement de la même couche du modèle OSI ;)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Réseau: lapin compris.
Posté par Gof (site web personnel) . Évalué à 2.
C'est les requêtes HTTP:
Mais c'est toute la pile réseau pour ces requêtes qui est faite dans ce thread. Ça inclus TCP et SSL.
Cela permet à avoir un réseau plus rapide puisque le thread HTTP peut envoyer de nouvelle requêtes au serveur plus vite pendent que le thread principal est occupé à faire du rendu (webkit).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.