Bonjour,
Ayant l'habitude de suivre le Planet KDE, je suis tombé sur un billet particulièrement intéressant : GTK+ made Qt.
L'auteur de ce billet propose de recréer une bibliothèque GTK+, mais utilisant au maximum Qt. Telle qu'il la présente, elle n'est pas binairement compatible, mais uniquement du point de vue des sources. Il a déjà des exemples qui tournent, et le travail semble correct.
Par contre, cette bibliothèque n'est pas encore du tout propre, et n'est qu'une ébauche. Toutes les vérifications faites par GTK ne sont pas faites, plein de trucs ne vont pas, etc.
Néanmoins, c'est une idée qui ne peut qu'être applaudie des deux mains, et est peut-être le futur projet libre de l'année. En effet, les promesses de ce genre de bibliothèque sont énormes : enfin des applications GTK parfaitement intégrées à Qt.
La méthode n'est peut-être pas la plus simple (le plus simple aurait été un backend GTK, comme il en existe pour Windows et Mac), mais il faut avouer que l'idée est séduisante, surtout si tout le boulot se fait à la compilation.
Par contre, du côté technique, ça promet d'être difficile. En effet, le C est très facilement utilisé depuis le C++, mais l'inverse est déjà nettement moins facile.
En tous cas, ce binding inattendu est vraiment très prometteur, et on ne peut qu'encourager l'auteur. Si vous connaissez Qt et GTK+, c'est un bon projet auquel participer, déjà rien que pour montrer que ça intéresse des gens.
Parlez-en, une nouvelle aire d'intégration commence peut-être !
Toutes mes félicitations à son auteur.
Journal GTK+ Made Qt : une bonne idée pour KDE
15
jan.
2010
# Un mur en approche
Posté par Laurent A. . Évalué à 6.
Il a des exemples *triviaux* sur un code loin, très loin (selon ses propos), d'être propre.
Chouette...
Ça va être la fête quand il faudra tout mettre sous l'API Gtk/Gdk. D'ailleurs, il commence mal son encapsulation :
QWidget *gtk_window_new(int) { return new QWidget(); }
Il va falloir mettre des pointeurs sur des QWidget dans un code censé utiliser Gtk ? Amusant.
Personnellement, je pense que ce projet va donner lieu à plein de bidouilles pour un résultat médiocre.
« ...est peut-être le futur projet libre de l'année »
C'est surtout qu'il ne passera probablement pas l'année :-/
« Toutes mes félicitations à son auteur. »
Non, franchement pas.
# Toujours dans le même sens
Posté par Anonyme . Évalué à 3.
On voit souvent des postes du type : « How make Qt looks like GTK » mais rarement l'inverse, et ça me saoul. Si je pouvais intégrer mes application GTK dans un environnement ou j'ai principalement du Qt (Un OpenBox où mes 4 uniques applications graphiques sont en Qt) j'utiliserai des appli GTK.
Sinon, on remarque aussi que tout ça n'est qu'une histoire d'intégrisme :þ
Comme on est trolldi : GTK suxx, Qt rox ! (ceci est purement trollesque et ne reflète en rien la réelle pensée de l'auteur).
[^] # Re: Toujours dans le même sens
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Toujours dans le même sens
Posté par Anonyme . Évalué à 1.
Non, je répondais pas directement au journal en fait, je disais juste ce que je ressentais vis à vis de l'intégration des 2 framework.
[^] # Re: Toujours dans le même sens
Posté par BAud (site web personnel) . Évalué à 2.
VLC est passé à Qt, ce qui est bien, ça fonctionne bien avec Gnome en tout cas. N'est-ce-pas un simple souci KDE ? (il est encore 'dredi).
[^] # Re: Toujours dans le même sens
Posté par Sphax . Évalué à 10.
Mais l'inverse n'est pas possible, sauf à utiliser gtk-qt-engine, qui n'est pas fameux, et pas disponible par défaut dans GTK.
C'est ce que je déplore aussi, pourquoi les gens de GTK ne s'occupent pas de reprendre le style Qt quand des applis GTK sont lancés sur KDE ?
Bon évidemment, c'est plus facile à dire qu'à faire, mais je crois que ça plairait à pas mal de gens d'avoir un Firefox ou autres avec un rendu Qt.
Tout ceci prouve bien que Qt > GTK+ au final.
[^] # Re: Toujours dans le même sens
Posté par zebra3 . Évalué à -1.
Non. Si personne ne prend la peine de faire ça, ça prouve juste qu'il y a suffisamment d'applis en GTK pour ne pas avoir besoin d'applis en Qt, et qu'on peut avoir des environnements full-GTK.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Toujours dans le même sens
Posté par claudex . Évalué à 4.
« 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: Toujours dans le même sens
Posté par suJeSelS . Évalué à -10.
[^] # Re: Toujours dans le même sens
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
[^] # Re: Toujours dans le même sens
Posté par suJeSelS . Évalué à 2.
[^] # Re: Toujours dans le même sens
Posté par Aldoo . Évalué à 5.
[^] # Re: Toujours dans le même sens
Posté par Anonyme . Évalué à 3.
Par contre Qt là, oui.
/me →[]
[^] # Re: Toujours dans le même sens
Posté par GeneralZod . Évalué à 10.
Très peu de personnes sont payés pour travailler à temps plein sur Gtk+ (à ma connaissance, aucun actuellement).
QGtkStyle a été écrit courant 2008 et intégré dans Qt 4.5 (printemps 2009), c'est relativement récent l'intégration visuelle digne de ce nom dans un environnement basé Gtk+.
Puis, il manque pas mal de choses pour qu'une application Qt s'intégre parfaitement, par exemple, pouvoir utiliser les jeux d'icônes standard (c'est prévu pour Qt 4.7 il me semble), la disposition des labels dans les menus etc ...
Certes, de gros efforts ont été mené pour faciliter l'intégration de Qt dans les bureaux natifs (pas que GNOME, mais également Windows et OS X) mais principalement de la part de Nokia/Qt, pas des développeurs KDE (non affilié à Nokia s'entends).
C'est un peu trop facile de taper sur un Gtk+ qui est très loin d'avoir les mêmes ressources que Qt.
----
Pour revenir sur le sujet du journal, j'ai l'impression qu'on n'a pas compris l'objectif de Jonathan Thelin. D'abord Jonathan Thelin est un expert Qt reconnu (auteur du tutoriel indépendant de Qt, du bouquin "Foundations of Qt Development" *LE* meilleur bouquin d'initiation à Qt) et spécialiste de l'embarqué.
C'est avant tout une expérimentation, pas un projet bien défini. Plutôt que de permettre l'intégration des application Gtk+ à un environnement Qt (pas très réaliste, un moteur de rendu à gtk-qt-engine aurait plus approprié), ce serait surtout un kit de transition pour porter des applications Gtk+ vers un environnement Qt (sans Gtk+, sans X11 etc ...).
L'un des axes de développement de Qt est l'embarqué notamment la téléphonie mobile, entre Maemo qui va passer d'un environnement basé sur GNOME Mobile vers un environnement basé sur Qt.
J'ai bien souligné que Jonathan Thelin était un spécialiste de l'embarqué, maintenant à vous d'en tirer les conclusions sur l'intérêt de cette expérimentation.
[^] # Re: Toujours dans le même sens
Posté par Zenitram (site web personnel) . Évalué à 5.
Tu parles des causes, le reste des commentaires parlent du résultat.
Perso, je m'en fou de la cause, c'est le problème de l'équipe GTK+ si ils n'ont pas réussi (ou voulu) à trouver un financement.
Moi, je constate juste que Qt fait un effort pour offrir un SDK qui me permet d'offrir une UI homogène aux utilisateurs KDE, Gnome, Windows, Mac OS X (et autres)., et que côté GTK l'UI est homogène que pour les utilisateurs Gnome (bon, ajoutons Windows à moitié, puisque que GTK n'utilise pas les boites de dialogue native, et il faut mettre un thème GTK-Wimp. GTK sous Mac j'avoue ne pas savoir)
Resultat : Qt 4 (+ les mobiles), GTK 1.5 (modulo Mac), résultat net.
C'est aussi une différence de philosophie : l'un fait énormément pour s'intégrer à l'OS, l'autre fait "juste" le nécessaire pour que ça compile sur un OS donné qui n'est pas Gnome.
Bref, je comprend la cause, mais ça n'empêche pas que ce qui compte, c'est le résultat, le fait de ne pas avoir x développeurs sur cette partie est un "choix" (avec les contraintes) des développeurs, l'un a su trouver un modèle qui permet le développement, pas l'autre. Je suis bien conscient que ce n'est pas facile (WxWidgets est dans la même situation, il n'évolue plus), que Qt a eu la "chance" d'avoir un gros acheteur intéressé, mais ça fait aussi partie des conséquences des choix faits (est-ce que le copyright de GTK pourrai être revendu à une grosse boite? Il me semble que non, chaque contributeur gardant son copyright, mais pour Qt si, c'était un choix de l'entreprise derrière...)
Et ensuite, finalement, il ne reste peut-être de la place que pour un toolkit graphique multi-OS, et GTK redeviendra alors peut-être que le tookit natif de Gnome... Et ceux souhaitant que l'utilisateur ai une UI homogène choisiront Qt, la seule solution réellement bonne pour les gens qui veulent que l'utilisateur ai son UI et pas celle d'un autre OS que celui de l'utilisateur.
[^] # Re: Toujours dans le même sens
Posté par GeneralZod . Évalué à 7.
Gtk+ est un projet communautaire maintenu par des volontaires, Qt était un framework propriétaire qui s'est progressivement ouvert mais qui est très largement maintenu par une seule société. Dès le départ, le modèle de développement/économique n'était pas le même (bazar vs cathédrale).
Oui, Nokia/Qt fait plus d'efforts que Gtk+ mais ils ont plus de moyens, ce n'est pas de la 'mauvaise volonté' de la part des développeurs Gtk+.
Dans ce fil, on donne l'impression que KDE fait des efforts pour s'intégrer dans un environnement GNOME et que ce n'est pas réciproque.
KDE != Qt, KDE est un simple "utilisateur" de Qt, KDE ne participe peu (ou pas) au développement de Qt (à l'exception de Phonon), KDE n'a rien à voir avec les efforts d'intégration mené par Nokia. Une application KDE ne s'intégrera pas mieux à GNOME qu'une application GNOME à KDE, par défaut une application KDE n'utilise pas le thème par défaut de Gtk+ (donc pas de QGtkStyle).
Hormis le look, une application Qt n'est pas mieux intégré dans un environnement KDE que dans un environnement GNOME. Quant au feel d'une application Qt "vanilla", sans travail d'intégration, il sera tout aussi étranger sur bureau KDE que sur GNOME.
Si on commence à regarder sur FreeDesktop, on constate que GNOME fait beaucoup plus d'efforts que KDE pour favoriser l'interopérabilité en étant force de proposition, en implémentant les specs de façon la plus neutre possible (dbus, xdg, *Kit, etc...).
Qt fasse plus d'efforts certes, mais KDE bof bof.
[^] # Re: Toujours dans le même sens
Posté par Zenitram (site web personnel) . Évalué à 4.
Quand on veut arriver à une cible donnée, il faut faire des choix. De ce que je vois, les développeurs GTK ne sont pas prêts à faire les choix nécessaires, ce n'est certes pas forcement de la "mauvaise volonté", mais ce n'est pas non plus la "volonté d'aller dans cette direction à tous prix et donc on cherche un moyen d'y arriver". Encore une fois, je regarde le résultat, ce qui est fait (ou ce qui va être fait : je n'ai jamais lu que GTK allait mettre des moyens dans cette direction même dans le futur)
Dans ce fil, on donne l'impression que KDE fait des efforts pour s'intégrer dans un environnement GNOME et que ce n'est pas réciproque.
Je n'ai pas l'impression qu'on parle de KDE.
On parle de Qt qui s'intègre mieux a KDE et Gnome que GTK, qui ne s'intègre bien qu'à Gnome, et on lance la pierre à GTK.
Ou as-tu vu "impression que KDE fait des efforts " --> Qt fait des efforts, on parle de Qt!
Quant au feel d'une application Qt "vanilla", sans travail d'intégration, il sera tout aussi étranger sur bureau KDE que sur GNOME.
Permet-moi d'en douter : je travaillais avant avec WxWidgets (donc GTK en dessous), mon appli allait très bien sous Gnome et horrible sous KDE, maintenant, je passe à Qt, et ça passe très bien sous Gnome, l'intégration Qt a l'air d'être relativement aléatoire suivant la distro, mais ce n'est pas Qt qui pose problème, "juste" la façon dont la distro l'a intégré : sur je ne sais plus lesquelles de distro, faudrait que je reteste, je développe en Qt sans rien faire de plus, et quand je lance l'appli elle a le style Gnome (pour les autres distros, si je me souviens bien, il faut que je force le thème, c'est juste un paramètre à ajouter à la ligne de commande lancée).
De la même manière, si je demande à GTK d'ouvrir la boite de dialogue d'ouverture de fichier, GTK affiche sa boite quel que soit l'OS, alors que Qt communique avec l'OS pour afficher la boite de dialogue de l'OS.
Bref, niveau intégration, ça va avec Qt mieux qu'avec GTK.
Hormis le look, une application Qt n'est pas mieux intégré dans un environnement KDE que dans un environnement GNOME
A quoi penses-tu? Parce que Qt a pas mal de fonctions qui lissent les différences quand même...
Qt fasse plus d'efforts certes, mais KDE bof bof.
On parle de Qt depuis le début : Qt vs GTK. On ne parle pas de d'environnements de bureau, mais de toolkits! Pas la peine de tout mélanger en y ajoutant les gestionnaires de bureaux dans la partie "dev", laissons dans la partie "UI cible" : le bilan est la, Qt gère Gnome/KDE/Mac OS X/Windows, GTK gère Gnome et c'est tout.
[^] # Re: Toujours dans le même sens
Posté par Gof (site web personnel) . Évalué à 1.
Peut importe qui développe et comment c'est développer, quand on regarde le résultat final, il semble que l'un est meilleur que l'autre. En plus tous les deux sont libre.
Quelque précisions:
- Qt permet d'utiliser le jeux d'icône standard depuis Qt 4.6 http://doc.trolltech.com/4.6/qicon.html#fromTheme
- La disposition des labels et des icônes dans les menu Qt suit les préférences que KDE ou de GNOME en fonction du bureau
- Les développeur Gtk+ principaux sont tout de même payé pour leur travail par des entreprises comme RedHat ou Novell. (Ils sont certes moins nombreux que les développeurs Qt)
[^] # Re: Toujours dans le même sens
Posté par thedude . Évalué à 1.
Ca utilise x11, c'est une horreur, tu peux pas faire pire niveau integration, meme un windows dans vmware en seamless est mieux.
Ya l'air d'avoir un projet de port pour macos, mais c'est pas encore fini.
Ca avance cela dit, ya pas si longtemps que ca, c'etait x11 ou creve.
[^] # Re: Toujours dans le même sens
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Toujours dans le même sens
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Toujours dans le même sens
Posté par 태 (site web personnel) . Évalué à 1.
Gnucash : http://gtk-osx.sourceforge.net/images/Gnucash-Mac%20Quartz%2(...) et des instructions pour le compiler : http://wiki.gnucash.org/wiki/MacOSX/Quartz .
Bref, ça fait 42 ans que c'est en développement et 3 que c'est utilisable...
[^] # Re: Toujours dans le même sens
Posté par benoar . Évalué à 0.
Franchement, là, tu fais moraliste à deux balles, quelque chose que tu dénonces dès que quelqu'un te fais le coup ... Si t'es pas content, code le. En attendant, moi et une bonne partie des utilisateurs sont très contents comme ça.
[^] # Re: Toujours dans le même sens
Posté par grid . Évalué à 9.
GTK a le soutien de Novell, Sun... bref, les sociétés qui trouvaient que la GPL de Qt n'était pas assez libre pour faire du proprio. Ils préféraient la LGPL
[^] # Re: Toujours dans le même sens
Posté par guppy . Évalué à -1.
http://qt.nokia.com/about/news/lgpl-license-option-added-to-(...)
Qt est dispo sous LGPL depuis début 2009.
[^] # Re: Toujours dans le même sens
Posté par claudex . Évalué à 3.
« 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: Toujours dans le même sens
Posté par Zenitram (site web personnel) . Évalué à 3.
Je comprend pour un vieux projet qui a déjà du code écrit pour un toolkit, mais si je regarde maintenant pour un nouveau projet, je ne vois pas pourquoi je devrait prendre en compte un argument qui n'est plus valide : Qt est LGPL maintenant et GTK+ n'est pas intégré à KDE maintenant.
[^] # Re: Toujours dans le même sens
Posté par claudex . Évalué à 2.
« 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: Toujours dans le même sens
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Mais soit dit en passant, l'uniformité de l'apparence des logiciels, si c'est très important, la majorité des gens s'en moquent éperdument, ou du moins, acceptent sans trop râler qu'elle ne soit à peu près inexistante. Il suffit de voir quelqu'un utiliser Windows Internet Explorer, Window Media Player, iTunes et Microsoft Office : rien n'a le même aspect.
[^] # Re: Toujours dans le même sens
Posté par claudex . Évalué à 3.
« 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: Toujours dans le même sens
Posté par NickNolte . Évalué à 1.
Il aurait pu créer un théme par défaut à la compilation, là dans l'état ce sont toutes les valeurs à zéro et c'est clairement moche!
Donc que toutes les applis se ressemblent... pas nécessairement.
[^] # Re: Toujours dans le même sens
Posté par Albert_ . Évalué à 1.
[^] # Re: Toujours dans le même sens
Posté par thedude . Évalué à 1.
Le seul truc dans son ui qui n'est pas "par defaut" c'est les scrollbars (et encore, a verifier, mais je serais surpris que ca ne soit pas juste un style de scrollbar).
[^] # Re: Toujours dans le même sens
Posté par Dr BG . Évalué à 2.
[^] # Re: Toujours dans le même sens
Posté par thedude . Évalué à 1.
'fin entre ca, et une utilisation du scroller fourni par cocoa, on est loin de "completement a cote de la plaque"...
Autant, vous m'auriez parle d'imovie ou idvd, j'aurais pas dit, mais la pour le coup...
[^] # Re: Toujours dans le même sens
Posté par zebra3 . Évalué à -5.
Personnellement, je n'utilise aucune application en Qt, j'ai trouvé mon bonheur pour chaque besoin en GTK. Le seul point qui a manqué pendant des années, c'était la gravure de CD, mais maintenant que Brasero a intégré GNOME, plus besoin de Qt.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Toujours dans le même sens
Posté par claudex . Évalué à 3.
« 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: Toujours dans le même sens
Posté par Anonyme . Évalué à 6.
Le jour où on pourra, dans une application comme GTKChTheme mettre : « style Qt » (comme dans QtConfig en fait), là je commencerai à regarder les appli GTK. À l'heure actuelle, j'utilise pas d'appli GTK, sauf pour tester et sauf quand y a rien d'autre.
Encore une fois comme dit dans mon poste en haut : ça marche que dans un sens : Qt DOIT ressembler à GTK, et chez GTK, eux ils s'en foutent (y a qu'à voir : QGTKStyle, gtk-qt-engine, les postes sur les boards GNUx : « Make GTK looks like Qt » etc.).
# Quelle est sa superficie?
Posté par NickNolte . Évalué à 10.
Parlez-en, une nouvelle aire d'intégration commence peut-être !J'éspère que cette ère commencera le plus tôt possible!
[^] # Re: Quelle est sa superficie?
Posté par Maclag . Évalué à 8.
------------> [ ]
[^] # Re: Quelle est sa superficie?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
# C'est compliqué c't'affaire.
Posté par téthis . Évalué à -10.
Ah... on n'est déjà plus trolldi.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: C'est compliqué c't'affaire.
Posté par HoloAddict (site web personnel) . Évalué à 8.
désolé, c'était vendredi...
[^] # Design de l'application
Posté par cppuser . Évalué à -4.
je peux me tromper mais wxWidgets continue d'évoluer et offre le look natif du système sur lequel on travaille (certes GTK+ sous linux). J'ai du mal à voir l'intérêt de GTK+ car la documentation est bien loin du niveau de celle de wxWidgets ou Qt. Certes Qt soutenu par une société tirera certainement mieux son épingle du jeu (et le fait déjà) que wxWidgets. Je ne comprends spécialement l'intérêt d'être passé en Qt pour VLC, on n'a pas forcément gagné ou perdu au change.
Lorsque je regarde les API (systèmes, machine virtuelle...) qui ont fonctionné ou fonctionne (java, C#), elles fonctionnent car elles offrent un même code pour tous les systèmes. Pourquoi wxWidets, Qt qui sont sur le même créneau sur les 3 principaux systèmes mais en natif donc plus performant n'ont pas su s'imposer j'ai un peu de mal à comprende (certainement le C++). En ce qui me concerne je trouve que le principal c'est la documentation puis la bibliothèque et à ce niveau j'ai toujours eu du mal avec GTK. Et ce n'est pas un troll :-)
Bonne fin de journée
PS à part GIMP de connu qui utilise GTK sur linux/windows, wxWidgets lui a Audacity, Amaya, CodeBlocks...mais visiblement cela ne suffit pas puisque j'ai l'impression que : Ouf VLC est passé en Qt :-)
[^] # Re: Design de l'application
Posté par claudex . Évalué à 3.
Qt a quand même bien su s'imposer. Je suis pas sûr qu'il y ait autant d'applications (pour desktop, sinon ça sert à rien de comparer) fort distribuées en Java: http://qt.nokia.com/qt-in-use/target/qt-in-use/target/deskto(...) http://qt.nokia.com/qt-in-use
« 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: Design de l'application
Posté par cppuser . Évalué à -4.
je parlais naturellement des applications hors KDE et hors linux, plutôt sur les applications sur Microsoft Windows, c'est à dire sur le système qui (hélas) est le plus utilisé sur des ordinateurs de bureau.
Bonne soirée
[^] # Re: Design de l'application
Posté par claudex . Évalué à 2.
« 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: Design de l'application
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Design de l'application
Posté par claudex . Évalué à 2.
« 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: Design de l'application
Posté par 태 (site web personnel) . Évalué à 3.
[^] # Re: Design de l'application
Posté par Zenitram (site web personnel) . Évalué à 4.
Oui, j'aimai bien cette idée. Malheureusement l' "offre" n'a pas suivie. WxWidgets n'offre pas assez de choses par rapport à Qt, sans compter que le port Mac est à l'arrache (j'ai abandonné WxWidgets quand j'ai vu toutes les merdes graphiques sous Mac, et la version Cocoa n'est pas près d'être stable).
WxWidgets était une bonne idée au départ, sur le principe je le préfère à Qt car Qt "copie" l'interface de l'OS hôte, mais n'utilise pas forcement le toolkit natif et c'est chiant (en plus d'être volumineux). Malheureusement, ça na pas suivit ensuite face au rouleau compresseur Qt qui offre bien plus de Widgets, d'aide à la construction du GUI.
(certes GTK+ sous linux)
Ce qui pose un problème, cf les autres commentaires : WxWidgets utilisant GTK+, il en prend les défauts donc pas d'intégration dans KDE. 1 point en moins.
Je ne comprends spécialement l'intérêt d'être passé en Qt pour VLC, on n'a pas forcément gagné ou perdu au change.
Toi, tu n'as pas assez programmé en WxWidgets pour dire ça...
[^] # Re: Design de l'application
Posté par cppuser . Évalué à -2.
bien si mais pas forcément en Qt, et sauf erreur de ma part, celui qui a "repris" VLC programmait en Qt du coup le portable.
Je suis d'accord sur le fait que l'avenir de wxWidgets est moins "rose" depuis que Qt est passé en LGPL car Qt offre plus de choses, et va plus vite car c'est développé par une entreprise+KDE aussi. Pour l'aide à la construction wxFormbuilder est pas trop mal (mais j'ai pas testé il est vrai du côté de Qt). Et le port de python pour Qt il est comment ?
# Design de l'application (en commentaire cette fois-ci)
Posté par cppuser . Évalué à -3.
je peux me tromper mais wxWidgets continue d'évoluer et offre le look natif du système sur lequel on travaille (certes GTK+ sous linux). J'ai du mal à voir l'intérêt de GTK+ car la documentation est bien loin du niveau de celle de wxWidgets ou Qt. Certes Qt soutenu par une société tirera certainement mieux son épingle du jeu (et le fait déjà) que wxWidgets. Je ne comprends spécialement l'intérêt d'être passé en Qt pour VLC, on n'a pas forcément gagné ou perdu au change.
Lorsque je regarde les API (systèmes, machine virtuelle...) qui ont fonctionné ou fonctionne (java, C#), elles fonctionnent car elles offrent un même code pour tous les systèmes. Pourquoi wxWidets, Qt qui sont sur le même créneau sur les 3 principaux systèmes mais en natif donc plus performant n'ont pas su s'imposer j'ai un peu de mal à comprende (certainement le C++). En ce qui me concerne je trouve que le principal c'est la documentation puis la bibliothèque et à ce niveau j'ai toujours eu du mal avec GTK. Et ce n'est pas un troll :-)
Bonne fin de journée
PS à part GIMP de connu qui utilise GTK sur linux/windows, wxWidgets lui a Audacity, Amaya, CodeBlocks...mais visiblement cela ne suffit pas puisque j'ai l'impression que : Ouf VLC est passé en Qt :-)
[^] # Re: Design de l'application (en commentaire cette fois-ci)
Posté par janine . Évalué à 4.
Pidgin, Inkscape, GVim pour ceux que j'ai utilisé
En ce qui concerne la documentation de GTK c'est un reproche que j'ai vu plusieurs fois et que je comprend pas. Es ce que quelqu'un pourrait donner plus de détails sur ce qui ne va pas avec ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# documentation GTK
Posté par cppuser . Évalué à 0.
C'est vrai que pour les applications certaines ont été depuis portées sur windows mais il y en a moins que wxWidgets je trouve on peut rajouter kicad, wxMaxima, digsby, filezilla....
Pour la documentation GTK, j'avais essayé de rajouter des fonctionnalités à wxWidgets version linux, mais j'avais laissé tomber pour certaines car je trouvais qu'il n'y avait pas assez d'explications sur GTK (attention il s'agissait de faire des éléments un peu plus techniques que ceux de base qui existent déjà sur wxWidgets). Le plus simple serait de voir ce qu'il y a sur wxWidgets (doc+livre en pdf), je trouve que c'est beaucoup plus clair à tous niveaux. Les informations sont certainement là aussi sur GTK mais j'avais eu plus de mal à les trouver (sans parler des "cast" entre GDK, GTK...), plus simple sur wxWidgets (désolé c'est ce que j'utilise). Ce que j'avais testé sur Qt m'avait demandé aussi beaucoup moins de temps que pour la même chose sur GTK. J'avais le sentiment que la doc GTK c'était juste l'API sortie avec docoxygen. Voilà mon ressenti, pas forcément complètement objectif.
A+
[^] # Re: documentation GTK
Posté par Troy McClure (site web personnel) . Évalué à 2.
C'est sur que gtk gagnerait pas mal à avoir une doc digne de ce nom. ALSA aussi d'ailleurs.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.