Journal Qt 4.0 Beta1 : à vous de tester :p

Posté par  .
Étiquettes : aucune
0
22
déc.
2004
Bonjour !!

Ha, quel bon mois de décembre :)
Après Directfb 0.9.21 (http://linuxfr.org/~phhusson/16472.html(...)), voici Qt 4.0 beta1 :)
Quel est le rapport ? Hé ben Qt 4 devrait permettre d'utiliser Directfb pour toutes les applis utilisant Qt sans trop de cabrioles, et donc toutes les applis KDE 4 (qui utilisera qt4)
J'ai pas encore eu le temps de la tester (je m'empresse de le faire :) ) mais voici quelques fonctionnalités intéressantes (cf http://dot.kde.org/1103717662/(...) notamment) :
- Première version de qt4 (déjà deux technology preview...) qui inclue le nouveau qt designer : http://doc.trolltech.com/4.0/qt4-designer.html(...)
Ce nouveau qt designer s'intègrera sans difficulté dans les autres applis normalement, dont Kdevelop. Même si ça fait doublon avec KDevDesigner (j'ai un doute sur le nom :/ ) ça reste une bonne nouvelle
- Librairies scindées : ça c'est le principal ! Avec, on avait un libqt.so énorme contenant QtXML, la lib graphique, la lib OpenGL... Maintenant, c'est séparé, avec à la clé un chargement plus rapide vu que le fichier à lire sera bien plus léger.
- Utilisation de certaines fonctionnalités C++ précédemment évitées (du fait de mauvais compilateur) comme les namespace
- Nouveau moteur de rendu de texte (Scribe)
- Nouveau moteur de dessin (Arthur), bien mieux que le QCanvas actuel :)
Et plein d'autres :)

Par contre, il y aura rupture de la compatibilité binaire et même source ! Néanmoins, une lib permettant la compatibilité (source probablement) avec les applis Qt3 sera dispo...

À noter, les performances des applis Qt4 seront bien bien meilleures que celles des applis Qt3 ! Et la conso mémoire plus faible...
La version finale sortira à la fin du premier trimestre 2005, et on peut espérer un KDE 4 à la fin de 2005 :)

  • # Correction

    Posté par  . Évalué à 5.

    Je me permet de corriger une faute :
    - Librairies scindées : ça c'est le principal ! Avec, on avait un libqt.so énorme contenant QtXML, la lib graphique, la lib OpenGL... Maintenant, c'est séparé, avec à la clé un chargement plus rapide vu que le fichier à lire sera bien plus léger.

    Il fallait bien sûr lire :
    - Librairies scindées : ça c'est le principal ! Avant, on avait un libqt.so énorme contenant QtXML, la lib graphique, la lib OpenGL... Maintenant, c'est séparé, avec à la clé un chargement plus rapide vu que le fichier à lire sera bien plus léger.

    • [^] # Re: Correction

      Posté par  . Évalué à 2.

      > Maintenant, c'est séparé, avec à la clé un chargement plus rapide vu que le fichier à lire sera bien plus léger.

      Ca c'est pas trop vrai accessoirement, sur un disque moderne, ce qui est couteux c'est le positionnemenet de la tête de lecture du disque au début de ton fichier, pas la lecture en elle-même, c'est limite aussi coûteux de lire 16 octets que de lire plusieurs megas. Là en plus vu que t'as plusieurs libs différentes à charger au lieu d'une seule, ça serait pas surprenant que le temps de chargement soit au contraire plus grand...

      • [^] # Re: Correction

        Posté par  . Évalué à 4.

        Des grands débats sur le performances de KDE/Qt j'ai retenu que le Grand Coupable de la lenteur des applications était l'édition dynamique des liens dans le cas de nombreuses méthodes virtuelles.

        Si on considère que le bureau KDE va probablement charger en mémoire toutes les librairies et que chaque application ne va demander que l'édition dynamique des liens dont elle a besoin, est-ce que ça ne vas pas produire une diminution du temps de lancement des applications KDE ?

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Correction

          Posté par  (site web personnel) . Évalué à 2.

          Si c'est vraiment ça (j'en sais fichtrement rien), il y a un patch pour gcc (qui sera intégré dans le 4.0.0 il me semble) qui s'appellle visibility dont le but est de caché explicitement des symbols inutils, et les différences apportées sont que les libs sont plus légère (comme après un strip?), et justement le link plus rapide.
          (Si PieD repasse par ici il te retrouvera surement l'url ;)

          • [^] # Re: Correction

            Posté par  . Évalué à 4.

            il y a un patch pour gcc (qui sera intégré dans le 4.0.0 il me semble)
            Le patch est intégré dans gcc 4.0
            caché explicitement des symbols inutils, et les différences apportées sont que les libs sont plus légère (comme après un strip?)
            cachER :)
            Ça n'a rien à voir avec un strip !! Un strip fait que tous les symboles exportés le resteront, je sais plus exactement quelles infos disparaîtront...


            GROS avantage : il y a déjà du travail sur le CVS de KDE pour profiter des avantages de ce patch ! Et d'après les testeurs les perfs sont bien meilleures. Plus d'infos dans le KDE CVS digest du 19 novembre : http://cvs-digest.org/index.php?issue=nov192004(...)

            • [^] # Re: Correction

              Posté par  . Évalué à 4.

              Le prelink c'était pas déjà censé améliorer ces performances de chargement des libs dynamiques ? Avec un strip, t'as toutes les infos de debug (n° de ligne, ...) qui disparaissent.

              • [^] # Re: Correction

                Posté par  (site web personnel) . Évalué à 1.

                Ben si et il le fait....
                Mais autrement, càd qu'il garde les addresses des fonctions des autres libs en memoire (enfin en gros et je crois)

              • [^] # Re: Correction

                Posté par  . Évalué à 2.

                Oui mais prelink est chiant à utiliser !! Faut le lancer sur chaque système où tu fous la lib, alors que là, le patch modifie la lib générée on en parle plus.
                Après libre à toi de prélinker la lib avec changement de visibilité :)

                • [^] # Question ?

                  Posté par  . Évalué à 1.

                  > Quel est le rapport ? Hé ben Qt 4 devrait permettre d'utiliser Directfb
                  > pour toutes les applis utilisant Qt sans trop de cabrioles,
                  > et donc toutes les applis KDE 4 (qui utilisera qt4)...
                  > J'ai pas encore eu le temps de la tester (je m'empresse de le faire :)...

                  tout ca c bien gentil mais comment je pe faire pour compiler le qt4beta1 avec le support du directfb ? avez-vous tester ?

                  • [^] # Re: Question ?

                    Posté par  . Évalué à 2.

                    C'est pas pour maintenant ce genre de choses.
                    "Qt 4 devrait permettre d'utiliser Directfb"
                    J'ai employé du conditionnel :(

          • [^] # Re: Correction

            Posté par  . Évalué à 2.

            deux choses :

            - les attributs "visibility" de gcc : utile pour les fonctions à liaison externe mais non-destinées à être utilisées depuis l'extérieur. L'effet rechercher c'est de virer les symboles privés de la table. http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Function-Attributes.htm(...)
            ça marche très bien. La Glib fournit des macros portables pour utiliser ces attributs.

            -point noir pour le C++ : les fonctions appartenant à un namespace anonmye ont une liaison externe : ceci pose un problème car après optimisation, la définition d'une fonction n'est plus nécessaire, mais à cause de sa liaison, sa définition est cependant émise
            http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267(...)

  • # Gruik?

    Posté par  (site web personnel) . Évalué à 3.

    >fait doublon avec KDevDesigner

    C'est quoi cet outils? Dans le Kde actuel, c'est qtdesigner qui gere les widgets Kde, donc je vois pas le probleme. J'ai loupé un truc? :)

    • [^] # Re: Gruik?

      Posté par  . Évalué à 2.

      http://webcvs.kde.org/kdevelop/kdevdesigner/README?rev=1.1&view(...)

    • [^] # Re: Gruik?

      Posté par  . Évalué à 4.

      KDevDesigner c'est juste QtDesigner à la sauce kde pour plus ou moins bien s'intégrer à kdevelop.
      A mon avis il sera abandonné vu que le nouveau QtDesigner sera plus facile à intégrer à des environnements externes.

      • [^] # Re: Gruik?

        Posté par  . Évalué à 2.

        KDevDesigner c'est juste QtDesigner à la sauce kde pour plus ou moins bien s'intégrer à kdevelop.
        L'intégration à kdevelop est optionnelle ! C'est surtout qu'il a été développé par et pour Kexi, afin de fournir un éditeur de formulaires à la Access. Après y'en a qui l'ont intégré dans Kdevelop, tant mieux ! :)

  • # Compatibilité source/binaire

    Posté par  . Évalué à 10.

    Par contre, il y aura rupture de la compatibilité binaire et même source !

    Ben c'est normal. Avec QT et KDE la règle est toujours rigoureusement la même :

    Changement de release (x.y.2 -> x.y.3), compaibilité binaire.

    Changement de version mineur (x.1.y -> x.2.z), pas de compatibilité binaire, mais compatibilité source.

    Changement de version majeur (3.x.y -> 4.z.t), ni compatibilité binaire, ni compatibilité source.

    • [^] # Re: Compatibilité source/binaire

      Posté par  (site web personnel) . Évalué à 3.

      Changement de version mineur (x.1.y -> x.2.z), pas de compatibilité binaire, mais compatibilité source.


      Si, il y a compatibilité binaire.

      Un programme compilé pour KDE 3.0 avec QT 3.0 fonctionnera très bien sous KDE 3.4.
      L'inverse n'est pas vrai, car il y a des évolutions.

      • [^] # Re: Compatibilité source/binaire

        Posté par  . Évalué à 5.

        Bah oui, mais pour moi "compatibilité binaire" c'est ascendant et descendant.

        des libs KDE ou QT 3.0.0 sont complètement interchangeables avec des 3.0.1, si tu compiles avec du 3.0.1 ça marchera avec du 3.0.0

        En fait ces releases correspondent à des bugfixes.

        Par contre, la compatibilité source c'est ascendant uniquement : tu recompiles une appli 3.0 avec des libs 3.1 ça doit marcher sans problème, mais recompiler du 3.1 avec du 3.0 c'est pas du tout garanti.

        Enfin pour en revenir au point de départ, la non compatibilité source n'est pas une surprise, cela a déjà été le cas avec KDE 1, KDE 2, KDE 3 (et les QT 1, 2, 3), donc il eût été surprenant qu'il n'en soit pas ainsi avec KDE/QT 4.

        C'est d'ailleurs pour cela que KDE 3.0.0 n'avait pas grand chose de plus que la dernière release de KDE 2. Les développeurs avaient travaillé principalement à faire le portage en QT3. Ensuite, pour KDE 3.1, les développeurs disposaient d'un framework qui leur a permis de mettre des nouveautés exploitant les possibilités offertes par QT3.

  • # Ancienne news

    Posté par  (site web personnel) . Évalué à 6.

    Je me permet de mettre l'URL d'une news que j'avais envoyé sur les nouveautés de QT4.

    http://linuxfr.org/2004/04/20/16022.html(...)

  • # Quelques précisions.

    Posté par  . Évalué à 10.

    J'été justement en train de rédiger un journal là-dessus, mais bon, je me suis fait griller.

    Alors quelques précisions :
    La version béta intégre une pré-version de Designer (il n'est pas possible de créer des MainWindow par exemple, il n'y a pas encore de dialogue de modifications des propriétés courantes d'un widget...). Par contre, il y a une grosse amélioration conernant l'utilisation du Designer. En effet, il n'y a plus ni besoin de fichier ui.h, ni besoin d'hériter (voir http://doc.trolltech.com/4.0/designer-using-a-component.html(...) )
    Il y a aussi Linguist, et un nouvel outil qui permet d'aider à faire le portage de Qt3 à Qt4 (je n'ai pas essayé encore).
    Plus de précision là : http://doc.trolltech.com/4.0/qt4-intro.html(...)

    Comme dit dans la news, la nouveauté vient de la découpe de Qt en plusieurs bibliothèques (core, ui, xml, sql...), ce qui va permettre d'alléger les programmes, et d'utiliser notamment le core (avec les signaux/slots, QObject) sur des machines sans X (ne dépend pas des bibliothèques graphiques).

    Qt4 est basé sur 5 nouvelles technologies (/!\ avis subjectif à la clef) :
    Tulip ( http://doc.trolltech.com/4.0/qt4-tulip.html(...) ) : ensemble de containers (list, map...), complètement intégré à Qt, et plus simple d'utilisation que la STL
    Interview ( http://doc.trolltech.com/4.0/qt4-interview.html(...) ) : nouvelle architecture pour les listes d'items, les tables... basée sur une architecture Model/View (avec en plus des sélections partageables entre plusieurs vues), enfin !
    Arthur ( http://doc.trolltech.com/4.0/qt4-arthur.html(...) ) : nouveau système de dessin, il va permettre de faire des trucs complètement fou comme par exemple dessiné dans une fenêtre OpenGL avec un QPainter
    Scribe ( http://doc.trolltech.com/4.0/qt4-scribe.html(...) ) : nouveau système de rendu du texte
    MainWindow ( http://doc.trolltech.com/4.0/qt4-mainwindow.html(...) ) : nouveau système de gestion des fenêtres principales, avec notamment une meilleur prise en charge des docks et toolbars

    Petite rectification, Arthur n'est pas un remplaçant de QCanvas, mais de toutes les routines de dessin (avec notamment un double buffering automatique). Il n'y a pas de remplaçant à QCanvas dans la 4.0.0, il arrivera dans la 4.1.0 normalement (voir peut être avant).

    Téléchargement ici : http://www.trolltech.com/download/betas.html(...) , avec de nombreux exemples à la clef.

    N'hésitez pas à faire un tour du côté de la communauté francophonne Qt : http://prog.qt.free.fr/portal.php(...)

    • [^] # Re: Quelques précisions.

      Posté par  . Évalué à 4.

      Petite rectification, Arthur n'est pas un remplaçant de QCanvas, mais de toutes les routines de dessin (avec notamment un double buffering automatique). Il n'y a pas de remplaçant à QCanvas dans la 4.0.0, il arrivera dans la 4.1.0 normalement (voir peut être avant).
      Désolé pour ce vulgaire amalgame (bien que je n'ai pas explicitement dit ça)
      En fait, j'ai dit ça parce que j'ai vu sur une interview d'un développer / un site d'un programme que Qt4 permettra de résoudre les problèmes du Canvas en passant par arthur... J'aurais du contrôler mes infos avant :/

      Merci pour ta précision !

      • [^] # Re: Quelques précisions.

        Posté par  . Évalué à 2.

        Désolé pour ce vulgaire amalgame (bien que je n'ai pas explicitement dit ça)
        En fait, j'ai dit ça parce que j'ai vu sur une interview d'un développer / un site d'un programme que Qt4 permettra de résoudre les problèmes du Canvas en passant par arthur... J'aurais du contrôler mes infos avant :/

        C'est vrai, après relecture, tu n'as pas explicitement dis ça, en effet... mais bon, une lecture rapide peut être trompeuse.
        Et c'est vrai que ma phrase est peut être un peu agressive, mais je voulais juste insiter sur ce point, pour éviter tout malentendu... et puis j'étais dégoûté de m'être fait griller à 10 minutes ;)

  • # A quand de beaux thèmes pour QT?

    Posté par  . Évalué à -10.

    Une feature que j'attend depuis longtemps c'est l'arrivée de beaux thèmes pour QT.
    A croire que les utilisateurs de KDE aiment tous le thème keramik et le thème d'icones Crystal...

  • # hummm

    Posté par  . Évalué à 3.

    y'aurait du screenshoutte ? :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.