Ici on parle de refaire l'interface. Donc la capture des trames réseau, la logique, les moteurs pour filtrer les paquets et certainement beaucoup d'autres choses, tout ceci ne change pas.
L'idée est de remplacer l'interface actuellement en GTK par une interface en HTML5. J'imagine que si l'application est pas trop mal conçue, il y a déjà une séparation propre de l'interface par rapport aux autres modules. Et l'interface GTK a donc un système de communication pour aller récuperer les paquets, envoyer les commandes de capture, de filtrage, etc...
Il y a donc à modifier ce système de communication pour qu'au lieu de communiquer avec du GTK, il communique avec une IHM en HTML5. Si l'architecture actuelle est bien faite, il n'y a rien à faire dans les autres parties du code. Le module qui va capturer les trames en a rien à faire de savoir que la commande reçue vient d'un bouton GTK ou d'une requête HTTP...
Si tu veux, on peut considérer l'application actuelle délestée de l'interface GTK comme un serveur, et l'interface en HTML5 comme un client. Mais je trouve que le modèle client/serveur n'est pas très pertinant ici. Mais il existe techniquement (puisque la communication entre l'interface et le reste est faite avec HTTP/WebSockets).
Après l'application peut se contenter d'ouvrir dans le navigateur par défaut une URL vers localhost:portquelconque mais je trouve ça pas très userfriendly. Une application HTML5 peut aussi s'ouvrir dans une nouvelle fenêtre sans passer par un navigateur.
iOS le permet (même si Apple l'a massacré récemment), windows 8 aussi. Sinon rien n'empêche de faire une application Qt avec QtWebkit qui contient uniquement l'interface HTML5. C'est peut-être un peu ironique par rapport à mon premier commentaire, mais QtWebkit est trop pas mal est la boite à outils Qt reste excellente pour les développeurs C++ qui font pas de l'IHM.
[^] # Re: HTML5
Posté par dave_null . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à -2.
Ici on parle de refaire l'interface. Donc la capture des trames réseau, la logique, les moteurs pour filtrer les paquets et certainement beaucoup d'autres choses, tout ceci ne change pas.
L'idée est de remplacer l'interface actuellement en GTK par une interface en HTML5. J'imagine que si l'application est pas trop mal conçue, il y a déjà une séparation propre de l'interface par rapport aux autres modules. Et l'interface GTK a donc un système de communication pour aller récuperer les paquets, envoyer les commandes de capture, de filtrage, etc...
Il y a donc à modifier ce système de communication pour qu'au lieu de communiquer avec du GTK, il communique avec une IHM en HTML5. Si l'architecture actuelle est bien faite, il n'y a rien à faire dans les autres parties du code. Le module qui va capturer les trames en a rien à faire de savoir que la commande reçue vient d'un bouton GTK ou d'une requête HTTP...
Si tu veux, on peut considérer l'application actuelle délestée de l'interface GTK comme un serveur, et l'interface en HTML5 comme un client. Mais je trouve que le modèle client/serveur n'est pas très pertinant ici. Mais il existe techniquement (puisque la communication entre l'interface et le reste est faite avec HTTP/WebSockets).
Après l'application peut se contenter d'ouvrir dans le navigateur par défaut une URL vers localhost:portquelconque mais je trouve ça pas très userfriendly. Une application HTML5 peut aussi s'ouvrir dans une nouvelle fenêtre sans passer par un navigateur.
iOS le permet (même si Apple l'a massacré récemment), windows 8 aussi. Sinon rien n'empêche de faire une application Qt avec QtWebkit qui contient uniquement l'interface HTML5. C'est peut-être un peu ironique par rapport à mon premier commentaire, mais QtWebkit est trop pas mal est la boite à outils Qt reste excellente pour les développeurs C++ qui font pas de l'IHM.