GtkFileChooser a la même apparence partout pour avoir une unité parfaite d'esthétique et de fonctionnalités sur toutes les plate-formes.
Implémenter des boîtes de dialogue natives serait possible, pas dans GTK+ directement mais via un module qui pourrait être optionnellement installé (tout comme GTKGLArea, qui implémente une vue OpenGL avec un code différent pour chaque OS). C'est juste que personne ne l'a encore codé.
A titre perso, je pourrais éventuellement le faire, juste que mon planning est ultra-chargé en ce moment. Comme d'hab…
GTK+, c'est un message "Firefox can't establish a connection to the server at www.tarnyko.net."? ;-)
Corrigé ;-).
le truc le plus énorme dans une appli GTK+, c'est la boite d'ouverture de fichiers imonde ailleurs que sous GNOME
Bien que ça ne m'ait jamais dérangé, la critique revient souvent. Techniquement, il est tout à fait possible d'appeler une boîte de dialogue native ; je ne pense même pas que ce soit compliqué (il y aura juste certaines fonctions indisponibles). Je vais poser la question pour savoir pourquoi on ne le fait pas.
Juste un mot sur "le support pourri des autres plate-formes que Linux".
Comme le rappelle Pierre Maziere (1er commentaire), GTK+ est surtout poussé par une communauté ; et c'est spécialement vrai pour les ports Win32 et OSX, qui n'intéressent pas forcément les sponsors officiels de GTK+/GNOME. Logique.
Or, beaucoup de gens sont intéressés (lire : se plaignent) de ces ports, mais assez peu contribuent. Moi-même, qui contribue pour Win32, ai déjà proposé de "coacher" un contributeur OS X sans succès. Il faut bien réaliser ça, et essayer de réagir constructivement.
En passant, les captures de Dirk sont un peu orientées : un logiciel GTK+ sous Win32 aujourd'hui, ça ressemble plutôt à ça. A sa décharge, il utilise encore GTK+2, qui est passé en mode "maintenance" et est moins avancé que GTK+3 de ce côté. Il aurait pu nettement améliorer la situation, mais a préféré migrer suite aux obstacles qu'il cite.
A titre personnel, je trouve que GTK+ est assez bien construit considérant son langage de référence et son extensibilité.
Le retour des développeurs, la documentation… c'est autre chose.
Désolé pour la réponse tardive, mais je n'ai pas vu ton commentaire jusqu'à maintenant (peut-être peut-on se faire prévenir par mail ?).
j'ai voulu cross-compiler gtk+ master à l'instant, et ça foire
master subit fréquemment des modifs de développeurs purs Unix/Linux qui n'envisagent pas le cas "Windows". Je passe donc derrière pour réparer (par exemple ça). Tu peux réessayer maintenant, il est tout à fait probable que ça fonctionne.
Quand je regarde les Makefile.am, je constate que c'est normal
Non, j'ai rarement dû toucher aux Makefile.am, les versions du moment sont propres.
tu compiles avec les autotools ou avec un autre système de build
autotools/mingw, avec des scripts perso. Tu peux trouver des anciennes versions du buildenv ici. J'ai malheureusement pas encore eu le temps d'y mettre celui de la "prod".
tu compiles sous Windows, ou tu cross-compiles?
Je cross-compile. Idéalement je ferais sous win, c'est 1000x plus facile et aussi performant, mais les binaires fournis doivent provenir d'une machine GNOME pour être certifiés = Linux.
je vois des makefile.msc
Les scripts MSVC sont fournis par d'autres contributeurs. Je ne les utilise pas, à la fois pour éviter les problèmatiques de version de CRT, et parce que je maîtrise moins bien ce compilateur.
À noter pour les afficionados d'OpenGL 1.X/2.X qu'il n'est pas explicitement dit que cela supporté (même si on parle à un moment de "compatibility profiles"). Je suppose que ça dépendra de la lib du vendeur.
Clutter ne peut pas vraiment être considéré comme GTK+ (malgré la présence du binding clutter-gtk).
J'en distribue cependant des binaires (non-officiels) ; c'est concu pour être aspiré par ValaWinPKG, mais on peut aussi télécharger l'archive directement.
Ca marche plutôt bien.
Dans le temps, il y avait un moteur (engine) GDK nommé GTK-Wimp qui servait de "glue" entre GTK+ et les widgets natifs de Windows.
Il n'a pas été porté sous GTK+3, mais je suppose que c'est loin d'être infaisable.
Une solution plus rapide serait d'écrire un simple accesseur capable de "lire" les icônes dans les binaires systèmes (comme shell32.dll) pour les réafficher via Gdk-Pixbuf ou Cairo.
on a toujours le droit au même immonde thème d'icônes
Les thèmes d'icônes sont personnalisables sous win32 aussi, il y a un "settings.ini" comme sous Linux, et même les formats vectoriels (SVG) sont gérés…
Après, inclure plein de thèmes, ça fait vite un bundle de 200 Mo. Alors que la demande était au contraire "plus petit possible" !
Maintenant il suffirait d'une bonne âme pour nous écrire une petite appli GTK+3-Windows récupèrant les thèmes sur les dépôts du Net, et les activant/désactivant dans ce fameux fichier ;-).
pourquoi avoir attendu autant de temps avant de mettre à disposition des binaires officiels de GTK+3
Question de support. Il faut qu'une ou plusieurs personnes se dévouent pour servir de "point d'entrée" aux questions, faire des revues de patches, discuter avec les développeurs…
la présence de ces binaires officiels changent quelques chose ?
Meilleurs rapports de bugs (puisque les gens seront incités à utiliser tous les mêmes binaires, pas une version compilée dans un coin avec des options et patches inconnus), reconnaissance de la qualité du port, garantie de confiance pour les développeurs tiers…
L'archive de Tuma ? Oui, elle marche pas trop mal ; je ne l'ai pas mentionnée car elle utilise des versions très anciennes, et craignais qu'on me le reproche.
Il faudrait en refaire une version à jour à partir des sources, avec des patchs documentés.
Effectivement ; d'autant qu'il intègre GLU (ce que jwzgl ne fait pas) et peut remplacer libGL.so à l'exécution, sans besoin de recompiler.
Il a par contre comme jwzgl parfois tendance à se tromper dans les profondeurs.
PS : L'idéal serait quand même d'avoir une vraie implémentation de référence. J'ai trouvé ça en rapport au commentaire de Léo, mais ça ne fournit pas EGL et ne me paraît pas encore prêt d'arriver, si ?
Le plus serait de suivre les pas de Qt ( port officiel OSX
Le port OSX est plus ou moins dans le même état que le Windows il y a peu : fonctionnel, mais a besoin de quelqu'un qui le suive de près.
Dans le même ordre d'idée, je contribue actuellement à GtkGLArea, qui supporte Linux, Windows, mais pas OSX… et la demande revient fréquemement.
Et j'ai aussi créé un dépôt pour Vala sous OSX, qui fonctionne, mais que je laisse "dormant" tant que je n'ai pas de réponse à mon appel à contribution.
Bref, un connaisseur OSX, ou simplement un passionné avec un peu de temps libre, est plus que bienvenu. Le cas échéant, je coache ;-).
Android, iOS
+1000. J'ai déjà creusé le sujet, et c'est pas irréalisable sous Android, mais là il faudrait définitivement un sponsor.
J'espère que cette initiative rassurera les développeurs et qu'ils décideront de continuer à développer avec GTK.
la problématique GLX/EGL est (théoriquement) orthogonale à la problématique GL/GLES
Tu as tout à fait raison.
Je pensais d'ailleurs initialement faire une dépêche consacrée uniquement à l'aspect GLX (on prend une appli GLES/GLX sous X11 pour la porter en GLES/EGL sous Wayland).
Le problème est que les cas d'application ne sont pas légion. L'immense majorité des applis GL sous X sont encore en vieux GL 1.X ; j'ai préféré mélanger avec la très courante problématique GL pour faire concret (et je pense que si EGLX est utilisé ailleurs, il le sera comme ça, de concert avec jwzGLES ou un autre wrapper).
ça va être corrigé par une nouvelle ABI proposée par NVidia
Alors là, je suis très intéressé. Je vais chercher, mais au cas où, aurais-tu un lien ?
Ben voila : il ya des OS de troisièmes zone, et ben les utilisateurs de ces OS disent aux dev' que c'est lourd. Et comme ils sont nombreux…
Qt considère Linux, Windows et Mac comme importants: Qt Reference Configurations
Juste pour information, le port Windows dispose d'une distribution officielle depuis ce vendredi.
C'est surtout la reconnaissance de l'existant (le port marche bien), mais ce n'est pas anodin pour autant, dans le sens où de nombreux projets l'attendaient.
La mise à jour du bundle PyGTK dont tu parles était une proposition GSoC, mais malheureusement personne ne s'est proposé :-(.
Je maintiens le bundle Windows qu'annonce le journal ; je sais également générér des installeurs avec NSIS. Ma seule lacune ici est mon manque de connaissance de Python (sa façon de gérer les bibliothéques, bindings, etc..). Si tu es intéressé pour contribuer et faire avancer la chose, n'hésite pas à venir vers moi.
TurnKey Linux propose cette fonctionvia une GUI. C'est cependant plus qu'une solution NAS, et peut-être un peu "too much" pour tes besoins. Tu devrais essayer.
Je ne connais aucun NAS prêt-à-l'emploi qui le propose pour l'instant ; c'est cependant une feature request pour NAS4Free. Tu pourrais contribuer en créant l'interface, ou carrément suivre l'idée du post avec la migration vers Samba 4 -plus de travail, mais ouvre un maximum de possibilités.
Juste une question : comment peut-on avoir une liste complète des projets déposés ? La page d'accueil ne montre que les derniers, et pas de lien évident pour ceci.
Je le sais bien alagoutte, mais je n'ai pas voix au chapitre là-dessus. Il faut se contenter des binaires que l'on fournit pour l'instant (moi et quelques autres).
La dernière version résout plusieurs bugs, dont un avec le dual screen. Mon build system est en train de la compiler ; je vais fournir le lien à B.l.nt et, si problèmes il y a encore, regarder ce qu'on peut faire dans le code.
Le port Windows fonctionne très bien, je bosse dessus en ce moment ; s'il y a des problèmes que je ne connais pas, il faut me les remonter (directement ou viaBugzilla).
Il est possible que l'absence de version à télécharger sur le site officiel soit ce qui dérange les devs. Si c'est le cas, je ne peux pas -encore- faire grand-chose à ce niveau-là
Ah OK, c'est bien ce que je pensais. Oui c'est vrai que le choix de GTK+ de fournir ses propres sélecteurs (fichiers, polices, couleurs…) plutôt que d'utiliser ceux du système ne fait pas l'unanimité. Encore qu'un peu de hacking suffirait à implémenter ça, la branche Mac est la plus ouverte en ce moment.
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
OK, donc voilà ce que ça donne :
GtkFileChooser a la même apparence partout pour avoir une unité parfaite d'esthétique et de fonctionnalités sur toutes les plate-formes.
Implémenter des boîtes de dialogue natives serait possible, pas dans GTK+ directement mais via un module qui pourrait être optionnellement installé (tout comme GTKGLArea, qui implémente une vue OpenGL avec un code différent pour chaque OS). C'est juste que personne ne l'a encore codé.
A titre perso, je pourrais éventuellement le faire, juste que mon planning est ultra-chargé en ce moment. Comme d'hab…
[^] # Re: Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
Corrigé ;-).
Bien que ça ne m'ait jamais dérangé, la critique revient souvent. Techniquement, il est tout à fait possible d'appeler une boîte de dialogue native ; je ne pense même pas que ce soit compliqué (il y aura juste certaines fonctions indisponibles). Je vais poser la question pour savoir pourquoi on ne le fait pas.
# Autres plate-formes
Posté par Tarnyko (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 10.
Juste un mot sur "le support pourri des autres plate-formes que Linux".
Comme le rappelle Pierre Maziere (1er commentaire), GTK+ est surtout poussé par une communauté ; et c'est spécialement vrai pour les ports Win32 et OSX, qui n'intéressent pas forcément les sponsors officiels de GTK+/GNOME. Logique.
Or, beaucoup de gens sont intéressés (lire : se plaignent) de ces ports, mais assez peu contribuent. Moi-même, qui contribue pour Win32, ai déjà proposé de "coacher" un contributeur OS X sans succès. Il faut bien réaliser ça, et essayer de réagir constructivement.
En passant, les captures de Dirk sont un peu orientées : un logiciel GTK+ sous Win32 aujourd'hui, ça ressemble plutôt à ça. A sa décharge, il utilise encore GTK+2, qui est passé en mode "maintenance" et est moins avancé que GTK+3 de ce côté. Il aurait pu nettement améliorer la situation, mais a préféré migrer suite aux obstacles qu'il cite.
A titre personnel, je trouve que GTK+ est assez bien construit considérant son langage de référence et son extensibilité.
Le retour des développeurs, la documentation… c'est autre chose.
[^] # Re: Hélas toujours pas...
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Enlightenment 0.18 EFL 1.8.3 & Elementary . Évalué à 2.
Si, les EFL fonctionnent sous win32, il existe d'ailleurs un process de build officiel (les fonctions sont wrappées via la sous-bibliothèque "Evil").
Pour OSX, aucune idée.
[^] # Re: Tu compiles depuis Win ou en natif?
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 1.
Je t'en prie !
OK. Fais juste attention, depuis peu, mingw32 n'est plus utilisable -et mon buildenv non plus, donc (mingw64 requis).
[^] # Re: Tu compiles depuis Win ou en natif?
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 1.
Salut Jehan,
Désolé pour la réponse tardive, mais je n'ai pas vu ton commentaire jusqu'à maintenant (peut-être peut-on se faire prévenir par mail ?).
master subit fréquemment des modifs de développeurs purs Unix/Linux qui n'envisagent pas le cas "Windows". Je passe donc derrière pour réparer (par exemple ça). Tu peux réessayer maintenant, il est tout à fait probable que ça fonctionne.
Non, j'ai rarement dû toucher aux Makefile.am, les versions du moment sont propres.
autotools/mingw, avec des scripts perso. Tu peux trouver des anciennes versions du buildenv ici. J'ai malheureusement pas encore eu le temps d'y mettre celui de la "prod".
Je cross-compile. Idéalement je ferais sous win, c'est 1000x plus facile et aussi performant, mais les binaires fournis doivent provenir d'une machine GNOME pour être certifiés = Linux.
Les scripts MSVC sont fournis par d'autres contributeurs. Je ne les utilise pas, à la fois pour éviter les problèmatiques de version de CRT, et parce que je maîtrise moins bien ce compilateur.
[^] # Re: Ne pas confondre !
Posté par Tarnyko (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 1.
Très intéressant, merci !
À noter pour les afficionados d'OpenGL 1.X/2.X qu'il n'est pas explicitement dit que cela supporté (même si on parle à un moment de "compatibility profiles"). Je suppose que ça dépendra de la lib du vendeur.
[^] # Re: Et Clutter ?
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 1.
Clutter ne peut pas vraiment être considéré comme GTK+ (malgré la présence du binding clutter-gtk).
J'en distribue cependant des binaires (non-officiels) ; c'est concu pour être aspiré par ValaWinPKG, mais on peut aussi télécharger l'archive directement.
Ca marche plutôt bien.
[^] # Re: Non mais sérieusement
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 3.
Dans le temps, il y avait un moteur (engine) GDK nommé GTK-Wimp qui servait de "glue" entre GTK+ et les widgets natifs de Windows.
Il n'a pas été porté sous GTK+3, mais je suppose que c'est loin d'être infaisable.
Une solution plus rapide serait d'écrire un simple accesseur capable de "lire" les icônes dans les binaires systèmes (comme shell32.dll) pour les réafficher via Gdk-Pixbuf ou Cairo.
Plein d'idées, plein de projets !
[^] # Re: Non mais sérieusement
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 6.
Les thèmes d'icônes sont personnalisables sous win32 aussi, il y a un "settings.ini" comme sous Linux, et même les formats vectoriels (SVG) sont gérés…
Après, inclure plein de thèmes, ça fait vite un bundle de 200 Mo. Alors que la demande était au contraire "plus petit possible" !
Maintenant il suffirait d'une bonne âme pour nous écrire une petite appli GTK+3-Windows récupèrant les thèmes sur les dépôts du Net, et les activant/désactivant dans ce fameux fichier ;-).
[^] # Re: Questions de débutant + Erreurs
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 2.
De rieeeeen !
[^] # Re: Questions de débutant + Erreurs
Posté par Tarnyko (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 9.
Question de support. Il faut qu'une ou plusieurs personnes se dévouent pour servir de "point d'entrée" aux questions, faire des revues de patches, discuter avec les développeurs…
Meilleurs rapports de bugs (puisque les gens seront incités à utiliser tous les mêmes binaires, pas une version compilée dans un coin avec des options et patches inconnus), reconnaissance de la qualité du port, garantie de confiance pour les développeurs tiers…
[^] # Re: Binding Python !!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 2.
L'archive de Tuma ? Oui, elle marche pas trop mal ; je ne l'ai pas mentionnée car elle utilise des versions très anciennes, et craignais qu'on me le reproche.
Il faudrait en refaire une version à jour à partir des sources, avec des patchs documentés.
[^] # Re: Enfin !!!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 2.
Oui, le GTK+ de MacPorts et HomeBrew utilise X11, à moins de spécifier le contraire ; par exemple avec MacPorts :
port install gtk3 +quartz -x11 +nox11_
Je fournis un bundle OSX (non-officiel) avec Quartz pour ceux qui veulent tester, mais l'installeur OSX-Vala avec création automatique des raccourcis et variables d'env. est sans doute le plus rapide.
[^] # Re: glshim
Posté par Tarnyko (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 1.
Effectivement ; d'autant qu'il intègre GLU (ce que jwzgl ne fait pas) et peut remplacer libGL.so à l'exécution, sans besoin de recompiler.
Il a par contre comme jwzgl parfois tendance à se tromper dans les profondeurs.
PS : L'idéal serait quand même d'avoir une vraie implémentation de référence. J'ai trouvé ça en rapport au commentaire de Léo, mais ça ne fournit pas EGL et ne me paraît pas encore prêt d'arriver, si ?
[^] # Re: Enfin !!!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 8.
Le port OSX est plus ou moins dans le même état que le Windows il y a peu : fonctionnel, mais a besoin de quelqu'un qui le suive de près.
Dans le même ordre d'idée, je contribue actuellement à GtkGLArea, qui supporte Linux, Windows, mais pas OSX… et la demande revient fréquemement.
Et j'ai aussi créé un dépôt pour Vala sous OSX, qui fonctionne, mais que je laisse "dormant" tant que je n'ai pas de réponse à mon appel à contribution.
Bref, un connaisseur OSX, ou simplement un passionné avec un peu de temps libre, est plus que bienvenu. Le cas échéant, je coache ;-).
+1000. J'ai déjà creusé le sujet, et c'est pas irréalisable sous Android, mais là il faudrait définitivement un sponsor.
Moi aussi. Merci pour tes encouragements.
[^] # Re: Ne pas confondre !
Posté par Tarnyko (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 4.
Tu as tout à fait raison.
Je pensais d'ailleurs initialement faire une dépêche consacrée uniquement à l'aspect GLX (on prend une appli GLES/GLX sous X11 pour la porter en GLES/EGL sous Wayland).
Le problème est que les cas d'application ne sont pas légion. L'immense majorité des applis GL sous X sont encore en vieux GL 1.X ; j'ai préféré mélanger avec la très courante problématique GL pour faire concret (et je pense que si EGLX est utilisé ailleurs, il le sera comme ça, de concert avec jwzGLES ou un autre wrapper).
Alors là, je suis très intéressé. Je vais chercher, mais au cas où, aurais-tu un lien ?
[^] # Re: Pas les premiers à changer et pas les derniers
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Wireshark passe à Qt. Évalué à 4.
Juste pour information, le port Windows dispose d'une distribution officielle depuis ce vendredi.
C'est surtout la reconnaissance de l'existant (le port marche bien), mais ce n'est pas anodin pour autant, dans le sens où de nombreux projets l'attendaient.
[^] # Re: Binding Python !!
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 10.
Salut stopspam,
La mise à jour du bundle PyGTK dont tu parles était une proposition GSoC, mais malheureusement personne ne s'est proposé :-(.
Je maintiens le bundle Windows qu'annonce le journal ; je sais également générér des installeurs avec NSIS. Ma seule lacune ici est mon manque de connaissance de Python (sa façon de gérer les bibliothéques, bindings, etc..). Si tu es intéressé pour contribuer et faire avancer la chose, n'hésite pas à venir vers moi.
# TurnKey ou contrib ?
Posté par Tarnyko (site web personnel) . En réponse au message Remplacement SME server avec contrôleur de domaine . Évalué à 2.
TurnKey Linux propose cette fonction via une GUI. C'est cependant plus qu'une solution NAS, et peut-être un peu "too much" pour tes besoins. Tu devrais essayer.
Je ne connais aucun NAS prêt-à-l'emploi qui le propose pour l'instant ; c'est cependant une feature request pour NAS4Free. Tu pourrais contribuer en créant l'interface, ou carrément suivre l'idée du post avec la migration vers Samba 4 -plus de travail, mais ouvre un maximum de possibilités.
Bonne chance.
[^] # Re: HS pardon d'avance
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Attention au dépôt debian-multimedia.org !. Évalué à 3.
Il n'existe pas (encore) de section "testing-updates".
Si tu es aventureux, tu pourrais utiliser "testing-proposed-updates" :
testing étant déjà activé par ailleurs, je pense qu'il est inutile de te recommander la prudence…
# Liste des projets
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Open Funding cherche des testeurs beta. Évalué à 2.
Très bonne initiative.
Juste une question : comment peut-on avoir une liste complète des projets déposés ? La page d'accueil ne montre que les derniers, et pas de lien évident pour ceci.
[^] # Re: Interface graphique.
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Wireshark 1.10. Évalué à 3.
Je le sais bien alagoutte, mais je n'ai pas voix au chapitre là-dessus. Il faut se contenter des binaires que l'on fournit pour l'instant (moi et quelques autres).
La dernière version résout plusieurs bugs, dont un avec le dual screen. Mon build system est en train de la compiler ; je vais fournir le lien à B.l.nt et, si problèmes il y a encore, regarder ce qu'on peut faire dans le code.
[^] # Re: Interface graphique.
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Wireshark 1.10. Évalué à 6.
Le port Windows fonctionne très bien, je bosse dessus en ce moment ; s'il y a des problèmes que je ne connais pas, il faut me les remonter (directement ou via Bugzilla).
Il est possible que l'absence de version à télécharger sur le site officiel soit ce qui dérange les devs. Si c'est le cas, je ne peux pas -encore- faire grand-chose à ce niveau-là
[^] # Re: Interface graphique.
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Wireshark 1.10. Évalué à 1.
Ah OK, c'est bien ce que je pensais. Oui c'est vrai que le choix de GTK+ de fournir ses propres sélecteurs (fichiers, polices, couleurs…) plutôt que d'utiliser ceux du système ne fait pas l'unanimité. Encore qu'un peu de hacking suffirait à implémenter ça, la branche Mac est la plus ouverte en ce moment.