Ca me fait penser à une vieille idée que j'ai jamais eu le courage et le temps d'essayer: si on insérait une couche client/serveur réseau au niveau du toolkit ?
Dans l'état actuel des choses, voila ce qui se passe quand on deplace une barre de défilement d'une liste pop-up:
1. Le serveur X detecte un evenement souris et l'envoie au client.
2. Le client X interprète l'événement et demande au serveur X d'effacer de redessiner le contenu de la liste (ce qui demande de nombreuses commandes: il faut effacer redessiner les traits, le texte)
Avec un qt (ou gtk) possédant une couche réseau, tout se passe uniquement sur le "serveur qt (ou gtk)". Les seuls communications qui subisteraient seraient des appels de callbacks définis par l'utilisateur à éxécuter du côté client qt:
1. Le serveur Qt détecte un événement souris. Il regarde le callback associé à cette événement. Le callback est en fait un morce de code de Qt lui-même et peut être éxécuté localement.
2. Le serveur Qt éxécute le callback, qui consiste à redéssiner la liste.
[^] # Toolkit client/serveur
Posté par Johann Deneux . En réponse à la dépêche Xfree86 4.2.0. Évalué à 10.
Dans l'état actuel des choses, voila ce qui se passe quand on deplace une barre de défilement d'une liste pop-up:
1. Le serveur X detecte un evenement souris et l'envoie au client.
2. Le client X interprète l'événement et demande au serveur X d'effacer de redessiner le contenu de la liste (ce qui demande de nombreuses commandes: il faut effacer redessiner les traits, le texte)
Avec un qt (ou gtk) possédant une couche réseau, tout se passe uniquement sur le "serveur qt (ou gtk)". Les seuls communications qui subisteraient seraient des appels de callbacks définis par l'utilisateur à éxécuter du côté client qt:
1. Le serveur Qt détecte un événement souris. Il regarde le callback associé à cette événement. Le callback est en fait un morce de code de Qt lui-même et peut être éxécuté localement.
2. Le serveur Qt éxécute le callback, qui consiste à redéssiner la liste.