Ce journal a été promu en dépêche : Wireshark passe à Qt.
Wireshark, le célèbre logiciel d'inspection du réseau, va progressivement passer d'une interface en GTK vers une interface en Qt. La raison invoquée est que de plus en plus d'utilisateurs sont sur autre chose que Linux et que certains voudraient bien l'avoir sur leur tablette (iPad ou basée sur Android) mais également que GTK sur autre chose que Linux c'est un peu pourri tout de même sur OSX ou Windows. Dans les commentaires du blog, il y a même une intervention de Miguel de Icaza pour défendre son bébé mais ça n'a pas l'air de prendre.
Après Subsurface, LXDE et WireShark qu'elle sera la prochaine appli à délaisser GTK au profit de Qt ?
# HTML5
Posté par dave_null (site web personnel) . Évalué à -9.
Au lieu de Qt, j'aurais choisi HTML5. Qt c'est tout autant oldschool que GTK.
[^] # Re: HTML5
Posté par Guillaume Denry (site web personnel) . Évalué à 8. Dernière modification le 22 octobre 2013 à 10:20.
T'as raison, une application web pour faire de la capture de paquets réseaux protocolaires bas niveau, c'est vraiment l'idéal ! Je te propose de commencer à pousser un truc sur github, on regardera.
EDIT: bon, en toute rigueur, on pourrait bricoler un truc à base de nodejs interfacé avec des libpcap et des machins comme ça, mais je doute de l'intérêt de devoir se connecter à un serveur en localhost pour ça.
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à 0.
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.
[^] # Re: HTML5
Posté par Guillaume Denry (site web personnel) . Évalué à 4. Dernière modification le 22 octobre 2013 à 10:53.
Ah bon ? Tu imagines l'appli comment concrètement ? Ça m'intéresse.
Parce que pour capturer des trames bas niveau dans une appli web, j'ai du mal à voir comment faire autrement que de déporter ça côté serveur.
[^] # Re: HTML5
Posté par dave_null (site web personnel) . É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.
[^] # Re: HTML5
Posté par Guillaume Denry (site web personnel) . Évalué à 6. Dernière modification le 22 octobre 2013 à 11:43.
En gros tu proposes de faire une appli native qui instancierait un renderer html5 quoi, en supposant que c'est plus stimulant d'écrire une IHM html5 que GTK/Qt pour cette appli.
Je sais que cette possibilité existe (via QtWebkit principalement), mais je ne suis pas d'accord, je pratique régulièrement les deux (IHM web et Qt) et je préfère amplement écrire des IHM en Qt, les outils sont plus puissants, plus intégrés. L'IHM web a l'immense avantage de pouvoir être exécutée via un navigateur et, idéalement d'un peu partout. Si tu retires ces deux avantages, je ne vois pas trop ce qui me motiverait à écrire une IHM HTML5 pour une appli native, alors qu'il existe des frameworks 100x plus puissants à côté. (sans parler de QML qui permet de donner un look plus moderne et "convergent" multi-plateforme)
Surtout pour écrire une application dont la philosophie d'utilisation ne rentre pas vraiment le moule de l'appli client/serveur classique, mais est un système d'analyse réseau bas niveau.
Mais chacun son trip. Néanmoins, bon courage pour trouver des gens motivés pour t'accompagner dans cette démarche.
[^] # Re: HTML5
Posté par Astaoth . Évalué à 6. Dernière modification le 22 octobre 2013 à 14:34.
Je pense quand même que le commentaire initial était à but humoristique, et que la suite n'est qu'une explication de la blague … mais évidemment, ca devient moins drôle et plus sérieux, alors que ce n'était pas le but de base.
Emacs le fait depuis 30 ans.
[^] # Re: HTML5
Posté par Octabrain . Évalué à -2.
"Au lieu de Qt, j'aurais choisi HTML5."
Mais t'as carrément raison, le web c'est tellement bien, d'ailleurs pourquoi tu la dev pas toi même cette interface puisque ce sont des incompétents ?
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à -5.
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.
[^] # Re: HTML5
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Moi j'aurais choisi Turbo Pascal !
Ah bin mince, pourquoi je suis tout moinssé ?! Ah, c'est sans doute parce que je n'ai fourni aucun argument pour mettre dans la balance Turbo Pascal VS les autres technos et que mon avis ne fera pas du tout avancer le shmilblick !
[^] # Re: HTML5
Posté par guppy . Évalué à 3.
Visiblement c'est pas le modernisme ou non de GTK qui gène, mais son implémentation sous certains OS.
[^] # Re: HTML5
Posté par xcomcmdr . Évalué à 10.
" If all you have is a hammer, everything looks like a nail."
-_-'
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à -3.
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.
[^] # Re: HTML5
Posté par Le Gab . Évalué à 5.
De rajouter la lourdeur d'un firefox ou chrome…
[^] # Re: HTML5
Posté par Batchyx . Évalué à 10.
Sauf qu'on parle d'une application de capture réseau là. Le genre d'application qui, dans sa configuration par défaut, va capturer tout tes paquets réseaux en temps réel. Y compris les sessions TCP qui transportent du HTTP et qui contiennent du HTML5, comme … Ton application de capture réseau en HTML5.
Pour ceux qui n'ont jamais fait au moins une fois l'erreur d'utiliser
tcpdumpen direct dans une session SSH, ça donne ça:tcpdumpcapture un paquet et l'affiche sur sa sortie standard, qui est rebalancée en SSH.tcpdumpvoit les paquet de la session SSH dans les deux sens, et les affiche sur sa sortie standard … qui est aussi rebalancée en SSH. En bref ta sortie se fait rapidement floodée par des paquets TCP/SSH et si t'est assez intelligent, tu te rend compte que c'est de ta faute.Certes, en local, sharkTML5 pourra capturer les paquets réseaux qui ne passent pas par
lo, mais la fonctionnalité de capture de paquets passant parloest utile pour les développeurs réseaux qui testent leur alpha foireuse en local.En gros, t'est juste en train de réduire les fonctionnalités de ton logiciel rien que pour une fonctionnalité à la mode dont les utilisateurs se foutent.
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à -10.
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 ?
[^] # Re: HTML5
Posté par Batchyx . Évalué à 5.
Ce que tu dit n'a strictement aucun sens.
loest une interface réseau. Une interface réseau ne peut pas être intégrée à du code, et ne peut pas filtrer des listes d'éléments à afficher.[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à 0.
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.
[^] # Re: HTML5
Posté par Guillaume Denry (site web personnel) . Évalué à 8. Dernière modification le 22 octobre 2013 à 22:43.
Du coup, tu dois intégrer les couches basses de données du réseau au coeur de ton appli web (en faisant probablement un binding natif javascript), ce qui coupe toute possibilité d'accéder à l'appli web par réseau. En gros tu as au final une appli avec un frontend HTML5, mais qu'on ne peut pas exécuter avec un navigateur ou à distance.
C'est balot.
Tu es sûr que tu veux le faire avec HTML5 ton wireshark ? :)
[^] # Re: HTML5
Posté par Maclag . Évalué à 9.
C'est bon, ça va, on a compris.
Il le fera en PHP…
----------------------> [ ]
[^] # Re: HTML5
Posté par reynum (site web personnel) . Évalué à 1.
Nan mais stop là t'y comprends strictement rien.
T'as dis une ânerie c'est pas la mort mais n'essaye pas de faire des pirouettes t'es sur LinuxFr et on est pas vendredi, => t'as aucune chances :-D
Pour info lo = loopback = interface réseau système.
kentoc'h mervel eget bezan saotred
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à -2.
Cf message au dessus. Je pensais que lo était cette fonctionnalité : http://wiki.wireshark.org/DisplayFilters (mal lu, la fatigue tout ça…)
[^] # Re: HTML5
Posté par Batchyx . Évalué à 3.
C'est quoi une "interface réseau système" ? Techniquement, toutes les interfaces réseaux sont gérées par le système, vu que pour le noyau, la définition même d'une interface réseau n'est qu'une abstraction des couches inférieures, abstraction qui est notamment utilisée par les implémentations des protocoles IP.
[^] # Re: HTML5
Posté par reynum (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2013 à 11:41.
J'admets que c'est pas très bien formulé.
Peut être que dire : interface réseau interne ou alors l'interface réseau du système aurait été plus juste ?
kentoc'h mervel eget bezan saotred
[^] # Re: HTML5
Posté par delio . Évalué à 2.
non.
C'est l'interface loopback. En français ça donne un truc moche du style "interface (virtuelle) de rebouclage"
[^] # Re: HTML5
Posté par reynum (site web personnel) . Évalué à 2.
Effectivement c'est clair comme de l'eau de roche. En particulier la notion de rebouclage.
Surtout qu'à la base je répondais à ça donc au vu du contenu du message je ne voyais pas l'intérêt de m'étendre sur des détails.
kentoc'h mervel eget bezan saotred
[^] # Re: HTML5
Posté par Marotte ⛧ . Évalué à 2.
Merci. Je ne me suis jamais fait avoir mais j'essaierai de m'en souvenir si je me retrouve à utiliser tcpdump via SSH :) Je suppose que dans ce cas il faut indiquer à tcpdump de filtrer afin de ne pas afficher le trafic SSH.
[^] # Re: HTML5
Posté par freem . Évalué à 6.
Ha ben merci, j'ai bien ri.
Cela dit, rassures-moi, c'était bien une blague?
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à -4.
À 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)
[^] # Re: HTML5
Posté par gnumdk (site web personnel) . Évalué à 5.
Et sinon tu connais Qt Quick?
[^] # Re: HTML5
Posté par dave_null (site web personnel) . Évalué à -1. Dernière modification le 22 octobre 2013 à 21:23.
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 ?
[^] # Re: HTML5
Posté par gnumdk (site web personnel) . Évalué à 4.
Tu parles du code dégueulasse et non maintenable?
[^] # Re: HTML5
Posté par freem . Évalué à 4.
Bien ce que je pensais :)
Enfin, personnellement, je ne pense pas que les technos basées sur HTML soient déjà mûres, et faites pour, avoir des IHM aussi performantes que ce qu'on à sur le bureau.
Cela dit, je suis plutôt d'accord sur certaines de tes interventions: si c'est bien codé, ça ne devrait pas changer grand chose que l'IHM soit en gtk, motif, Qt ou html, les fonctionnalités seront les mêmes.
A ce niveau, le logiciel qui m'impressionne le plus, c'est clairement mpd. Ca, c'est un logiciel portable, et qui ne risque pas d'avoir de problèmes d'intégrations à cause d'une stupide lib graphiques qui ne sera de toutes façons plus à la mode dans 10 ans. Et ça, ça vaut pour HTML et sa tétrachiée d'ajouts pour lui faire faire ce que ce n'est pas censé faire de base (aka: des logiciels s'exécutant côté client) aussi.
On en fait trop autour de ce truc.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 22 octobre 2013 à 18:22.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTML5
Posté par freem . Évalué à 2.
Ben non. Je trouve que les UI des sites web et autres webapp sont bien loin de celles que j'ai avec les applications desktop de ma machine.
Ce qui n'empêche pas que changer la techno utilisée pour l'IHM ne devrait pas changer des masses de code si l'architecture est bien foutue.
Justement. MPD n'a pas d'IHM, ou plutôt, on peut considérer (je dit bien "peut" et pas "doit", ainsi que "considérer" et non "constater") que ce logiciel à de nombreuses IHM: ario, ncmpcpp, etc.
Je sais que techniquement, il ne s'agit pas d'IHM mais d'applications séparées, mais elles remplissent malgré tout la fonctionnalité d'IHM (certains en font plus, cependant).
Bruit.
En espérant avoir enlevé les zones d'ombre de mon précédent message.
# Qui sera le prochain ?
Posté par windu.2b . Évalué à 10.
Gnome ?
====>[]
[^] # Re: Qui sera le prochain ?
Posté par Guillaume Denry (site web personnel) . Évalué à 10. Dernière modification le 22 octobre 2013 à 10:50.
Gimp !
(vu la signification de Gtk, ça voudrait dire que Gtk deviendrait automatiquement Qt ^^)
[^] # Re: Qui sera le prochain ?
Posté par Gui13 (site web personnel) . Évalué à 2.
Qimp?
[^] # Re: Qui sera le prochain ?
Posté par freem . Évalué à 1.
Euh… le 'G' veut dire Gnu, hein, s'pas un acronyme récursif…
[^] # Re: Qui sera le prochain ?
Posté par erdnaxeli (site web personnel) . Évalué à 4.
Non, ça signifie « The Gimp Tool**k**it ».
Par contre je n'ai pas trouvé de référence sur gtk.org, ça vient donc de wikipédia.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Qui sera le prochain ?
Posté par freem . Évalué à 5. Dernière modification le 22 octobre 2013 à 15:52.
Je parlais bien évidemment du G de Gimp… Ca me semblait logique, puisque je répond à un message suggérant de renommer Gimp en Qimp. Bref.
Sinon, l'info est ici: http://www.gtk.org/
"GTK+, or the GIMP Toolkit, "
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Qui sera le prochain ?
Posté par reynum (site web personnel) . Évalué à 5.
En même temps Gimp en QT outre le fait de nous faire rire ça pourrait donner pas mal.
kentoc'h mervel eget bezan saotred
[^] # Re: Qui sera le prochain ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 23 octobre 2013 à 03:10.
Étant donné que le cœur de GIMP est désormais poussé vers GEGL, cela signifie que GIMP est de plus en plus seulement une UI. Presque tout ce qui concerne le traitement d'image passe dans GEGL. GIMP, c'est donc principalement du code GTK+ lié à du code GEGL (un widget GTK+ appelle telle opération GEGL).
Donc passer en QT n'a pas trop de sens, car ça signifierait en gros tuer 90% du code, je pense. QIMP ne serait donc pas un port de GIMP, mais pourrait tout à fait être une nouvelle application QT faite à partir de zéro, qui utiliserait aussi GEGL (ce qui est fortement encouragé! Plus il y aura d'applications utilisant cette lib commune de traitement d'images, plus celle-ci sera améliorée, avec de nouvelles opérations, plus performante, etc.).
Ceci dit, cela resterait un énorme boulot. Dans un logiciel comme GIMP, l'UI reste très importante. Des logiciels Libres de traitement d'image qui font des trucs de ouf, y en a d'autres, comme ImageMagick, mais beaucoup de gens veulent une UI. Donc ils utilisent GIMP, alors peut-être même que le rendu final d'ImageMagick aurait peut-être plus été ce qu'ils voulaient, ou bien que cela aurait été plus facile pour traiter des lots d'images s'ils avaient pris juste 5 min à lire la doc. Si je me plante pas G'mic aussi a une UI en ligne de commande, mais les gens l'utilisent surtout à travers GIMP (ce qui n'ajoute absolument rien à G'Mic quand seulement ces effets G'mic sont appliqués à l'image). L'UI de GIMP a beaucoup de problèmes et mérite vraiment d'être améliorée radicalement, voire transformée complètement. Mais elle a le mérite d'exister. Toute nouvelle implémentation d'UI (en QT par ex), même s'ils n'auront pas à se préoccuper autant du cœur du programme (en se basant aussi sur GEGL), prendra tout de même énormément de temps et de dédication pour en arriver au même nombre de fonctionnalités que GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Qui sera le prochain ?
Posté par phoenix (site web personnel) . Évalué à 3.
C'est pas Krita justement ?
[^] # Re: Qui sera le prochain ?
Posté par gnumdk (site web personnel) . Évalué à 1.
Non, Krita est un logiciel de dessin, pas de traitement d'image…
[^] # Re: Qui sera le prochain ?
Posté par freem . Évalué à 1.
Gimp n'est pas un logiciel de dessin?
[^] # Re: Qui sera le prochain ?
Posté par delio . Évalué à 0.
non
[^] # Re: Qui sera le prochain ?
Posté par freem . Évalué à 1.
J'ai rien contre la négation, mais, pourquoi?
Wikipedia me dit ceci:
Pour moi, le dessin, l'acte de dessiner, c'est bien celui d'éditer (au sens de modifier, naturellement) une image, chose que gimp à l'air de quand même faire super bien (pour ceux qui arrivent a s'en servir, je veux dire). Donc ça me semble pas aberrant de qualifier the gimp de logiciel de dessin?
[^] # Re: Qui sera le prochain ?
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
Yep, y'a quand même une sacrée différence :
Dans gimp, tu as des filtres, des calques, des brosses.
Et dans Krita, tu as des filtres, des calques, des brosses.
[^] # Re: Qui sera le prochain ?
Posté par gnumdk (site web personnel) . Évalué à 4.
Ben, écoutes, t'iras expliquer cela aux dev de Krita qui ont toujours clamé haut et fort que leur soft n'était pas une alternative à GIMP car son seul but était de faire des dessins…
Moi, je n'utilise ni l'un ni l'autre…
# bébé
Posté par fravashyo . Évalué à 5.
son bébé c'est mac os x, gtk ou xamarin (le truc qui tourne sur tout sauf sous les distributions linux) : "Thinking about supporting iOS, Android, Mac and Windows? Xamarin allows you to write it all in C#. "
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: bébé
Posté par Atem18 (site web personnel) . Évalué à 2.
En fait, ce mec défend des technos Apple et Microsoft. Comme c'est ironique quand on connait son passé dans le monde du libre….
[^] # Re: bébé
Posté par freem . Évalué à 4.
Possible, toujours est-il que la, il ne fait pas la moindre pub pour une lib qui serait dev par apple ou ms, il indique seulement qu'il est possible avec gtk de se passer de X sous mac.
En fin de compte, si je comprend bien, les raisons du switch, c'est que GTK supporte mal les plate formes mobiles, mais surtout que ça nécessite soit un port expérimental, soit Xorg sous mac OS X. Il parle aussi d'un problème d'intégration, mais je n'ai pas eu l'impression qu'il s'agisse du principal souci.
Plutôt d'excellentes raisons pour le coup, bien que ça ne soit pas spécialement surprenant (j'ai l'impression que mac OS est une plate-forme assez pénible… la plupart des rapports de bug spécifiques à un OS que je vois des projets open source semblent y être liés… ou alors il n'y a personne sur mac qui contribue, je sais pas).
Autrement dit: rien à voir avec la défense des produits Apple ou Microsoft.
[^] # Re: bébé
Posté par gnumdk (site web personnel) . Évalué à 10.
Bref, hormis pour les C++ haters, il y'a peu de raison de ne pas choisir Qt plutôt que GTK…
[^] # Re: bébé
Posté par freem . Évalué à 2. Dernière modification le 22 octobre 2013 à 14:46.
Il n'y a pas un port C++ pour GTK? GTKmm ou un truc du genre?
Enfin, le truc qui me chagrine le plus avec Qt à l'heure actuelle, c'est qu'il ne s'agit pas juste d'une lib pour faire des IHM, plutôt d'un framework complet. Suis pas fan d'utiliser un seul outil énorme pour tout faire, même si j'en comprend les intérêts par rapport à utiliser une foultitude de lib spécialisées.
Le souci, c'est qu'il ne semble pas y avoir des masses de lib spécialisées pour faire des IHM, qui soient portables, légères, et qui ne tentent (je n'ai pas dit que Qt, Gtk, ou quoique ce soit force, attention, je parle de tentation ) pas le dev d'utiliser des classes non standard.
Je parle ici des strings et divers conteneurs, et pas pour un souci de perf, mais de garder un code le plus standard possible, de sorte a ce que, si, un jour, par malheur, il faille changer l'interface, qu'on aie pas une trop grosse dépendance à une seule lib.
En gros, si boost intégrait une lib graphique, ce serait à peu près l'esprit que j'aimerai (même si, je sais, boost et les versions c'est pas toujours top il paraît. Je n'utilise pas depuis assez d'années pour avoir eu des problèmes avec ça cependant).
PS: je ne dis pas non plus que c'est simple à faire, surtout pour ce qui est de l'intégration à l'environnement natif
PPS: il y a toujours des raisons majeures de choisir Gtk au lieu de Qt: combine au moins deux de ces éléments: l'expertise des gens qui travaillent, l'existence d'une base de code existante, le manque de main d'oeuvre.
[^] # Re: bébé
Posté par claudex . Évalué à 8.
Qt, surtout depuis la version 5, est modulaire, on peut donc avoir uniquement la partie IHM sans avoir le réseau ou le SQL. Par contre, comme tu le dis, il faut résister à la tentation d'utiliser tout Qt. (mais à mon avis, si tu es tenté d'utiliser des classes non standard, c'est que les classes standards ne sont pas si bien que ça.)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bébé
Posté par Gof (site web personnel) . Évalué à 4.
C'était déjà le cas avec Qt 4.0.
Et depuis Qt 5 les widgets sont séparés pour ne pas devoir en dépendre quand on utilise QML
[^] # Re: bébé
Posté par claudex . Évalué à 3.
Il livrait déjà les modules à part avec Qt4 ou il fallait les séparer après téléchargement ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bébé
Posté par Sébastien Wilmet . Évalué à 3.
Je ne connais pas pour Qt, mais les entreprises qui offrent du support ou développent GTK+ : Red Hat, Suse, Lanedo, Collabora, Igalia, Openismus, Codethink, Canonical, des indépendants, sans compter
les célibatairesla communauté. Il y a donc un bus factor > 1.GTK+ 3 apporte quand même de plus en plus de nouvelles API bien foutues. Et utilisant GTK+ depuis pas mal d'années, je trouve que c'est loin d'être une calamité. Parfois quand on a une utilisation un peu plus poussée d'une API, on se rend compte que la documentation n'est pas suffisante, il faut aller voir le code. J'écris donc de temps en temps des patchs pour améliorer la doc, et il y a généralement une review assez rapidement.
Et quand on développe en GTK+, on utilise aussi GLib, GObject, GIO. Ce sont des bibliothèque très stable au niveau de l'API, et c'est un vrai bonheur de les utiliser. Pour écrire une application en console, ça fait d'ailleurs très bien l'affaire. Un truc qui m'a réjoui récemment, c'est GSubprocess, pour lancer des sous-processus facilement, tout en supportant pas mal de fonctionnalités avancées, comme lire ou écrire des flux de données de manière asynchrone entre plusieurs processus. Dans son domaine, GSubprocess est apparemment ce qui se fait de mieux dans le libre.
[^] # Re: bébé
Posté par freeze . Évalué à 2.
Je pense que le sens de soutenu était à prendre en terme de rapidité, pas dans le sens "nombre de personnes qui le soutiennent"
[^] # Re: bébé
Posté par tanguy_k (site web personnel) . Évalué à 0.
C'est pas l'avis de Benjamin Otte : "This gives the GNOME project essentially a bus factor of 1" (encore plus vrai pour GTK+ et GLib puisqu'il y a encore moins de developpeurs).
[^] # Re: bébé
Posté par Atem18 (site web personnel) . Évalué à 8.
Pour avoir testé OS X en machine virtuelle, je confirme. Ah, pour aller Internet, écouter de la musique, développer des trucs Apple-only, etc., pas de soucis. Mais si ce que tu veux en faire, n'est pas quelque chose que Apple a approuvé en premier, vouloir développer sur cet ersatz de FreeBSD, c'est juste du suicide.
[^] # Re: bébé
Posté par El Titi . Évalué à 4.
J'adore cet argument.
Bref si on a pas un parti pris d'un coté ou de l'autre on peut interpréter ca différemment:
Ca fonctionne très bien lorsqu'on prend la peine d'investir.
Vu que ca n'intéresse pas les Linuxiens, ils ne sont pas prêt d'y retrouver le même confort pour leur spécificités.
Moi en tout cas je vois de plus en plus de codeur qui bossent sous IntelliJ, Eclipse ou autre RubyMine et Pycharm passer sous OSX.
Apple approuved ? Sure ?
[^] # Re: bébé
Posté par freem . Évalué à 1.
J'ai personnellement du mal a m'imaginer programmer avec eclipse ^
Enfin, sauf si je veux prendre des pauses café régulièrement, bien entendu :p
[^] # Re: bébé
Posté par Prae . Évalué à 1.
Etre un bon librien c'est d'être absolument sous Linux ou BSD ?
[^] # Re: bébé
Posté par Sébastien Wilmet . Évalué à 5.
On dit libriste.
[^] # Re: bébé
Posté par Marotte ⛧ . Évalué à 6.
Non, on peut aussi utiliser Haiku ou FreeDOS. Et surement d'autres auxquels je ne pense pas.
Bon… Utiliser quotidiennement FreeDOS faut en vouloir. Par contre Haiku me semble vraiment prometteur.
https://www.haiku-os.org/
http://www.freedos.org/
[^] # Re: bébé
Posté par Prae . Évalué à 4.
Je savais que quelqu'un allait répondre cela…
Je vais être plus précis: Si on n'est pas sur un système d'exploitation libre, on n'est donc pas un vrai gars du libre ?
[^] # Re: bébé
Posté par Marotte ⛧ . Évalué à 6.
Et bien tu peux être libriste si tu privilégies les formats ouverts et les applications libres. Mais n'utiliser exclusivement qu'un OS propriétaire ça fait tâche quand même ! :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bébé
Posté par claudex . Évalué à 3.
C'est quoi un vrai gars du libre ? Un type qui exécute sans le savoir un bout de JS sous licence MIT sans le savoir ? Un type qui n'utilise que du libre, de son OS à son distributeur de billet en passant par son fer à repasser ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bébé
Posté par Marotte ⛧ . Évalué à 3.
Ya encore des gens qui utilisent un fer à repasser ?
[^] # Re: bébé
Posté par TImaniac (site web personnel) . Évalué à 5.
Xamarin c'est le produit "commercial", l'équipe s'occupe toujours de la version Linux : elle est open-source comme d'hab (Mono, monodevelop, GTK# & co).
# Et d'autres...
Posté par Philippe F (site web personnel) . Évalué à 10.
TortoiseHG a fait la migration aussi il y a un an ou deux. Et il y a un environnement de dev Python dont le nom m'échappe qui passe aussi à Qt.
Je saute sur mon destrier à remonter le temps et je m'en vais de ce pas nourrir les trolls d'il y a 10 ans avec ces nouveaux arguments imparables !
Sinon … on vous l'avait tous dit il y a longtemps mais vous ne vouliez pas nous croire!
# Et pour les aveugles ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Remarque pas directement liée à WireShark, mais plus à Gtk/Qt: j'avais discuté il y a quelques temps avec un déficient visuel (et j'ai également suivi sa conf aux JDLL l'année dernière), et Gtk (avant la 3.x, ce qui était l'objet de la critique principale) était la seul bibliothèque d'interfaces libre à permettre l'utilisation correcte d'un lecteur braille. Du coup je me pose la question de la situation aujourd'hui, et si les passages (bruyants) à Gtk 3.x et Qt ne risquent pas de mettre les mal-voyant à l'écart.
Jean-Philippe, si tu lis ce commentaire, je serais intéressé par ton avis et les progrès dans la situation actuelle.
[^] # Re: Et pour les aveugles ?
Posté par Gof (site web personnel) . Évalué à 6.
Il y a eu de grosse amélioration dans Qt5 en ce qui concerne l'accessibilité. C' est peut-être pas encore parfait, mais c'est mieux qu'avant
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.