IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelques pensées sur Qt 5
Quelles seront les lignes directrices de la prochaine version majeure du framework C++ ?

Le , par dourouc05

0PARTAGES

2  0 
Qt 5, quelles seront ses lignes directrices ?


Six ans déjà que Qt 4.0 est sorti, en juin 2005. Depuis lors, beaucoup de choses ont changé dans l'industrie du logiciel : le développement se déroulait principalement pour le desktop, alors que les périphériques mobiles se sont répandus. L'interface utilisateur est passée de la souris au toucher, du statique au fluide. Sept versions mineures depuis cette époque ont permis à Qt de s'approcher des demandes actuelles, avec la sortie de Qt Quick par exemple. La base d'utilisateurs de Qt ne cessant de croître, il faut toujours rester proche des besoins nouveaux des développeurs.

Ainsi, pour rester à la pointe de la technologie, pour rester un framework leader dans l'industrie en général, Qt doit continuer à se renouveler. Qt 4 a été une évolution, les prochaines versions de Qt devront être dans sa perspective technique. Ces dernières années, de nouvelles fondations ont été esquissées pour la prochaine génération : Qt Quick, QML Scenegraph, Lighthouse, Qt WebKit.

En plus de son orientation vers l'open gouvernance, voici quelques pistes architecturales pour Qt 5.

Objectifs pour Qt 5

Mieux utiliser le GPU, pour obtenir des applications graphiques fluides et performantes, même avec peu de ressources.
Rendre la création d'application avancées plus facile et plus rapide, avec QML et JavaScript.
Faire en sorte que les applications connectées au Web soient aussi puissantes que possible, notamment au niveau de l'insertion de contenu Web dans des applications Qt.
Réduire la complexité et la quantité de code requise pour implémenter et maintenir un port.

Qt 4.7 contient encore du vieux code qui empêche certaines évolutions, qui empêchent Qt d'être aussi bon que possible pour la création d'applications next-gen. La plupart du code convient encore, alors que certaines parties bloquent le chemin de Qt 4.x.

Faciliter la migration entre Qt 4 et Qt 5

Avec Qt 5, il est prévu d'effectuer des changements bien précis dans les API pour abandonner certaines limitations du passé. La difficulté du portage de Qt 3 vers Qt 4 ne sera pas réitérée : la compatibilité des sources sera conservée pour la majorité des cas, alors que, à d'autres endroits, il sera nécessaire de la briser.

Il est actuellement envisagé de se focaliser sur un petit ensemble de systèmes supportés (Wayland, X11 pour Linux, en plus de Mac OS X et de Windows), le nombre total de plateformes supportées dépendra de l'activité de la communauté, suivant le principe de l'open gouvernance. Les autres systèmes d'exploitation ne seront pas maintenus par Nokia (principalement les UNIX commerciaux). Le but de Qt 5 est de fournir les meilleures fonctionnalités sur chaque plateforme, ce qui implique que l'on va d'abord fournir des fonctionnalités plus différenciées entre les OS, tout en offrant une réutilisation du code aussi efficace que possible pour la majorité des plateformes.

Développé ouvertement

Le modèle de développement va complètement changer entre Qt 4 et Qt 5, changement qui se profile depuis déjà longtemps : Qt 4 a principalement été développé par Trolltech puis Nokia, le fruit de ce travail a été publié. Qt 5 se veut développé par la communauté, un projet open source dès le tout début. Il n'y aura pas de différences entre un développeur de chez Nokia et un contributeur externe.

Vision

Qt 5 devrait être la fondation d'une nouvelle manière de développer des applications. En offrant toute la puissance de Qt en C++ natif, le focus sera déplacé vers un modèle, où le C++ est principalement utilisé pour implémenter les fonctionnalités derrière Qt Quick. Qt 5 mettra Qt Quick au centre, sans se couper du code déjà existant, il s'agira plus d'une restructuration. Les applications Qt/C++ traditionnelles vont continuer à fonctionner avec Qt 5, même si quelques changements vont être apportés sur les fondements de la manière de développer des applications.

On devrait s'attendre à ce que toutes les IU soient écrites en QML. JavaScript deviendra un citoyen de première classe de l'environnement Qt : beaucoup de logique, voire toute une application sera écrite en JavaScript, non en C++. Le but est que les développeurs commencent d'abord avec QML et JavaScript pour n'implémenter des fonctionnalités en C++ que lorsque cela est nécessaire. Dans ce cas, toute la puissance des API C++ pourra être utilisée pour implémenter des fonctionnalités plus complexes ou dont l'exécution doit être très rapide.

Le modèle basé sur QWidget sera conservé, les API liées aussi pour la compatibilité, mais le long terme devrait voir QML comme le futur des interfaces utilisateur pour desktop. La solution retenue sera probablement des composants basés sur QML qui s'intègrent dans le style natif des plateformes desktop.

Les quatre grands changements architecturaux

Les premiers changements sont déjà en cours depuis un certain temps, le travail débute pour le reste. La plupart de ces changements pourraient être effectués avant août.

Changer l'architecture de la pile graphique

Qt Quick et QML Scenegraph seront au centre de la nouvelle architecture. QPainter sera toujours disponible et est très utile pour bien des choses, mais il ne sera plus utilisé pour l'interface principale. Qt aura besoin d'OpenGL (ES) 2.0 pour fonctionner. Les QWidget seront rendus par-dessus le graphe de scène, pas l'inverse comme actuellement.

Qt Components et Qt Mobility feront donc partie intégrante de Qt, plus des modules avec un statut spécial.

Baser tous les ports de Qt sur Lighthouse

Le projet Lighthouse a été lancé pour fournir une meilleure manière pour abstraire l'intégration au système de fenêtrage que ce qui est actuellement disponible. La maturité est proche avec Qt 4.8, son utilisation sera probablement requise pour Qt 5.0.

Utiliser une structure de répertoires modulaire

Beaucoup a déjà été fait ces dernières semaines, le travail est d'ores et déjà visible dans les nouveaux dépôts : http://qt.gitorious.org/qt. Cette modularisation va permettre de faciliter et d'accélérer l'intégration de contributions à Qt.

Séparer les fonctionnalités liées à QWidget dans une bibliothèque distincte

Les classes basées sur QWidget sont actuellement très importantes ; le modèle va cependant changer et les IU seront principalement faites avec QML. Séparer les fonctionnalités basées sur QWidget est donc une manière d'obtenir une architecture propre dans Qt 5.

Beta fin 2011, version finale en 2012

On ne doit pas trop changer dans les fondations de Qt, on veut aussi rendre facile le portage d'applications vers Qt 5 : on ne peut donc pas changer trop dans la base de code déjà en place. Beaucoup des changements proposés se basent sur la modularisation de Qt, avec chaque bibliothèque partagée dans son propre répertoire. On devra supprimer quelques API rarement utilisées si elles se révèlent contraignantes à maintenir sans empêcher d'avancer. Du code en version beta devrait être disponible fin 2011, avec une version finale pour 2012.

Billet original

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Kikohs
Membre du Club https://www.developpez.com
Le 11/05/2011 à 14:42
JavaScript deviendra un citoyen de première classe de l'environnement Qt : beaucoup de logique, voire toute une application sera écrite en JavaScript, non en C++.
L'horreur !
2  0 
Avatar de xelif
Membre du Club https://www.developpez.com
Le 09/06/2011 à 11:12
OpenGL :

c'est précisé dans l'article que le support du GPU devrait être amélioré ce qui explique en partie la dépendance vers openGL 2.0.
et puis comment utiliser le QML SceneGraph sans openGL?

@Firwen : Pour le support de l'acceleration matériel : Pour les plateformes qui ne l'ont pas, comme les ordinateurs (sous linux ) avec de vieilles carte graphiques, cela ne devrait rien changer pour eux mais n'est ce pas un rêve d'avoir des performances et une acceleration matérielle si les pilotes ne sont plus supportés par les fondeurs de processeurs graphique?
(je me base sur ma propre expérience pour dire ca étant l'heureux possesseur d'une carte graphique ati x600.... )

QML
Je suis beaucoup mitigé c'est vrai concernant QML et javascript de manière générale, c'est déroutant pour les habitués du designer....

Cela ressemble a un jouet pour le moment, mais ca permet je pense de forcer le codeur à réfléchir un peu plus dans un style MVC et peut être une meilleure conception pour certaines applications.

Si cela permet en plus de moins galérer pour faire des interfaces graphiques sympas, et refilant le boulot à un designer ben pourquoi se priver?

@Causa tout le monde (ou presque connait) HTML/javascript/CSS, cela permet de prototyper des interfaces graphiques rapidement, donc pourquoi ne pas essayer avec Qt... De plus le javascript est un langage limité et simple d'utilisation. Il ne peux communiquer avec le système (j'ai pas vérifié les interaction systèmes avec le javascript de Qt) et est donc normalement sécurisé. Pour les parties : intéraction avec le système ou code critique c'est toujours Qt qui serait utilisé.
Je vais ajouter que : meme si avec Qt il y a généralement peu de fuite mémoires, ca limite encore plus ce genre d'erreurs.

Les dévelopeurs sont réfractaires au changement de manière générale, moi j'attends avec un impatience cette nouvelle mouture
2  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 11/05/2011 à 16:39
Voici même une réponse à tous ces commentaires : http://labs.qt.nokia.com/2011/05/11/...onses-to-qt-5/
1  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 11/05/2011 à 17:47
On sent la patte de Nokia qui cherche à unifier ses deux frameworks de développement, à savoir Qt (C++) et WRT (JavaScript).
1  0 
Avatar de mister3957
Membre expérimenté https://www.developpez.com
Le 11/05/2011 à 20:56
Moi je fais confiance ! Et j'ai hâte !
1  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 12/05/2011 à 17:31
Quelques infos supplémentaires sur ce qui sera retiré dans Qt 5 : http://labs.qt.nokia.com/2011/05/12/...evel-the-list/.
1  0 
Avatar de ness522
Membre averti https://www.developpez.com
Le 11/05/2011 à 16:03
Citation Envoyé par Kikohs Voir le message
L'horreur !
Bah je pense que c'est valable pour les dev du web, genre flash et autres petits jeux gentils.

Il sera bien sûr toujours possible de faire du C++ pour les applications sérieuses, avec une couche QML-javascript pour l'UI. Ca obligera peut-être à une meilleure séparation entre les deux et une meilleure conception en général.
0  0 
Avatar de DSGSLA
Membre régulier https://www.developpez.com
Le 11/05/2011 à 16:17
J'ai lu les 192 messages du billet original.
Très majoritairement les développeurs ne veulent pas de QML/Javasript, et ne comprennent pas la dépendance à OpenGL ES. Ils attendaient d'autres évolutions. Les réponses de l'équipe Nokia sont peu convaincantes, d'autant qu'elle ne propose aucun Proof Of Concept de la nouvelle orientation pour des application lourdes.

Conclusion : vers quelle bibliothèque graphique multi-plateforme en C++ et innovante se tourner ?

Remarque sur les réponses au billet : les utilisateurs de Qt sont plus polis que le moyenne des développeurs ou alors la modération est très sévère.
1  1 
Avatar de fregolo52
Expert confirmé https://www.developpez.com
Le 11/05/2011 à 16:52
Citation Envoyé par Kikohs Voir le message
JavaScript deviendra un citoyen de première classe de l'environnement Qt : beaucoup de logique, voire toute une application sera écrite en JavaScript, non en C++.
L'horreur !
Je n'y connais pas grand chose mais ça me fait penser à Gecko de Mozilla.
0  0 
Avatar de Firwen
Membre expérimenté https://www.developpez.com
Le 12/05/2011 à 9:29
Integration de javascript pour des petits développements léger et portable : why not ?.

La dépendance à OpenGL me semble beaucoup plus embêtante, étant donné que beaucoup de plate-formes ne dispose pas d'accélération 3D performantes
0  0