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
- portage de Qt sous Haiku (10 clics)
- Haiku (6 clics)
- L'annonce qui a inspiré cette dépêche avec une archive à la clé! (5 clics)
- Le premier portage de Qt sous BeOS (7 clics)
- Le fameux BeBook (7 clics)
- Le Haiku Book, décrivant les spécificité de l'API native d'Haiku (7 clics)
# Thread?
Posté par Gilles G. . Évalué à 4.
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 madhatter (site web personnel) . Évalué à 3.
There is no spoon...
[^] # Re: Thread?
Posté par Gilles G. . Évalué à 2.
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 nomorsad . Évalué à 3.
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 bubar🦥 (Mastodon) . Évalué à 2.
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 VINDICATORs . Évalué à 1.
[^] # Re: Thread?
Posté par reno . Évalué à 8.
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 Stibb . Évalué à -3.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 B16F4RV4RD1N . Évalué à 2.
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 Stibb . Évalué à -1.
[^] # Re: Thread?
Posté par Albert_ . Évalué à 2.
[^] # Re: Thread?
Posté par reno . Évalué à 3.
"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 Maclag . Évalué à 1.
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 madhatter (site web personnel) . Évalué à 1.
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 LupusMic (site web personnel, Mastodon) . Évalué à 0.
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 riri le breton (site web personnel) . Évalué à 1.
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 nomorsad . Évalué à 2.
Rien de grave bien sûr, mais c'était ma petite couche.
[^] # Re: Thread?
Posté par Stibb . Évalué à 1.
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 riri le breton (site web personnel) . Évalué à 1.
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 Etienne RABY (site web personnel) . Évalué à 4.
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 reno . Évalué à 1.
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 Phil Actaire . Évalué à 2.
[^] # Re: Le premier lien me donne une 403
Posté par sanao . Évalué à 1.
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 vincent LECOQ (site web personnel) . Évalué à 2.
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 B16F4RV4RD1N . Évalué à 3.
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 Anonyme . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.