dave_null a écrit 358 commentaires

Cf message au dessus. Je pensais que lo était cette fonctionnalité : http://wiki.wireshark.org/DisplayFilters (mal lu, la fatigue tout ça…)

J'avais mal compris. Je pensais que lo était la fonctionnalité de filtrage après capture.

En gros je pensais que c'était ça : http://wiki.wireshark.org/DisplayFilters (qui s'oppose à ça : http://wiki.wireshark.org/CaptureFilters)

Donc oui forcément c'est à cotés de la plaque.

Pour l'interface réseau «lo», effectivement ça peut compliquer un peu l'implémentation. On ne peut donc pas utiliser HTTP pour communiquer avec l'interface. Il reste cependant la possibilité d'utiliser un moteur web intégré à l'application. Là la communication entre l'interface est le cœur de l'application n'est pas nécessairement en HTTP.

Rapidement, je n'ai jamais testé. Ce serait comparable à XAML dans les grandes lignes.

Selon moi c'est pas mal, ça ressemble au web sur certains points, mais il n'y a pas tout l'écosystème du web qui vient avec.

Mais ils ne comptent pas le faire avec Qt Quick le nouveau Wireshark ?

Je ne pense pas que lo soit intégré à l'arrache au milieu du code GTK.

J'imagine qu'il est communiqué à GTK une liste d’éléments à afficher, éventuellement filtrés par lo.

Du coup qu'est-ce que ça change ?

À la base c'est un troll lié à un journal récent qui sur le web en tant que système d'exploitation. J'ai fait court car je savais l'écrivant que ma remarque allait se retrouver à -10.

Maintenant, si c'était à moi de développer cette interface, je le ferais en HTML5. Peut-être parce que j'aime bien mon marteau qui fait tout. En attendant je ne suis pas le seul à l'aimer et l'apprécier ce marteau. (un exemple parmi tant d'autres : http://msdn.microsoft.com/fr-FR/library/windows/apps/br211385.aspx)

Ici on parle d'une technologie pour créer des interfaces libre multi-plateforme et qui s'adapte à différents supports. Qt est supporté sur les plateformes qu'ils ciblent d'où leur choix. HTML5 aussi.

Réellement je ne vois pas où est le truc choquant. Ce n'est pas nouveau HTML5 pour créer des applications.

Je n'ai pas dev cette interface car je n'en ai pas besoin, pas envie et pas le temps. Et je n'ai jamais dit qu'ils sont incompétents, juste qu'à leur place j'aurais choisi HTML5.

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.

Excusez-moi, mais on parle bien d'IHM là ? Car sinon, on dirait «Wireshark passe de GObject à Qt» ou quelque chose de similaire.

Une IHM développée avec des technologies web peut très bien communiquer avec une logique métier bas niveau. Et pas besoin de sortir l'artillerie lourde avec NodeJS et compagnie.

Au lieu de Qt, j'aurais choisi HTML5. Qt c'est tout autant oldschool que GTK.

C'est une bonne nouvelle mais je suis un peu déçu qu'il n'y ait pas eu d'initiative pour trouver un format de dates. Actuellement il y a plusieurs solutions en concurrence et ce n'est pas pratique.

Tu peux charger des fichiers JavaScript d'autres domaines par défaut. le bookmarklet consiste à charger un fichier JavaScript.

Pour infos, l'introduction est une parodie du site du zéro et l'article a été écrit bien avant l'accident de Fukushima. La foire aux questions contient donc une erreur apprise plus tard : il ne faut pas arroser les restes qui s'enfoncent dans le sol, c'est très polluant.

C'est vraiment super, à quand une version minitel ?

J'ai souvent appris en m'amusant lors de mes études. Avec des cours bien plus funs que la plupart que l'on peut trouver sur le site du zéro. Ce n'est pas parce que l'on ajoute des smileys et que l'on a un style d'écriture plus familial que le cours devient amusant.

Ma belle mère m'avait demandé (avec insistance) de mettre en place un contrôle parental pour mon petit frère. J'avais mis en place un serveur proxy bien que peu convaincu de l'intérêt de la démarche.

Il a été supprimé suite à un faux positif sur voyagesncf au mauvais moment. Malgré l'absence de filtrage, je n'ai pas l'impression que mon petit frère ait une enfance perturbée par ses recherches google un peu naïves. D'ailleurs le filtrage de Google est bien suffisant pour un jeune débutant, pour les autres cela ne sert à rien, surtout si ils ont des copains.

Habitué au bépo, je ne suis pas vraiment à l'aise pour écrire de longs textes avec un clavier virtuel. Mais avec un peu d'habitude il est quand même possible d'écrire rapidement avec.

J'ai acheté un clavier bluetooth que j'utilise en Bépo et je ne regrette pas mon netbook. J'utilise VIM sur Android et ça fonctionne bien. Mais je ne me suis jamais amusé à compiler ou autre, pour l'instant je m'en sers surtout pour du texte.

Tu peux utiliser ARIA (cf https://developer.mozilla.org/en-US/docs/Accessibility/ARIA) et l'utilisation d'AngularJS ne pose à prioris pas de problèmes avec.

Il existe des implémentations de Socket.IO dans d'autres environnement que Node.js même si c'est un peu plus confidentiel. Mais rien ne t'empêche de développer la même chose avec d'autres technologies ou les websockets de HTML5.

Mais AngularJS est plus tourné vers le JSON et les apis REST. Là c'est des preuves de concept très intéressantes mais pas vraiment utilisées à grande échelle.

Ça m'embête ces histoires de DAC car je fais plus confiance au DAC d'un ampli réputé de qualité qu'à un DAC acheté quelques $ à un obscur vendeur asiatique sur ebay. Donc je cherche un moyen de garder un signal numérique jusqu'à l'ampli.

Sectarisme ?

Cotés client, c'est du MVC avec un bus à événements. La synchronisation s'effectue dans les deux sens (double data binding) entre les vues et les modèles.

Pour communiquer avec le serveur, des outils (ngResource) facilitent l'utilisation des APIs REST en JSON. Ça ne choquera pas grand monde qui fait du web.

Des prototypes tournent avec Socket.io. Ça permet de réaliser une synchronisation temps réel entre les vues, les modèles cotés client et le serveur.

Oui l'objectif n'était pas de lister du code source, car pour cela le site officiel s'en occupe très bien et il y a des centaines d'articles de ce type sur le web.

La dépêche est plus adressée aux décideurs qu'aux développeurs.

Pour les méthodologies adaptées au monde de l'industrie, tu as le test driven development, le modèle orienté composants et l'architecture pas faite sur le tas.

3 - Je confirme que la sortie audio en jack 3.5 est mauvaise. Il n'y a que du 11 bits de précision par défaut et le volume est faible. Je n'ose même pas imaginer à quoi ressemble le signal analogique en sortie.

Pour plus d'infos sur cette sortie audio ce topic (en anglais) peut apporter des informations : http://www.raspberrypi.org/phpBB3/viewtopic.php?t=14199

Par contre je n'ai pas testé la sortie son en HDMI, je sais qu'elle fonctionne bien. Mais par malchance je n'ai pas de HDMI sur l'amplificateur audio, et les convertisseurs HDMI/optique/coaxiale coutent généralement bien plus que le rasberry pi.

Si quelqu'un connait un moyen simple, efficace et moins cher qu'un rasberry pi pour sortir du son numériquement sans passer par l'HDMI, je suis très très intéressé.

Ce que je voulais dire c'est que tu peux brancher ton PC sur du bon matériel Hi-Fi