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 GeneralZod . É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 tuxicoman (site web personnel) . É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 CrEv (site web personnel) . É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 liberforce (site web personnel) . É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 Troy McClure (site web personnel) . É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 erdnaxeli (site web personnel) . Évalué à 2.
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 phoenix (site web personnel) . É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 JPEC . É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 fredix . É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 kursus_hc . Évalué à 10.
Merci, c'est ce qu'on se tue à vous dire depuis deux ans !!
[^] # Re: Qt
Posté par bubar🦥 (site web personnel) . Évalué à 10.
Menteur ! y a deux ans on était en 2009 !
[^] # Re: Qt
Posté par Frank-N-Furter . Évalué à 10.
La preuve que KDE est plus avancé.
Depending on the time of day, the French go either way.
[^] # Re: Qt
Posté par Niniryoku . Évalué à 2.
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 fredix . É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 fredix . Évalué à 5.
En fait c'est une simple option à cocher dans les options de Dolphin.
[^] # Re: Qt
Posté par gnumdk (site web personnel) . Évalué à 4.
kdemultimedia-ffmpegthumbs
[^] # Re: Qt
Posté par Lutin . É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 totof2000 . Évalué à 3.
Moi, c'est l'agenda KDE qui m'a convaincu : rien trouvé de tel sous Gnome.
# Rajouter une couche
Posté par Jux (site web personnel) . É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 GeneralZod . É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) !
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)
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 gnumdk (site web personnel) . É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 GeneralZod . É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 gnumdk (site web personnel) . É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 gnumdk (site web personnel) . Évalué à 4.
justifiés à droite ...
[^] # Re: Rajouter une couche
Posté par zerkman (site web personnel) . Évalué à -9.
Un peu comme Qt sous Linux ?
[^] # Re: Rajouter une couche
Posté par BFG . Évalué à 5.
Vous avez un exemple de ce que vous avancez ?
[^] # Re: Rajouter une couche
Posté par zerkman (site web personnel) . É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 leolio . Évalué à 3.
Pour changer le thème, tu peux utiliser qtconfig (pas besoin de KDE).
[^] # Re: Rajouter une couche
Posté par BFG . Évalué à 2.
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 totof2000 . É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 claudex . É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 totof2000 . É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 claudex . Évalué à 2.
C'est dommage pour un soft en java.
« 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 totof2000 . Évalué à 2.
StarUML n'est pas écrit en Java.
http://staruml.sourceforge.net/en/development-setting.php
Par contre j'ai tenté de faire fonctionner un autre soft de modélisation UML (OpenModelSphère) sous NetBSD, qui lui est écrit en Java, mais ça n'a jamais marché (j'avais d'ailleurs ralé ici même). Comme quoi la pseudo-portabilité de Java ....
[^] # Re: Rajouter une couche
Posté par totof2000 . Évalué à 2.
Par contre j'ai tenté de faire fonctionner un autre soft de modélisation UML (OpenModelSphère) sous NetBSD, qui lui est écrit en Java
Oups, désolé, j'ai posté un peu vite : je précise que c'est le soft OpenModelSphère qui est écrit en Java, pas NetBSD (ma phrase prête à confusion).
[^] # Re: Rajouter une couche
Posté par claudex . Évalué à 2.
Bizarre d'avoir des noms de fichiers en .java alors.
« 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 totof2000 . Évalué à 2.
La roadmap indique que le soft est compatible avec Eclipse, peut-être des modules pour Eclipse Sinon c'est peut-être le "Porting to multi-platform (.NET, Linux, Mac, ...) " de la roadmap ?
[^] # Re: Rajouter une couche
Posté par claudex . Évalué à 2.
Sans doute, je n'ai quand même pas eu de chance de tomber sur eux par hasard.
« 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 houra . Évalué à 2.
peut être que ça peut aider ?
http://www.developpez.net/forums/d606087/autres-langages/pascal/lazarus/conversion-projets-delphi-lazarus-linux/
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Rajouter une couche
Posté par zebra3 . É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 Paul . É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 coïn . É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 GeneralZod . Évalué à 4.
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 TortuXm . É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 Gof (site web personnel) . Évalué à 0.
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 gnumdk (site web personnel) . É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 Paul . É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 totof2000 . Évalué à 2.
Tu as vu quel jour il poste ?
# choisir
Posté par coïn . É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 Philippe M (site web personnel) . É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 Paul . É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 GeneralZod . Évalué à 10.
Une bonne conception, tu sépares le coeur de l'application de son interface utilisateur.
[^] # Re: À l'heure actuelle ?
Posté par Philippe M (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 6.
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 Jux (site web personnel) . É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 Alexandre COLLIGNON (site web personnel) . É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 Fabien Chaillou . É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 bubar🦥 (site web personnel) . É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 CrEv (site web personnel) . Évalué à 3.
Tout ça parce que demain c'est trolldi...
# XUL
Posté par Sonny Piers . É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 marahi . É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 Jiba (site web personnel) . É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 djibb (site web personnel) . É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 marahi . Évalué à 1.
C'est le truc que j'adore le plus dans Python. Souvent les erreurs me suffisent pour corriger mes programmes.
Ç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 Cédric Krier (site web personnel) . Évalué à 1.
Depuis peu, Gnome propose un installeur "all-in-one" pour pygtk. Ça simplifie grandement l'installation.
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.24/
[^] # Re: et côté facilité de développement ? c'est qui qui gagne ?
Posté par barmic . É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 palkeo (site web personnel) . É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 Kekun (site web personnel, Mastodon) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.