mardi 07 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de PieD :

Journal : Qt 4.0 Beta1 : à vous de tester :p

Posté par Pinaraf (Jabber id, ) le 22 décembre 2004
0
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 :)

> Lire le journal (32 commentaires, moyenne: 3,3).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Correction

Posté par Pinaraf (Jabber id, ) le 22/12/2004 à 13:33. (lien). É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 Christophe Fergeau () le 23/12/2004 à 09:45. (lien). É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 Aurélien Girard () le 23/12/2004 à 10:15. (lien). É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 ?

      • [^]Re: Correction

        Posté par Ph Husson (page perso, ) le 23/12/2004 à 11:37. (lien). É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 Pinaraf (Jabber id, ) le 23/12/2004 à 12:14. (lien). É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 Christophe Fergeau () le 23/12/2004 à 14:55. (lien). É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 Ph Husson (page perso, ) le 23/12/2004 à 15:31. (lien). É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 Pinaraf (Jabber id, ) le 23/12/2004 à 16:18. (lien). É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 thomas (page perso, ) le 26/12/2004 à 13:42. (lien). É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 Pinaraf (Jabber id, ) le 26/12/2004 à 14:07. (lien). É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 TazForEver () le 27/12/2004 à 01:04. (lien). É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 gnumdk (page perso, ) le 22/12/2004 à 13:37. (lien). É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 Narishma Jahar () le 22/12/2004 à 15:53. (lien). É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 Pinaraf (Jabber id, ) le 24/12/2004 à 08:53. (lien). É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 ! :)

      • [^]Re: Gruik?

        Posté par Narishma Jahar () le 24/12/2004 à 14:47. (lien). Évalué à 1.

        Je ne penses pas. L'éditeur de formulaires de Kexi s'appelle KFormDesigner, et n'a (d'après ce que je sais) rien à voir avec QtDesigner. Il a beaucoup moins de fonctionnalités (ce qui est tout a fait logique vu l'utilisation qui en est faite). D'ailleurs aseigo le compare au nouveau QtDesigner dans son blog d'hiers. (http://aseigo.blogspot.com/2004/12/qt-designer-redux-kformdesigner.(...))

        Je peux me tromper biensur...

        • [^]Re: Gruik?

          Posté par Pinaraf (Jabber id, ) le 24/12/2004 à 15:41. (lien). Évalué à 2.

          Je crois que KDevDesigner == KFormDesigner, car sur le site de kdevelop on parle de l'intégration de KDevDesigner qui permet d'avoir enfin un EDI RAD...
          Et sur kde-apps : http://www.kde-apps.org/content/show.php?content=14796(...) pour KFormDesigner parle de l'intégration dans Kdevelop...

Compatibilité source/binaire

Posté par peau chat () le 22/12/2004 à 14:06. (lien). É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 Gof (Jabber id, page perso, ) le 22/12/2004 à 17:56. (lien). É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 peau chat () le 23/12/2004 à 08:54. (lien). É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 patrick_g (page perso, ) le 22/12/2004 à 14:18. (lien). É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 Nicolas (page perso, ) le 22/12/2004 à 15:26. (lien). É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 Pinaraf (Jabber id, ) le 22/12/2004 à 19:23. (lien). É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 Nicolas (page perso, ) le 22/12/2004 à 19:43. (lien). É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 Simon TRENY () le 22/12/2004 à 15:36. (lien). É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...

  • [^]Re: A quand de beaux thèmes pour QT?

    Posté par PasChauve PasOunet () le 22/12/2004 à 15:42. (lien). Évalué à 8.

    Oh le troll tout naze.

    A croire que tu n'es jamais allé sur kde-look et que tu connais tres mal les users kde , keramik ainsi que crystal sont tres tres loin ( même pas dans les 10er pour ceux que cites... ) d'être les themes les plus plebiscités/utilisés.

    • [^]Re: A quand de beaux thèmes pour QT?

      Posté par gnumdk (page perso, ) le 22/12/2004 à 17:12. (lien). Évalué à 6.

      http://kdelook.org/content/show.php?content=18223(...)

      Voila le number one des themes Qt.

      http://kdelook.org/content/show.php?content=5358(...)

      Bon pour les icones c'est ca mais je vois pas bien le rapport avec Qt quand meme la :p

      Perso, mes gouts correspondent exactement à ceux des utilisateurs de kdelook :
      Lipstik + Nuvola + Crystal(pour kwin)

      • [^]Re: A quand de beaux thèmes pour QT?

        Posté par Narishma Jahar () le 22/12/2004 à 19:18. (lien). Évalué à 5.

        J'utilise aussi Lipstik et Nuvola, par contre pour kwin je n'ai pas trouvé de thème qui me convient alors je laisse le Plastik de base.

hummm

Posté par MsK` () le 22/12/2004 à 18:31. (lien). Évalué à 3.

y'aurait du screenshoutte ? :)

--
\_o<~~~~

  • [^]Re: hummm

    Posté par Pinaraf (Jabber id, ) le 22/12/2004 à 19:23. (lien). Évalué à 4.

    Je t'invite à consulter la documentation de Qt pour de plus amples informations/démonstrations...
    Qt 4 fournit surtout des nouvelles technologies comme Arthur : http://doc.trolltech.com/4.0/qt4-arthur.html(...)
    Les captures sont pas intéressantes si on voit pas la taille du code à côté :p
    Sinon je viens d'essayer le nouveau designer : leur drag and drop est simplement excellent ! Quand tu commences à glisser un bouton, tu vois une image du bouton que tu déplaces c'est vraiment agréable à utiliser...
    http://doc.trolltech.com/4.0/qt4-designer.html(...)

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1181s (dont 0.0115 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !