En fait il y a une vraie solution:
Beos (oui le fameux) lorsqu'il creait une application graphique demarrait en fait deux threads:
- une de l'appli qui lancait le main
- une graphique
En gros tout l'affichage client etait gerer par la thread graphique et les 2 thread ne communiquent que par protocole de queues de messages.
Donc pour le parrallele avec kmail, quand tu clique sur un bouton et que la thread principale fait "d'enoooormes calculs" , la thread graphique envoie la notification du bouton presse a la thread principale (qui ne pouvant rien faire la, ne le traite pas de suite).
Si l'event de ce bouton est considere comme bloquant (le cas par defaullt mais on peut lui assigner un timeout), alors la thread graphique te marque le bouton comme enfonce mais continue a rafraichir l'affichage tout en ne t'empechant l'execution de toute "commande bloquante" (en clair pas mal de widgets grises,...)
Mais ce qui est genial c que par exemple si le widget multi-liste et text (si read-only) ne sont pas bloquants (je croit qu'ils ne le sont pas par defaut), tu peut continuer a lire tes mails tout en attendant que ta commande reponde (car c du simple affichage)
Cela est possible car c'est une thread graphique dans le contexte de l'application. Xfree ne pourrait pas vraiment le faire car il aurait besoins de bcp d'informations sur l'application (en clair ca ferait bcp trop de duplication de donnee). Ca serait plutot aux widgets Qt et Gtk de le faire mais il subissent les "stupides" limitations de XFree qui les empechent d'avoir un comportement similaire.
[^] # Re: DCE, Quartz et Fresco
Posté par Raphael Junqueira . En réponse à la dépêche DCE, Quartz et Fresco. Évalué à 1.
Beos (oui le fameux) lorsqu'il creait une application graphique demarrait en fait deux threads:
- une de l'appli qui lancait le main
- une graphique
En gros tout l'affichage client etait gerer par la thread graphique et les 2 thread ne communiquent que par protocole de queues de messages.
Donc pour le parrallele avec kmail, quand tu clique sur un bouton et que la thread principale fait "d'enoooormes calculs" , la thread graphique envoie la notification du bouton presse a la thread principale (qui ne pouvant rien faire la, ne le traite pas de suite).
Si l'event de ce bouton est considere comme bloquant (le cas par defaullt mais on peut lui assigner un timeout), alors la thread graphique te marque le bouton comme enfonce mais continue a rafraichir l'affichage tout en ne t'empechant l'execution de toute "commande bloquante" (en clair pas mal de widgets grises,...)
Mais ce qui est genial c que par exemple si le widget multi-liste et text (si read-only) ne sont pas bloquants (je croit qu'ils ne le sont pas par defaut), tu peut continuer a lire tes mails tout en attendant que ta commande reponde (car c du simple affichage)
Cela est possible car c'est une thread graphique dans le contexte de l'application. Xfree ne pourrait pas vraiment le faire car il aurait besoins de bcp d'informations sur l'application (en clair ca ferait bcp trop de duplication de donnee). Ca serait plutot aux widgets Qt et Gtk de le faire mais il subissent les "stupides" limitations de XFree qui les empechent d'avoir un comportement similaire.