Trolltech, l'éditeur de la bibliothèque multiplateforme Qt, vient de mettre à disposition de tous la "technical preview" de Qt 4.4 alors que la version finale est encore "several months away".
La page de téléchargement est ici : http://trolltech.com/developer/downloads/qt/qt44-preview-dow(...)
Elle propose 4 versions différentes, Windows, Mac, Linux et Linux embarqué.
Une page des présentations des nouveautés est disponible : http://trolltech.com/products/qt/whatsnew/qt44-preview
Au niveau des nouveautés la plus remarquable est l'intégration au sein de Qt du moteur WebKit. Cela permet aux applications Qt d'avoir à disposition un moteur de rendu HTML 4.01, XHTML 1.1, XML, CSS 2.1, JavaScript 1.5, SVG 1.2, et qui implémente partiellement le CSS 3.
Il parait évident que ce moteur va remplacer KHTML dans l'environnement KDE (mais il y aura sans doute des remous de la part de certains développeurs).
On a ensuite l'intégration de Phonon, la couche d'abstraction multimédia de la branche 4 de KDE. On peut penser que Trolltech a absorbé Phonon car cela leur facilite le boulot pour déployer Qt sur différentes plateformes ayant différents moteurs multimédias (QuickTime pour Mac ou DirectShow pour Windows ou GStreamer pour Linux).
C'est quand même un signe que les relations Trolltech/KDE sont très étroites et cela démontre aux sceptiques (dont j'étais) que Phonon a sans doute été une bonne décision.
Il y a aussi une amélioration du support du XML avec le support des requêtes au format XQuery 1.0. L'inclusion d'un framework facilitant l'écriture de code multithreadé (sans avoir à s'embarrasser des mutexes et autres joyeusetés). Un nouveau système pour l'aide (QHelpSystem) qui n'est plus une grosse application mais devient une bibliothèque de programmes d'aides reposant sur une base SQLite.
En gros c'est quand même assez alléchant et le futur de KDE, qui reposera un jour ou l'autre sur cette version, s'annonce riant....du moins pour les versions ultérieures à la redoutable 4.0.0.
Journal Qt 4.4 : Version de démonstration
20
déc.
2007
# Précision/Question
Posté par lem__mel . Évalué à 2.
À lire en diagonale la page suivante : http://labs.trolltech.com/blogs/category/labs/threads/qt-con(...) le framework n'a pas forcément pour objectif de remplacer les mutexes et autres joyeusetés[1] pour les applications à exécution parallèle[2] : on dirait plutôt que un framework permettra de mieux exploiter le matériel (utilisation de n cœurs ou processeurs) dans le cadre d'exécution de traitements indépendants entre eux[3] ; ils utilisent pour cela l'idée déployée par Google dans leur MapReduce[4].
En bref, rien de vraiment nouveau sous le soleil on dirait, juste une facilité de dev accrue (ce que l'on peut attendre d'un bon toolkit :-)).
[1] attention, le journal ne l'a ni dit, ni laissé penser
[2] mon apport à la protection de la langue française ( pour multi-thread) :-)
[3]
- amis savants, à vos claviers pour donner des termes techniques ou des explications plus détaillées.
- remarquez également QFuture qui semblent être un mutex ++ (un mutex et un conteneur)
[4] me semble un peu excessif de citer Google pour cette idée : elle n'a rien d'exceptionnelle, et avait sûrement déjà utilisée bien avant ; peut être un brevet ?
[^] # Re: Précision/Question
Posté par Nicolas . Évalué à 2.
QtConcurrent permet d'utiliser autant de threads qu'il y a de coeur disponible sur la machine (utilisation d'une file d'attente s'il n'y a pas de coeur disponible).
L'intérêt, c'est surtout de ne pas se prendre la tête. Par exemple si l'on souhaite effectuer une tâche dans un thread (de façon asynchrone), il suffit juste :
* d'écrire la fonction,
* d'utiliser QtConcurrent::run(),
Maintenant, si l'on souhaite récupérer le résultat, deux façons de faire :
* avec QFuture : waitForFinished() ou result(), permet de synchroniser
* avec QFutureWatcher : un signal est émis à la fin de la tâche
Mais l'intérêt majeur, ce sont les fonctions map, mapped, mappedReduce (et filter...), qui permettent d'appliquer une tâche à une collection d'éléments de manière asynchrone, en utilisant le plus de threads possible, le tout ne nécessitant guère plus de 3-4 lignes.
Pour prendre un exemple, la lecture d'un ensemble d'images (pour un visualisateur d'images par exemple) nécessitent :
* écriture d'une fonction renvoyant un QImage à partir de son nom/chemin : QImage load( const QString& name );
* la création d'une liste avec le nom de toutes les images : QList imageName
* l'appel à mapped : QList image = mapped( imageName, load );
Et voilà, c'est magique !
[^] # Re: Précision/Question
Posté par rewind (Mastodon) . Évalué à 3.
Sinon, je voulais juste ajouter qu'Intel TBB joue un peu le même rôle que ça, c'est à dire offre des facilités de programmation parallèle pour des cas simples. Donc ce n'est pas très nouveau. Mais le fait que ça se démocratise est un bon point pour tout le monde. On ne va pas avoir des programmes qui vont d'un coup gagner en performances mais plutôt des petites améliorations à peine perceptibles, et c'est déjà très bien. On va exploiter un peu mieux les multi-coeurs.
[^] # Re: Précision/Question
Posté par Gof (site web personnel) . Évalué à 2.
> et autres joyeusetés
Qt porpose déjà une solution pour ça depuis longtemps, avec QThread, QMutex, QSemaphore, et autres joyeusetés.
Et le nouveau QAtomicPointer.
Ce qui rendais déjà facile l'utilisation de thread avec Qt.
(Mais bon, tout est toujours plus facile avec Qt :-D)
# Phonon
Posté par Gof (site web personnel) . Évalué à 2.
Phonon n'est pas sous double licence comme le reste de Qt.
Cela signifie que n'importe qui peux venir contribuer sans problème et sans avoir d'accord particulier ou d'autorisation de trolltech.
(Ce qui n'est pas le cas d'Apple avec webkit)
Celà signifie que le nombre de gens payés pour coder pour KDE est sur le point de dépasser le nombre de doigts de ma main. (c'est à la fois une bonne et une mauvaise nouvelle car j'aimais bien l'esprit ouvert et passionné de KDE, mais c'est bien que des entreprises s'interesse à KDE aussi)
En ce qui concerne le backed gstreamer, il ne fera pas partie de KDE 4.0 car il fut intégré après le gel des fonctionalités. Mais il sera tout de même disponible à part.
http://dot.kde.org/1197535003/
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Ouais enfin, c'est un peu dommage de voir ça sous cet angle, juste parce que des gens sont payés pour bosser sur Phonon hein.
Des gens sont payés également pour bosser sur le noyau linux. Et le noyau reste dans un esprit ouvert et passionné. L'important c'est la licence. C'est en quelque sorte une forte garantie.
[^] # Re: Phonon
Posté par Gof (site web personnel) . Évalué à 3.
Pas seulement.
L'ambiance de développement est aussi très importante.
« Ceux qui codent doivent être sympa »
Difficile de mettre ça dans une licence.
Et je n'ai pas dit que ceux qui était payés était moins sympa. Mais ils ont en général des motivations et des objectifs qui peuvent être différents.
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Dieu (ou Allah ou Boudha, ou Le Grand Capital) merci, chez Trolltech, on a encore le soucis de l'excellence technique en priorité.
Certes, on a aucune garantie que ça va se poursuivre toujours dans cette optique mais si Trolltech déconne, ne pas oublier que quasiment tout ce qu'ils font est en double-licence. Ils sont donc tenus à ne pas trop franchir la ligne rouge au risque de fork.
[^] # Re: Phonon
Posté par alice . Évalué à 3.
Toi tu n'as jamais jeté un coup d'oeil aux sources de Qt :-)
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Tu leur reproches quoi ? (je vais régulièrement regarder comment fonctionne Qt en interne et rien ne me choque vraiment alors ta réponse m'intéresse au plus haut point).
De toute façon, je suis tout d'abord plus intéressé par la rigueur déployée au niveau de l'API en elle-même que les tripes de la bibliothèque en elle-même.
Et une bonne API reflète et augure quand même pas mal de bonnes choses.
[^] # Re: Phonon
Posté par Philippe F (site web personnel) . Évalué à 1.
Par contre, niveau design des outils, je pense qu'ils peuvent mieux faire. Je m'explique. Quand Qt Designer est sorti, tout ceux qui ont voulu l'intégrer ont constate que l'architecture interne du bousin ne permettait pas une integration exterieure. Il a fallu attendre quelques années et une reecriture partielle pour que ça soit possible. même histoire avec qmake. Encore même histoire avec Qt/Help.
Je révere trolltech mais je suis quand même surpris que leurs outils ne soient plus pensés pour une intégration extérieure.
Espérons que QtHelp + QtDesigner + qmake leur aura fait comprendre cela.
Sinon, Qt, c'est bon mangez-en !
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Moi j'aimerais bien par exemple, qu'ils se penchent sur l'éventualité d'utiliser cmake pour leur système de build en lieu et place de qmake, car ça leur permettrait peut-être de déplacer des forces ailleurs. (Maintenant, s'ils ne l'utilisent pas, c'est qu'ils ont probablement des raisons que j'ignore.)
Je pense qu'on a tous des doléances plus ou moins importantes, malgré la qualité indéniable et inégalée (pour moi, en tout cas dans le domaine du logiciel type "lourd")) de ce framework. Et tout ce qui se passe actuellement me fait penser que ça ne va qu'en s'améliorant (sauf le temps de build du bouzin, malheureusement ;).
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
[^] # Re: Phonon
Posté par alice . Évalué à 2.
Ca dépend de la qualité à laquelle tu es habitué, mais je pense que tu ne pourras être que d'accord pour dire que le code de dessin des widgets est assez ignoble, avec de gros patés de switchs dedans :-)
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
2) En quoi un switch touffu est mauvais ?
3) T'as vraiment trouvé que ça ? ;-) Tu travailles pour un produit concurrent ? :o)
[^] # Re: Phonon
Posté par alice . Évalué à 2.
Jamais.
En quoi un code bordélique est mauvais?
Non et toi tu travailles pour Qt? S'il y a un plaie sur les ce sont bien les fanboys prêt à défendre leur produit ou marque préféré à tout prix...
[^] # Re: Phonon
Posté par windu.2b . Évalué à 2.
Et si possible, directement vers le(s) fichier(s) incriminé(s), et non un simple "télécharge tout le contenu du dépôt svn"...
Merci.
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
J'imagine que tu limites aussi tes types énumérés à 4 éléments ?
Parce que déduire qu'un gros switch signifie que le code de Qt 4 est bordélique, va falloir sacrément défendre ce point de vue. Bonne chance.
Parce que lorsque tu veux traiter un code suivant le type de couleur du QPalette par exemple, tu fais comment ? Tu sépares ton switch en plusieurs fonctions juste pour que ça tienne en moins de 24 lignes, comme on te l'a appris à l'école ?
Boarf, je demandais juste un exemple de code bordélique hein et tu me sors une histoire de gros switch en décrétant que c'est du code dégueulasse. Soyons sérieux. Moi j'en ai rien à foutre de défendre Qt à tout prix, par contre faut étayer quand on critique, sinon c'est comme pisser dans un violon.
[^] # Re: Phonon
Posté par alice . Évalué à 2.
[^] # Re: Phonon
Posté par Philippe F (site web personnel) . Évalué à 1.
Ca me parait pas choquant que ce code soit illisible. Souvent mon code optimisé devient illisible parce que certains raccourcis sont effectivement illisibles.
Je peux pas dire que un switch touffu résulte nécessairement de ce type d'optimisation mais ca semble quand même probable, surtout quand tu parles de dessin de widget noù la vitesse doit être la priorité.
Note qu'un gros switch s'optimise en général pas mal par le compilateur, en générant (horreur) des goto.
D'ailleurs, j'ai pas vu de goto dans Qt, preuve qu'ils codent proprement :-) Je suis même prêt à soutenir un troll qu'on code avec un goto peut être plus propre et plus lisible *dans certaines conditions* qu'un code sans goto (ou sans switch touffu puisqu'on y est).
[^] # Re: Phonon
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
# KHTML n'est pas mort
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: KHTML n'est pas mort
Posté par tanguy_k (site web personnel) . Évalué à 2.
mouais... ca n'a aucun interet pour l'utilisateur... surtout que les 2 moteurs sont proches. Netscape avait sortie une version ou il etait possible de choisir entre le moteur IE et gecko quand encore beaucoup de pages web ne s'affichaient pas bien sous gecko.
A mon avis WebKit survivra car il y a plus de monde derriere. J'imagine que ca va creer des frustrations pour quelques developpeurs KHTML : c'est pas evident de voir reprendre son bébé, surtout si le developpement ne se passe pas comme on le voudrait.
Donc, pour moi, KHTML va continuer a etre integrer a KDE4 quelques temps pour ne froisser personne et va finalement disparaitre avec le temps face a WebKit.
[^] # Re: KHTML n'est pas mort
Posté par GeneralZod . Évalué à 3.
http://zrusin.blogspot.com/2007/10/khtml-future.html
De toute façon, seul le meilleur survivra, et avec le support d'Apple, de Trolltech, et de bon nombre de développeurs de KDE, il y a de fortes chances que WebKit l'emporte. KHTML était une excellente base, WebKit a permis de maximiser son potentiel et de lui donner de la visibilité.
WebKit supporte plus de plateformes, avance plus rapidement, a été repris par nombre d'acteurs commerciaux (Nokia, Adobe, Trolltech) et sa part de marché explose. WebKit comble une bonne partie du "retard" sur Gecko.
Vous vous rappelez de egcs/gcc ?
En tout cas, merci et bravo à l'équipe KHTML et WebKit pour leur fantastique travail !
[^] # Re: KHTML n'est pas mort
Posté par tanguy_k (site web personnel) . Évalué à 1.
D'ailleurs ca serait cool qu'ils l'appellent a terme KHTML plutot que WebKit histoire de rendre a Cesar ce qui est a Cesar, mais bon peu de chance que ca arrive un jour :/
[^] # Re: KHTML n'est pas mort
Posté par Jean Roc Morreale . Évalué à 1.
[^] # Re: KHTML n'est pas mort
Posté par GeneralZod . Évalué à 2.
Certes, Zack Rusin est assez hargneux dans son billet, mais il répondait à une série de billet assez agressifs vis à vis des développeurs KDE engagés dans WebKit.
Quant à son dernier commit, il date de mars 2005 (et non pas d'il y a 4 ans). Si on se replace dans le contexte, avec un certain nombre de développeurs KDE clés comme Aaron Seigo ou Lars Knoll (mainteneur original de KHTML), George Staïkos (gros contributeur à KHTML) ont considérés sérieusement de fusionner les deux projets (Unity) après qu'apple ait décidé d'ouvrir le développement sous la pression de KDE.
Ils ont choisi de soutenir WebKit, non pas parce sous la pression d'un éventuel employeur, mais pour de bonnes raisons (Cf le billet de Z. Rusin).
Le gros du boulot de l'équipe KHTML s'est borné depuis quelques années à appliquer les patchs provenant de WebKit, hein.
Même si ils ne contribuent plus à KHTML directement, les développeurs KDE contribuant à WebKit ont parfaitement leur mot à dire contrairement à ce que prétend l'équipe actuelle.
C'est une guerre interne entre deux factions de développeurs KDE, point barre.Comme egcs ou php en son temps, le fork est meilleur que l'original, soit on est mature et on se réconcilie, soit on s'obstine. Aujourd'hui, KDE4 n'a aucune raison de privilégier KHTML à WebKit.
[^] # Re: KHTML n'est pas mort
Posté par Jean Roc Morreale . Évalué à 1.
"Le gros du boulot de l'équipe KHTML s'est borné depuis quelques années à appliquer les patchs provenant de WebKit, hein."
Assez basse cette remarque, surtout quand il suffit de jeter un oeil sur le svn pour observer qui a fait quoi (allez je file l'adresse, http://websvn.kde.org/trunk/KDE/kdelibs/khtml/ ). J'insiste, ce qui m'énerve royalement ce sont les commentaires mal-informés et insultants que se mangent dans la gueule les devs qui ont fait le plus gros du travail ces dernières années.
Promis, ma bonne résolution 2008 sera d'éviter les flamewars.
[^] # Re: KHTML n'est pas mort
Posté par GeneralZod . Évalué à 2.
Ça c'est pas une attaque personnelle gratuite ? Et y en a d'autres.
Comme toujours, le monde n'est pas noir ou blanc.
> les devs qui ont fait le plus gros du travail ces dernières années.
Personne ne dit qu'ils se sont contentés d'appliquer des patchs mais ça constitue une bonne partie de leur boulot. Mais on oublie que les développeurs KDE contribuant aujourd'hui à WebKit ont été de gros contributeurs à KHTML auparavant incluant l'auteur initial du code !
Quant ils ont constaté que le gros du boulot était d'appliqué des patchs provenant de WebKit, ils ont préférés travailler directement sur WebKit dès qu'Apple a ouvert le développement.
Alors c'est un peu facile de leur dire: "ouais mais ça fait un moment que vous ne contribuez plus au code (de KHTML)". Indirectement leur boulot est retombé dans KHTML, mais l'équipe actuelle feint de l'ignorer et les assimile à des "blablateurs qui en branlent pas une".
Moi, ce qui me fait chier, c'est de voir un petit groupe verrouiller la question du moteur de rendu de KDE4 non pas pour des raisons techniques ou éthiques mais par amour-propre.
Ce que je constate c'est que l'équipe KHTML n'a aucun véritable argument contre l'introduction de WebKit dans KDE. Personne n'ayant parlé de virer KHTML, auraient-ils tout simplement peur de la comparaison ?
Hein, avec la technologie KParts, KDE n'a aucun problème pour gérer deux moteurs de rendu
# Elimination du "flicker" dans les fenetres X11
Posté par tanguy_k (site web personnel) . Évalué à 1.
QtWebKit utilise WebKit 3, listes des ameliorations par rapport a la v2 :
http://webkit.org/blog/122/webkit-3-10-new-things/
A noter aussi que Qt 4.3 tourne de facon experimentale sous Windows CE. http://trolltech.com/developer/downloads/qt/qt-windows-ce
Un peu d'OpenGL sous WinCE : http://www.youtube.com/watch?v=P7XZsNtSoQQ&eurl=http://l(...)
IPhone "cover flow" avec Qt 4 sous Qtopia et WinCE :
http://www.youtube.com/watch?v=-zy5pWcBAaQ&eurl=http://l(...)
http://code.google.com/p/pictureflow/
http://www.youtube.com/watch?v=v2yN0F7_YlI&feature=relat(...)
D'autres videos Qt 4:
http://www.youtube.com/watch?v=uxQFY4mp_E0&feature=relat(...)
http://www.youtube.com/watch?v=YeWruO5gP0o&feature=relat(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.