Journal Qt ? GTK+ ?...

Posté par (page perso) .
Tags :
13
7
juil.
2011

Les utilisateurs se sont toujours demandé quel côté de la force choisir entre GTK+ ou Qt, ce choix étant bien souvent dicté par le bureau Gnome ou KDE entres autres. Une fois ce choix effectué on se retrouve à privilégier des applications tournant avec la bibliothèque favorite de notre gestionnaire de bureau en rejetant parfois certaines applications pour ne pas avoir à charger des librairies en plus mais également pour s'assurer d'une meilleure intégration dans notre environnement.

Je me suis posé cette question, comme tout un chacun ici je pense, et quand je me suis attelé à la tâche de coder une petite application j'ai du faire mon choix. C'est alors que j'ai pensé à une sorte de binding mais pour les boites à outils graphiques !

On pourrait, par exemple, profiter d'un langage commun pour faire des interfaces graphiques mais le choix de la bibliothèque utilisée serait fait après-coup, par l'utilisateur !

J'y vois plusieurs avantages :

  • Inter-opérabilité
  • Réutilisation de code
  • Pour les langages non compilés il serait possible de changer de librairie graphique à la volée
  • Cohérence forte dans l'aspect visuel des applications puisque toutes basées sur la même chose

Mais quelques inconvénients :

  • Pour les langages qui doivent êtres compilés, le choix doit s'effectuer à ce moment là et on se retouvera avec plusieurs versions d'un même logiciel dans les dépôts (tux-gtk,tux-qt,tux-wxwidget...)
  • Frein a l'innovation : en effet, il faudrait mettre en place une norme, un standard définissant les fonctions disponibles et certaines fonctions ne seraient pas disponibles avec certaines librairies. Cependant, à terme, les innovations se retrouveraient dans la norme et feraient avancer tout le monde.
  • Conséquence du précédent, un gros boulot de binding et de normalisation de noms devrait être fait mais majoritairement au début.

J'ai beau chercher, j'ai rien trouvé de semblable alors je vous pose la question : Vous en pensez quoi ? Y-a-t-il quelque chose de semblable en projet quelque part ?

  • # libYUI

    Posté par . Évalué à 10.

    Les mecs d'opensuse ont développé une bibliotheque similaire pour les besoins de YAST

    http://gitorious.org/libyui

    • [^] # Re: libYUI

      Posté par (page perso) . Évalué à -2.

      Wxwidget fait en partie le boulot entre win/GTK/macOS
      D'ailleurs, c'est pour ça que je l'ai choisi pour développer mes petites applis. Par contre,wxwidget a des bugs différents selon la plaeteforme d'exécution, il faut donc quand même bien tester son appli sur les OS privateurs...

      • [^] # Re: libYUI

        Posté par (page perso) . Évalué à 3.

        s/ différents selon la plaeteforme d'exécution, il faut donc quand même bien tester son appli sur les OS privateurs.../, il faut donc quand même bien tester son appli/

      • [^] # Re: libYUI

        Posté par (page perso) . Évalué à 10.

        wxWidgets est un emplâtre sur une jambe de bois... L'API est mal foutue (quantité de fonctions qui fonctionnent sur une plateforme mais pas une autre), et la gestion des évènements via des tables, calquée sur les MFC (beuk), et bon... Faire du C++ pour que tout le code derrière soit en fait des macros, c'est pas très bandant.

        Je suis plutôt GTK, mais quitte à faire du C++, autant prendre Qt, ou au pire, du GTKmm. Mais je ne compte pas refaire du wxWidgets avant longtemps.

        • [^] # Re: libYUI

          Posté par (page perso) . Évalué à 6.

          c++ ou pas, wx ou pas, c'est dur de bander en plaçant des boutons et des combo box dans une boite de dialogue (je deteste ça)

          • [^] # Re: libYUI

            Posté par (page perso) . Évalué à 2.

            c'est dur de bander

            Et vice versa.

            Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # Qt

    Posté par (page perso) . Évalué à 10.

    Moi ce que j'aime bien quand je développe en Qt c'est l'API que propose Qt, qui n'est pas qu'un simple framework graphique mais propose aussi la gestion des QString, ....

    Passer sur une couche proxy risquerai de me faire régresser et de ne plus avoir la puissance de Qt. Je préfère travailler sur Qt. De nous jours je considère qu'avoir un Gnu/Linux avec des applications Qt et Gtk qui tourne en même temps est monnaie courante. Même si je préfère KDE/Qt, si j'ai un besoin qui n'existe que grâce à une application Gtk, je ne vais pas faire la fine bouche.

    • [^] # Re: Qt

      Posté par . Évalué à 10.

      Même si mon environnement de bureau favori est GNOME3, actuellement je développe mes applications sur Qt4…
      Les raisons : portabilité sur Linux, Mac et Windows, Qtcreator (le must des IDE à mon avis) et l'API Qt qui permet de tout faire (ou presque)…

      • [^] # Re: Qt

        Posté par (page perso) . Évalué à 10.

        Moi tout pareil, sauf que je viens de tester KDE4 après des années sous GNOME, et comment dire, je découvre ce que peut être un vrai desktop Linux.
        Tout d'abord la gestion des thèmes est intégré au desktop, on peut choisir un thème depuis une interface dédié, le télécharger et l'installer en 2 clics, nul besoin d'aller sur un site web, récupérer un tgz à installer dans un répertoire comme sous GNOME ...

        Idem pour les fonds d'écrans, et même l'installation de thèmes dans une application comme Kopète est intégrée.

        Konqueror est excellent comme gestionnaire de fichier, rien à envier à nautilus et comme navigateur web il intègre webkit même si KHTML est mis part défaut sur Fedora, un clic pour switcher.
        KWallet est très bien intégré même avec Chrome, sauf avec Firefox.

        Les clients twitter sont excellent, que ce soit qwit ou chokok, rien à envier au bouzeu gwibber.

        Avec KDE j'ai l'impression d'être en 2011, c'est dingue.

        • [^] # Re: Qt

          Posté par . Évalué à 10.

          Merci, c'est ce qu'on se tue à vous dire depuis deux ans !!

          • [^] # Re: Qt

            Posté par . Évalué à 10.

            Menteur ! y a deux ans on était en 2009 !

        • [^] # Re: Qt

          Posté par . Évalué à 2.

          Konqueror est excellent comme gestionnaire de fichier, rien à envier à nautilus

          La dernière fois que j'ai testé KDE 4, je n'avais pas les prévisualisations des vidéos sous Fedora (le truc que Nautilus fait par défaut et que je trouve indispensable). Fallait installer « MPlayerThumbs » qui n'est pas dans les paquets Fedora.

          Qu'en est-il maintenant ? (MPlayerThumbs n'y est toujours pas, mais est-ce que Konqueror ou Dolphin fait la prévisualisation des vidéos par défaut ?)

          Knowing the syntax of Java does not make someone a software engineer.

          • [^] # Re: Qt

            Posté par (page perso) . Évalué à 4.

            Exact il n'y a rien par défaut avec dolphin dans Fedora en tout cas, je n'ai pas cherché plus loin pour l'instant, mais c'est plus génant pour les photos.

            • [^] # Re: Qt

              Posté par (page perso) . Évalué à 5.

              En fait c'est une simple option à cocher dans les options de Dolphin.

          • [^] # Re: Qt

            Posté par (page perso) . Évalué à 4.

            kdemultimedia-ffmpegthumbs

        • [^] # Re: Qt

          Posté par (page perso) . Évalué à 2.

          Il faudra vraiment que j'essaie un jour ces nouveaux environnements, mais je suis pas sûr que j'y gagnerais par rapport à mes *box.

          Faudra aussi que j'utilise un gestionnaire de fenêtres "tiling" vu que j'utilise openbox de la même manière.

        • [^] # Re: Qt

          Posté par . Évalué à 3.

          Moi, c'est l'agenda KDE qui m'a convaincu : rien trouvé de tel sous Gnome.

  • # Rajouter une couche

    Posté par (page perso) . Évalué à 10.

    Je ne vois pas l'intérêt de rajouter une couche. Surtout qu'il y a des différences fondamentales dans l'ergonomie entre QT et GTK et même avec un framework par-dessus, ça va être difficile à gommer.

    En plus, QT est nettement plus portable que GTK. GTK hors du monde Linux, c'est assez l'horreur niveau ergonomie alors qu'une application QT ressemble à quelque chose sous Windows ou OSX.

    • [^] # Re: Rajouter une couche

      Posté par . Évalué à -3.

      ça dépends pour quelle utilisation, pour des petits utilitaires avec des UX génériques, ça permet de développer rapidement les IHM et de se concentrer sur la partie métier. Tu développeras évidemment pas {Open,Libre,Star}Office avec ce genre de couche d'abstraction (ironie inside) !

      En plus, QT est nettement plus portable que GTK

      C'est pas intrinsèque à Gtk+, le problème c'est que les ports windows et mac intéressent peu de monde (enfin, peu de monde qui a envie de contribuer à ces ports)

      c'est assez l'horreur niveau ergonomie alors qu'une application QT ressemble à quelque chose sous Windows ou OSX.

      Ouais, sauf qu'avant Qt4.4, une application Qt ça ressemblait à rien du tout sous GNOME et que c'est toujours pas conforme aux HIG actuellement (des broutilles certes mais suffisamment perturbant à mon oeil de développeur d'IHM)

      • [^] # Re: Rajouter une couche

        Posté par (page perso) . Évalué à 6.

        T'as toujours pas répondu à ma question, le fait que certaine application GNOME ne respectent pas les HIG les plus basiques de GNOME ne te choque par par contre ?

        • [^] # Re: Rajouter une couche

          Posté par . Évalué à 3.

          Je connais aucune applications GNOME qui ne placent pas correctement les labels dans les menus par exemple ... Et ne pouvant pas répondre à une question qui ne m'était pas posé, je te répondrais maintenant que oui, ça me choque.

          • [^] # Re: Rajouter une couche

            Posté par (page perso) . Évalué à 2.

            La question était dans un autre journal ;)

            En clair, je parle de nautilus et de ses boutons de navigation centrés à droite, ce qui n'a rien de standard dans les applications GNOME...

            Sinon, c quoi ton histoire de label dans les menus ?

    • [^] # Re: Rajouter une couche

      Posté par (page perso) . Évalué à -9.

      GTK hors du monde Linux, c'est assez l'horreur niveau ergonomie

      Un peu comme Qt sous Linux ?

      • [^] # Re: Rajouter une couche

        Posté par . Évalué à 5.

        Vous avez un exemple de ce que vous avancez ?

        • [^] # Re: Rajouter une couche

          Posté par (page perso) . Évalué à -9.

          Bin quand j'utilise des applis Qt, j'ai l'impression d'être sous Windows 95. Les applis ont un aspect très austère et repoussant. Je sais que c'est customisable, mais vu que je ne travaille pas sous KDE, je n'ai pas trouvé.

          Autre problème, je constate des bugs depuis des années lors d'utilisation de toutes applis Qt hors de KDE. Genre les menus déroulants qui apparaissent la première fois en haut de l'écran au lieu du dessous de la barre de menu, puis au bon endroit ensuite. Cela donne un côté pas fini assez insupportable.

          • [^] # Re: Rajouter une couche

            Posté par . Évalué à 3.

            Bin quand j'utilise des applis Qt, j'ai l'impression d'être sous Windows 95. Les applis ont un aspect très austère et repoussant. Je sais que c'est customisable, mais vu que je ne travaille pas sous KDE, je n'ai pas trouvé.

            Pour changer le thème, tu peux utiliser qtconfig (pas besoin de KDE).

          • [^] # Re: Rajouter une couche

            Posté par . Évalué à 2.

            Autre problème, je constate des bugs depuis des années lors d'utilisation de toutes applis Qt hors de KDE. Genre les menus déroulants qui apparaissent la première fois en haut de l'écran au lieu du dessous de la barre de menu, puis au bon endroit ensuite. Cela donne un côté pas fini assez insupportable.

            Je n'ai jamais entendu parler de ça, avez-vous rapporté le bug à Qt ? (puisque vous pensez que le bug est dû à Qt)

          • [^] # Re: Rajouter une couche

            Posté par . Évalué à 3.

            Le seul truc que je déteste sous Qt, c'est Umbrello : exemple typique de l'appli mal finie buggée jusqu'à la moelle.

            • [^] # Re: Rajouter une couche

              Posté par (page perso) . Évalué à 3.

              Premièrement, ce n'est pas très étonnant, ça fait des années que la maintenance du projet est au strict minimum. Il y a d'ailleurs un GSOC sur le portage sur Qt/KDE4 (viré l'utilisation de KDESupport.

              Deuxièmement, si tu as un équivalent libre, ça m'intéresse, je n'en ai pas trouvé.

              « 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: Rajouter une couche

                Posté par . Évalué à 2.

                Mouais,un équivalent libre natif Linux, j'ai pas trouvé hélas (ça me gène réellement parce qu'à première vue, Umbrelo est sympa, mais il ne se passe pas 30 mn sans qu'il ne se vautre donc il est inutilisable). Pour ma part, j'utilise StarUml sous Wine (libre, mais pas porté sous Linux ma connaissance). C'est beaucoup plus stable.

        • [^] # Re: Rajouter une couche

          Posté par . Évalué à 2.

          VLC ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Rajouter une couche

          Posté par . Évalué à -6.

          Non c'est bon on va pas repartir dans ce débat, on l'a déjà eu il y a quelques jours. L conclusion, c'était que GTK s'intègre très bien dans un environnement Qt mais que la réciproque est fausse.

          • [^] # Re: Rajouter une couche

            Posté par . Évalué à 5.

            non, la conclusion est une application Gnome s'intègre très bien avec Gnome, et pis c'est tout. C'est déjà plus facile avec une application KDE.

            Une application Qt pure ou Gtk pure ne pose aucune difficulté.

            • [^] # Re: Rajouter une couche

              Posté par . Évalué à 4.

              C'est déjà plus facile avec une application KDE.

              En pratique, je constate plutôt le contraire (mais avec l'arrivée de GNOME3, ça risque d'être blanc bonnet et bonnet blanc). T'as déjà essayé de changer le moteur de thème d'une appli KDE sans le bouzin de conf KDE (hint: il ne tient pas compte de l'utilitaire fourni avec Qt)

              • [^] # Re: Rajouter une couche

                Posté par . Évalué à 2.

                De mémoire quand j'étais encore sous gnome, pour ça je faisais une modification du fichier ~/.kde/share/config/kdeglobals

                J'ajoutais des options du type "Style=Gtk+"

                Je n'ai plus les fichiers sous les yeux comme maintenant je suis sous KDE directement.

          • [^] # Re: Rajouter une couche

            Posté par (page perso) . Évalué à 0.

            La conclusion, c'était que GTK s'intègre très bien dans un environnement Qt mais que la
            réciproque est fausse.

            Foutaise !

            Certaines applications en Qt ne s'intègre pas parfaitement dans GNOME car le développeur de ces dites applications n'ont fait aucun effort (en particulier les applications KDE).

            Mais si tu développes une application avec Qt, avec très peu d'effort il est possible de s'intégrer à Gnome. Example parmis d'autres: QtCreator.

            • [^] # Re: Rajouter une couche

              Posté par (page perso) . Évalué à 10.

              Oui, est si Gtk s'intègre bien dans KDE c'est grace à QtCurve et Oxygen-gtk c'est à dire le boulot de deux devs KDE...

            • [^] # Re: Rajouter une couche

              Posté par . Évalué à 2.

              Et ben écoute faudra aller l'expliquer dans l'autre débat, moi je ne fais que rapporter le consensus. À la base j'ai pas franchement d'avis sur la question n'étant ni pro l'un ni pro l'autre. On a juste vu des captures d'écrans de KDE bien propres (avec des applis GTK et même XUL) et des captures d'écrans Gnome bien crades. (je précise que je préfère utiliser Gnome, au cas où je me fasse inutiler par conviction, mais je n'ai pas de DE sur mes PC)

        • [^] # Re: Rajouter une couche

          Posté par . Évalué à 2.

          Tu as vu quel jour il poste ?

  • # choisir

    Posté par . Évalué à 10.

    Choisir une application pour son toolkit graphique est un non sens. Ce qui compte, c'est l'application final. Par exemple, j'utilise digikam sous gnome et j'ai pas honte.

    freedesktop était une bonne initiative pour harmoniser, mais ça ne va pas assez loin, et assez vite. A cause de qui ?

    • [^] # Re: choisir

      Posté par (page perso) . Évalué à 2.

      Tout pareil mais c'est déstabilisant d'avoir un beau thème sous gnome avec des icônes topmoumoutesEnpoildechameauDesmontagnes, de lancer Digikam et d'avoir des icônes kde. Du coups les labels au survol c'est pratique mais chez moi ils sont en fond noir écrit en noir... Bien moins lisible :(

      Born to Kill EndUser !

  • # À l'heure actuelle ?

    Posté par . Évalué à 4.

    C'est quoi l'état des lieux en la matière ? Il existe des applications qui proposent plusieurs interfaces (je pense à Transmission, qui possède des interfaces en Cocoa, GTK, Qt, web et en lignes de commandes).

    Comment font-ils ? Tout est très indépendant j'imagine ?

    • [^] # Re: À l'heure actuelle ?

      Posté par . Évalué à 10.

      Une bonne conception, tu sépares le coeur de l'application de son interface utilisateur.

      • [^] # Re: À l'heure actuelle ?

        Posté par (page perso) . Évalué à 2.

        Je suis pas un expert en dev et encore moins en interface, mais de mémoire il me semble que GTK ou QT propose leur propre solution pour la gestion du réseau et des joyeusetés du genre.

        Born to Kill EndUser !

        • [^] # Re: À l'heure actuelle ?

          Posté par (page perso) . Évalué à 6.

          GTK ou QT propose leur propre solution pour la gestion du réseau et des joyeusetés du genre.

          D'une tu n'es pas obligé de les utiliser, et de deux tu peux très bien utiliser le réseau de Qt et l'UI de GTK si tu as envie.

          Bref, tu as le choix.

      • [^] # Re: À l'heure actuelle ?

        Posté par (page perso) . Évalué à 3.

        Ceci dit ça dépend fortemment de ce que fait l'application. Pour Transmission, c'est relativement simple niveau interface (il faut afficher une progression et des options) et la grosse partie de l'intérêt de l'application c'est ce qu'il y a derrière (télécharger des torrents).
        Pour une application à la Inkscape, Gimp ou Digikam ou il y a nettement plus d'interactivité et de fonctions liées à l'interface, c'est je pense nettement plus dur de faire une séparation nette sans pondre un code horriblement compliqué.

  • # Réduction des capacités au simple facteur commun

    Posté par (page perso) . Évalué à 4.

    Le risque avec l'idée d'une surcouche est que l'on se ramène souvent au facteur commun. Je m'explique, si GTK gère quelque chose que QT ne sait pas faire (je parle uniquement graphique) ou inversement... la surcouche risque de ne pas permettre d'utiliser la dite fonctionnalité par soucis d'harmonisation.

    J'entends déjà les gens du fond dire que l'on peut s'en sortir avec du #define pour savoir si on est dans tel ou tel environnement... personnellement je n'y trouve pas mon compte (trop spaghetti pour citer qu'un seul argument).
    On peut également imaginer émuler les comportements manquants, voir même les implémenter dans la surcouche.. et puis les remonter dans la librairie sous-jacente. Oui c'est possible, mais ça va vite devenir une galère et ralentir les développements de la surcouche et finalement représenter un coût tel que la surcouche devient trop lourde à maintenir.

    On a (eu)? cela avec la librairie AWT en java qui ne propos(e|ait) que le facteur commun des composant graphique des différentes plateforme (mais ce n'(était|est) pas son (seul|pire) défaut).

    Bref, l'idée est plus que louable, dans les faits je pense que c'est difficilement réalisable... mais tout est question de moyen.

    Alexandre COLLIGNON

    • [^] # Re: Réduction des capacités au simple facteur commun

      Posté par . Évalué à 0.

      Il est toujours possible de pallier ce problème en réimplementant les éléments manquants dans une lib pour simuler quelque chose d'uniforme. Dans un monde parfait, ce genre de pratiques pousseraient à amélorier les toolkits qui ont moins de fonctionnalités.

      Pour revenir au débat, j'ai bien l'impression que Qt est encore bien plus avancé que Gtk, sûrement à cause du fait que le toolkit appartient à une entreprise à l'opposé de Gtk. Ce dernier a moins de traction en nombre de développeurset semble avoir du mal à rattraper son retard même si Gtk3 semble une belle avancée.

  • # Qt ? GTK+ ?...

    Posté par . Évalué à 1.

    Qt ? GTK+ ?...

    peut être remplacer par "pour presque tous ou pour linux commercial redhat seulement" ? si ce n'est pas aujourd'hui ça peut être demain.

    hop hop hop je suis déjà loin

    • [^] # Re: Qt ? GTK+ ?...

      Posté par (page perso) . Évalué à 3.

      si ce n'est pas aujourd'hui ça peut être demain

      Tout ça parce que demain c'est trolldi...

  • # XUL

    Posté par . Évalué à 4.

    Y'a un binding GTK et un binding Qt pour XUL.

  • # et côté facilité de développement ? c'est qui qui gagne ?

    Posté par . Évalué à 2.

    Après un retour progressif et un (tout petit) peu de développement en Python (la lib Python pour le coeur + bricolage copier-coller et RTFM de surface pour les parties graphiques), j'aimerais commencer à faire du GUI pour les tâches où Zenity (et PyZenity) montre ses limites.

    Comme je travaille dans des environnement hétérogènes, je suis tenté par PyQt (les applis Qt4.4x s'intègrent parfaitement avec Gnome, pour le reste il y a qtconfig-qt4)

    Lequel est le plus facile à appréhender et a la courbe d'apprentissage la moins raide ?

    • [^] # Re: et côté facilité de développement ? c'est qui qui gagne ?

      Posté par (page perso) . Évalué à 3.

      J'ai utilisé à la fois PyQt et PyGTK et ma préférence va clairement à GTK, pour les raisons suivantes :

      • meilleure gestion des erreurs (avec PyQt, j'ai eu plusieurs problèmes conduisant à des "Segfaults", alors qu'avec GTK j'obtiens au pire des erreurs Python qui me génèrent un message d'erreur approprié facilitant le débogage).

      • PyQt inclut aussi de nombreuses librairies Qt qui n'ont pas directement à voir avec l'interface graphique, pour gérer le réseau, les chaînes de caractères, les threads,... ces librairies alourdissent l'ensemble et duppliquent des fonctionnalités déjà accessibles en Python via les modules standards. Au mieux tu n'en auras pas besoin, au pire tu seras obligé de les utiliser si tu veux coupler du réseau, des threads, etc, à ton interface. Alors qu'il serait plus simple d'utiliser les modules Python que le programmeurs Python a de bonnes chances de connaître déjà...

      Au final, Qt est assez orienté C++, alors que GTK a plus été pensé pour être utilisé dans différents langages de programmation.

      • [^] # Re: et côté facilité de développement ? c'est qui qui gagne ?

        Posté par (page perso) . Évalué à 7.

        Je ne suis pas tout à fait d'accord avec toi.

        Quand on veut faire des choses pas trop basiques mais pas trop poussées, Qt a tout ce qu'il faut (réseau, gestion des images, construction de projets) que n'a pas Gtk.

        Alors autant sous linux, ça ne pose aucun problème(on a tout la possibilité rapide d'installer un truc qui manque), sous windows...comment dire... c'est plus sioux (je me perds dans les numéros de versions, les bibliothèques à rajouter etc.)

        Donc si le seul argument c'est "on va gagner de la place...", il n'est pas bon. Pour tes segfault... je n'ai jamais eu ce problème, les sorties étaient toujours très propres et verbeuses pile comme il fallait.

        A près tout dépend de ce qu'on veut... si on veut un truc joli sous linux et moche sous windows (inexistant sous Mac OS ??) ou si on veut un truc joli partout...

      • [^] # Re: et côté facilité de développement ? c'est qui qui gagne ?

        Posté par . Évalué à 1.

        meilleure gestion des erreurs (avec PyQt, j'ai eu plusieurs problèmes conduisant à des "Segfaults", alors qu'avec GTK j'obtiens au pire des erreurs Python qui me génèrent un message d'erreur approprié facilitant le débogage).

        C'est le truc que j'adore le plus dans Python. Souvent les erreurs me suffisent pour corriger mes programmes.

        PyQt inclut aussi de nombreuses librairies Qt qui n'ont pas directement à voir avec l'interface graphique, pour gérer le réseau, les chaînes de caractères, les threads,... ces librairies alourdissent l'ensemble et duppliquent des fonctionnalités déjà accessibles en Python via les modules standards

        Ça je m'en doutais bien. Python est « livré avec les piles » et elles suffisent largement d'après ma petite expérience (sauf pour Tkinter qui est trop moche sous Linux. En comparaison, je trouve les applis Gtk - Inkscape, Gimp, etc. - nettement plus esthétiques sous Windows).

        Dernière question : quid du binding PyGtk sous Windows ? Google (ou plutôt Duck Duck Go) ne donnes pas toujours des résultats encourageants. As-tu des retours d'expérience à ce sujet ?

      • [^] # Re: et côté facilité de développement ? c'est qui qui gagne ?

        Posté par . Évalué à 3.

        Pour PyQt peut être que tu devrais regarder du coté de PySide.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # wxQt !

    Posté par (page perso) . Évalué à 0.

    Si tu veux, tu peux créer wxQt : toute la communauté wxWidgets t'en sera reconnaissante, et du coup il sera possible de choisir entre wxQt et wxGTK.
    Et je suppose que ton travail sera utilisable dans plein d'autres langages avec les nombreux bindings de wxWidgets.

  • # Phoenix

    Posté par (page perso) . Évalué à 1.

    byuu, l'auteur de l'émulateur SNES parfait bsnes, a créé une chose semblable appelée Phoenix : http://byuu.org/phoenix/.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.