Portage de Qt 4.5.1 sous Haiku

Posté par  . Modéré par Sylvain Rampacek.
Étiquettes :
29
22
oct.
2009
Haiku
Qt, la bibliothèque C++ multi-plateforme à tout faire, est portée sous Haiku, le pendant libre de feu BeOS. Voici l'occasion pour une présentation de ce portage, de ce qu'il apporte, et de l'API native d'Haiku.

Ce n'est pas la première fois qu'un portage de Qt pour BeOS est réalisé. Le premier remonte à 2001, du temps de Qt2. À l'époque, X-Window était nécessaire, alors que BeOS dispose de son propre système graphique. Ce portage, mal intégré, n'a pas eu un grand succès. Cette fois-ci, c'est un portage de la dernière version stable, la 4.5 (la 4.6 devrait sortir pour la fin de l'année), et X-Window n'est plus nécessaire. Plusieurs programmes d'exemples ont été compilé, comme Arora, un navigateur Web utilisant WebKit (intégré à Qt depuis la version 4.4). La disponibilité de ce navigateur devrait combler un gros manque d'Haiku, car actuellement le navigateur livré dans Haiku est un portage de Firefox2 qui n'est pas connu pour sa vélocité.

Ce portage de Qt fait suite à la disponibilité de la première Alpha de Haiku il y a quelques semaines.

Le portage d'une bibliothèque de cette qualité est une très bonne chose et rend le slogan de Qt (Qt everywhere) encore plus vrai. Mais il ne faut pas oublier qu'Haiku dispose de sa propre API, qui est quasiment la copie conforme de celle de BeOS. En C++, l'API native de Haiku est décrite en détail dans le BeBook et les spécificités de Haiku dans le Haiku Book.

L'API est divisée en « Kit » qui regroupent différentes classes selon leur thématique (noyau, interface graphique, réseau, mail, système de fichier, OpenGL, etc.). Bien qu'elle souffre de certains manques en raison de son âge (comme l'absence de système d'internationalisation ou de positionnement des éléments graphiques), mais qui devraient être comblés dans les prochaines versions de Haiku, elle offre tout de même des concepts fort intéressants. On peut citer notamment les Translators (qui permettent de rendre la lecture/écriture d'un nouveau format de fichier facilement ajoutable à toutes les applications utilisant les Translators, les BMessages (qui encapsulent des informations et qui sont à la base de tout le système de messages/événements d'une application native), les BQuery (qui utilisent toutes la puissance du BeFS, le système de fichiers d'Haiku utilisant massivement les métadonnées et dont l'interrogation est aussi rapide qu'une base de données) ou encore les Replicants (un équivalent au KPart de KDE).

L'avenir nous dira si ce portage est un succès.

Attention : le portage de Qt sous Haiku est une première version, ne vous attendez pas à une stabilité à toute épreuve !

Aller plus loin

  • # Thread?

    Posté par  . Évalué à 4.

    Excellente nouvelle!
    Je viens justement de passer un peu de temps a essayer de comprendre le fonctionnement des threads dans BeOS.
    En fait, je voudrais rendre une application Qt4 plus réactive. Pour cela, je pense copier le fonctionnement de BeOS en essayant de mettre en place des threads séparés pour les traitements non liés à la GUI. Ça a l'air un peu lourdingue à faire parce qu'il faut passer par des signaux/slots pour tout.
    Dans BeOS ^Haiku il y a des threads partout par défaut, et au moins un thread par fenêtre. J'ai l'impression que dans Haiku l'application sera plus réactive "par défaut" (en utilisant le modèle de programmation BeOS).

    Je suppose que ce portage ne remet pas en cause le modèle de thread utilisé par Qt (un seul thread pour la partie GUI), mais ne risque-t-on pas de perdre la réactivité d'Haiku dans les applications Qt portées?
    • [^] # Re: Thread?

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

      Tu as une interface de gestion multi-thread sous Qt, donc, ils l'ont peut-être adaptée pour qu'elle interface celle d'Haiku ?

      There is no spoon...

      • [^] # Re: Thread?

        Posté par  . Évalué à 2.

        Tu as une interface de gestion multi-thread sous Qt
        Si c'est de QThread dont tu parles, je pense qu'effectivement le portage a consisté a s'interfacer aux threads d'Haiku. Cependant, le modèle de thread de Qt reste le même: un seul thread pour la GUI.
    • [^] # Re: Thread?

      Posté par  . Évalué à 3.

      Tiens ça me rappelle mon bref cours de programmation Windows pendant mes études (ça commence à dater un peu j'avoue).
      J'avais vaguement compris que Windows utilise massivement les thread, me trompe-je ?
      D'ailleurs, toujours selon mes souvenirs, il n'y a pas de fork() sur windows.

      En y repensant, est-ce que c'est pour ça que Windows est plus réactif qu'un gnome ou qu'un KDE sur ma machine?

      je vais peut-être subir un moinssage en règle, mais je ne veux pas alimenter le troll. !
      Mais il est vrai que Gnome a plus de fonctionnalité que le genstionnaire de fenêtre de Windows, mais Windows est un peu plus rapide chez moi...
      • [^] # Re: Thread?

        Posté par  (Mastodon) . Évalué à 2.

        L'impression de vélocité donné par Windows est une impression bien réelle et nullement sujete à troll. Pour l'expérience utilisateur, mr michu voit clairement que Windows "va plus vite". Point.
        Ceci est bien entendu massivement bémolé par la consommation des ressources d'une part (cpu et mémoire vive), et d'autre part par le fonctionnement même. Car par exemple cette impression de rapidité est souvent donnée par le simple que Windows est très intégré d'une part, et procède à de nombreux pré-chargement d'autre part.

        Une comparaison simple peux se faire avec OpenOffice : tu fais un pre_load des biblio et hop, ooo.org se charge en 5 secondes sur OpenSuSe/Mandriva/Ubuntu/ (non pas fedora...). Ajoute à ça un partage massif des composants graphiques, et on obtiens au final, un gnu/linux qui peux être aussi rapide qu'un windows pour mr michu.

        Bref Mr Michu, il voit que son Windows "va plus vite à s'afficher", comme premier constat. Mais, tout Mr Michu qu'il est, il voit aussi à l'usage qu'il peux lancer beaucoup plus de programmes sur son Linux ...

        Donc pas troll je pense.
        • [^] # Re: Thread?

          Posté par  . Évalué à 1.

          Si! tu peux rajouter fedora vu que le chargeur est aussi disponible à installé, mais pas par défaut! perso il charge en moins de 5s!
        • [^] # Re: Thread?

          Posté par  . Évalué à 8.

          > L'impression de vélocité donné par Windows est une impression bien réelle et nullement sujete à troll. Pour l'expérience utilisateur, mr michu voit clairement que Windows "va plus vite". Point.

          Je ne suis pas d'accord avec toi, ce sont plutôt les 'experts Windows' qui peuvent avoir un Windows "rapide" (tout est relatif hein: bien moins que BeOS): un utilisateur normal a un anti-virus tournant en permanence sur son PC et celui-ci lui bouffe tellement de ressources qu'il ne va pas trouver forcément que Windows est rapide..

          • [^] # Re: Thread?

            Posté par  . Évalué à -3.

            c'est essentiellement dûe au fait que le GUI tourne en mode noyau, ça booste beaucoup de performance (niveau réactivité). Et puis X utilise encore massivement les sockets pour communiqué, ce qui ralenti d'autant plus.

            Mais bon, entre un windows qui peut pas rester installer 2 mois sans être submerger de bloatware et un linux qui passe d'une version à une autre tranquillement, c'est tout décider.
            • [^] # Re: Thread?

              Posté par  (Mastodon) . Évalué à 4.

              (windows) le GUI tourne en mode noyau
              C'est une blague ???????

              ps : je vais tester Haiku, juste pour voir, un truc sans Xorg, ça me titille les méninges ;-)
              • [^] # Re: Thread?

                Posté par  . Évalué à 2.

                franchement le déplacement des fenêtres est moins fluide qu'avec un compiz, par contre le toolkit donne une impression de légèreté quand même.

                Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

              • [^] # Re: Thread?

                Posté par  . Évalué à -1.

                oui GDI tourne en mode noyau. En tout cas celui de windows 2000/XP. Je ne sais pas si la couche graphique d'aero tourne dans l'espace utilisateur, ce qui serait logique.
        • [^] # Re: Thread?

          Posté par  . Évalué à 2.

          Euh je mettrai un bemol enfin pas moi mais ma femme qui est legerement enerve chaque fois qu'elle demarre son ordi pour faire un truc rapide et qu'il lui faut bien 5 minutes pour pouvoir faire reellement quelque chose avec son ordi.
      • [^] # Re: Thread?

        Posté par  . Évalué à 3.

        >J'avais vaguement compris que Windows utilise massivement les thread, me trompe-je ?

        "Massivement" pas forcément mais les processus étant lourd sur Windows c'est exact que les thread sont y plus utilisés oui.

        >En y repensant, est-ce que c'est pour ça que Windows est plus réactif qu'un gnome ou qu'un KDE sur ma machine?

        J'en doute: la réactivité de Windows est très, très inférieure à celle que BeOS avait (sur des machines beaucoup moins puissante)..

        Je pense que c'est plutôt qu'il y a peu de version de Windows avec beaucoup de part de marché donc plus d'optimisation contre beaucoup plus de baz^Wdiversité sur Linux.
      • [^] # Re: Thread?

        Posté par  . Évalué à 1.

        J'étais en train de penser comment j'allais présenter ma réponse le temps que la page de formulaire se charge.
        Mais quoi qu'il me vienne à l'esprit, je ne pense pas pouvoir l'écrire avant ce soir à minuit.
        Donc juste pour dire qu'on ne jette pas du pain dehors quand on ne veut pas nourrir les oiseaux...

        ----------------> [ ]
      • [^] # Re: Thread?

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

        Il faut aussi savoir ce que l'on compare :

        si il s'agit Windows XP, il faut prendre en compte le fait qu'il a déjà 8 ans, alors que la dernière version de Gnome a -au pire- 6 mois. ;)

        There is no spoon...

      • [^] # Re: Thread?

        Posté par  (site web personnel, Mastodon) . Évalué à 0.

        Tu es resté bloqué à MS Windows Me. Les MS Windows de la branche NT sont compatibles POSIX. Donc il y a bien fork.

        Les applications développées pour MS Windows étaient massivement multi-thread parce que c'est plus rapide, et parce que la création d'un nouveau processus était trop lent. Et puis, ça permettait de conserver les bonnes habitudes de programmations sous DOS avec ces joies et ces contrariétées ;)
        • [^] # Re: Thread?

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

          Tu es resté bloqué à MS Windows Me. Les MS Windows de la branche NT sont compatibles POSIX. Donc il y a bien fork.

          Tu me diras où tu as vu que l'API (j'ai ajouté API car tu l'avais omis) Windows était compatible POSIX ... Si tu veux du POSIX, il faut au minimum ajouter la couche Unix Services for Windows, ou le nom qu'ils donnent aujourd'hui, et il faut bien-sûr compiler le programme pour l'utiliser (jamais testé, donc je ne connais pas les spécificités).

          Dans tous les cas, le fork n'existe pas, il est au mieux simulé par la couche sus-mentionnée.
          • [^] # Re: Thread?

            Posté par  . Évalué à 2.

            Et d'ailleurs l'absence de fork sur windows me pose des soucis pour faire du code Perl portable, car le fork() Perl sous Windows est émulé par des threads, et que cela pose des problèmes avec certains modules.

            Rien de grave bien sûr, mais c'était ma petite couche.
          • [^] # Re: Thread?

            Posté par  . Évalué à 1.

            Oui il y a une pile POSIX sous Windows.
            Oui il y a un appel system fork.
            Non il n'est pas aussi rapide que sous linux car il appel derrière des appels systemes Win32 qui ne sont pas fait pour. C'est pour pour la compatibilité, pas pour faire fork toutes les 10s (perso, le fork, je déteste, je trouve ça antédéluvient et moche à souhait, rien ne vaut un bon QThread).
            • [^] # Re: Thread?

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

              Non tu peux vraiment me dire quel est l'appel système fork() sur Windows, ou même une pile POSIX, parce que moi je ne vois pas... mais attends :

              Non il n'est pas aussi rapide que sous linux car il appel derrière des appels systemes Win32

              Ha donc ce n'est pas natif, c'est émulé. Il ne faut pas confondre, car cela n'a rien a voir.

              Quant à fork(), je dois dire qu'ayant commencé la programmation avec l'API Win32, et étant passé sur une vraie API (POSIX), j'ai su m'y faire, et je trouve aujourd'hui que fork() est plus élégant, associé à la panoplie des signaux POSIX bien-sûr :-)

              Les threads (et donc QThread ou autre) sont également intéressants, mais AMHA pas à mettre partout ; un mix des deux peut s'avérer être la meilleure solution, quand fork() est réellement disponible, en natif, bien-sûr :-p
    • [^] # Re: Thread?

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

      "Je suppose que ce portage ne remet pas en cause le modèle de thread utilisé par Qt (un seul thread pour la partie GUI), mais ne risque-t-on pas de perdre la réactivité d'Haiku dans les applications Qt portées?"

      Si tu ne traite que le GUI sur un thread, tu aura toujours une IHM ultra réactive... Par contre, à charge au développeur de threader les autres traitements qui eux sont lourds...

      Pour avoir découvert récement et implémenté les thread sous Qt, je réfute le fait que "Ça a l'air un peu lourdingue à faire parce qu'il faut passer par des signaux/slots pour tout." un signal prends 10 seconde à créer et tu synchronises toutes tes tâches facilement...

      Je trouvais fork() facile, mais il n'y a rien à faire, Qt simplifie encore plus la programation...
      • [^] # Re: Thread?

        Posté par  . Évalué à 1.

        Je pense que c'est une question de defaut: par defaut dans BeOS tu as les traitements dans les thread 'moteurs' il me semble et en plus la machine cible au départ était bi-coeur --> utilisation importante des threads dans les appli fourni par l'OS lui meme, guide de programmation indiquant la manière correcte coder une application qui utilise des threads, etc.

        Par defaut dans les GUI sur Linux en regle generale, les traitement sont dans le thread du GUI et si tu es motivé alors tu peux utilisé des thread/process pour faire les traitement: résultat pas beaucoup d'utilisation des threads..
        D'autant plus que c'est quand même très récent que tout le monde a un bi-coeur dans le monde x86.

        Aller contre la fainéantise/recherche de simplicité des developpeurs n'est pas naturel: de la meme maniere qu'il a fallu attendre Chrome pour que les developpeurs de FF soient motivés pour avoir une architecture correcte (de mon point de vue), si Haiku a du succés (très peu probable: Syllable qui est assez semblable n'est quasiment pas utilisé) peut-être qu'un desktop sous Linux sera motivé pour faire les (gros) changement necessaire..
  • # Le premier lien me donne une 403

    Posté par  . Évalué à 2.

    Sinon, excellente nouvelle.
    • [^] # Re: Le premier lien me donne une 403

      Posté par  . Évalué à 1.

      Il est tombé en rade aujourd'hui il semblerait. Sinon sur le site il n'y avait pas d'annonce (c'est un peu officieux j'ai l'impression), le seul truc intéressant hier était l'accès au dépôt.

      Je n'ai pas regardé comme ils ont fait, mais c'est un projet en cours depuis déjà quelques mois.
  • # voila qui fait plaisir

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

    Je poste justement avec le navigateur suscite, jusque la ca tourne plutot bien.
    Ce qu' il faut a haiku pour le pas finir comme son ancetre c' est surtout des drivers ! Je cherche (disons je tatonne) a faire un chargeur des .ko de linux, je ne sais pas si ca aboutira mais je garde espoir.
    • [^] # Re: voila qui fait plaisir

      Posté par  . Évalué à 3.

      oui, j'ai remarqué au début que cela tournait bien, mais maintenant chez moi cela plante toute les 5 ou 10 minutes, alors cela ne m'inspire plus trop confiance. Néanmoins c'est un bel effort, qui augure bon pour l'avenir...

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: voila qui fait plaisir

      Posté par  . Évalué à 4.

      Ça marche bien, mais y'a encore des petits problèmes de stabi

Suivre le flux des commentaires

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