Quelle bibliothèque pour du GUI ?

Citation:

---

Envoyé par epsilon68

MAT007 tu pourrais nous dire les problemes que tu rencontres au jour le jour dans l'utilisation de Qt?

---

C'est pas vraiment des problèmes, en tous cas rien d'insurmontable, c'est surtout un fort sentiment de lutter constamment contre Qt.
Par exemple ce que dit MonGaulois sur qmake me fait bien halluciner, moi il est hors de question d'avoir un système de build imposé par une bibliothèque...

Je trouve que c'est comme ça pour un peu tout, Qt impose tout le temps plein de trucs, en général à l'encontre de la philosophie de la communauté C++ type boost.
Et des fois ça coince et je passe 1/2 journée à essayer de remanier les créations/destructions et à forcer plein de delete manuels des composants dans les destructeurs de leurs parents parce que le modèle de gestion n'est pas vraiment compatible avec la manière dont on fait le reste (bon c'est aussi que les applications graphiques sont considérées comme pas importantes là où je travaille et que tout le monde fait ça à l'arrache, ça n'aide pas).

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

MAT.

Citation:

---

Envoyé par Mat007

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

---

+1

Citation:

---

Envoyé par Mat007

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

---

Justement je trouve que c'est plutot un avantage certain.
par example le module SQL est tres pratique et s'integre parfaitement avec le reste du code, pareil pour le XML, pareil pour le Concurrent etc...

moi je n'utilise que qmake, j'aime vraiment bien cet outil, simple et puissant.

et la doc de Qt est un vrai plaisir :-)

Citation:

---

Envoyé par Mat007

Par exemple ce que dit MonGaulois sur qmake me fait bien halluciner, moi il est hors de question d'avoir un système de build imposé par une bibliothèque...

---

Tu n'as aucune obligation, c'est juste un outils qu'il t'offre pour te simplifier la vie. Tu peut très bien utiliser d'autre générateur de makefile ou faire "à la main". SCONS, CMAKE et autre gère Qt. moc et uic ne sont que des générateurs de code. Rien de plus.

Code:

---

Je trouve que c'est comme ça pour un peu tout, Qt impose tout le temps plein de trucs, en général à l'encontre de la philosophie de la communauté C++ type boost.

---

:koi:
comme????

Citation:

---

Et des fois ça coince et je passe 1/2 journée à essayer de remanier les créations/destructions et à forcer plein de delete manuels des composants dans les destructeurs de leurs parents parce que le modèle de gestion n'est pas vraiment compatible avec la manière dont on fait le reste

---

Ben si tu peut sans problème utiliser des delete. Tu peut aussi spécifier la destruction lorsqu'une widget est fermé avec l'attribut :
Qt::WA_DeleteOnClose
J'ai plus l'impression que ton problème est que tes traitements sont mélangés avec ton ihm

Je ne cherche pas à défendre Qt. Mais à être objectif.

Citation:

---

Envoyé par dtrosset

Citation:

---

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

---

+1

---

:koi:
GTK et WxWidget sont aussi gros!!! quasiment les même fonctionnalités!!! avec de ce que j'ai vue beaucoup plus de dépendance que Qt!!!
Boost est bien plus gros!

Je ne voie pas ce que vous voulez dire.

Personnellement j'ai utilisé wxWidgets par le passé (quand je dis par le passé, c'est que ça fait longtemps que je n'ai pas eu à faire d'ihm).
Sur le papier ça me semble excellent, c'est juste une surcouche de la lib graphique native du système (MSW, Mac, GTK, …) avec une API commune. D'ailleurs le poids des DLL et la facilité de déploiement s'en ressentent.
Par contre, en pratique je dois dire que je n'aime pas trop l'API :

• Système de gestion d'évènements particulièrement cradingue à base d'enums et de macro
• Ils n'ont pas l'air de savoir ce qu'est un namespace
• Utilisation obligatoire de l'allocation dynamique pour les objets graphiques
• le main() n'est pas accessible (utilisation forcée d'une macro qui l'implémente)

Mais bon, ça fait très bien ce qu'on lui demande et on est pas trop « envahi » par cette lib (si ce n'est la class wxString et les _T"" qui vont avec). Comme il a été dit, ce n'est pas un framework mais une bibliothèque seulement. Même si ils fournissent une lib de gestion des threads (merdique, de mémoire) et d'autres trucs du même acabit, tout cela n'est pas lié aux composants graphiques.


Qt, je ne connais pas trop. Je me suis renseigné rapidement dessus, et j'ai fait demi-tour aussi vite que je suis arrivé. Deux gros points noirs rédhibitoires :

• redondances omniprésentes de la STL (qlist et consort)
• et surtout, son utilisation peut mener à du C++ non-standard (d'où le préprocesseur made-in Qt)

Un exemple pour illustrer ce dernier point :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Counter : public QObject { Q_OBJECT   public slots: void setValue(int value);   signals: void valueChanged(int newValue); };

---

Les adorateurs de Qt trouvent ça pratique (et ils doivent avoir raison), mais personnellement, ça me pique les yeux.
L'utilisation forcée de leur préprocesseur n'est pas le seul inconvénient lié au fait que le code ne soit pas standard. Par exemple, allez faire du reverse-engineering là dessus…


Enfin, plus récemment, je me suis attelé à l'utilisation de gtkmm. Je ne l'ai utilisé que sous Linux pour un projet perso pas encore déployé, donc je ne peux pas appuyer ses propos concernant la facilité de déploiement, mais je peux dores et déjà dire que j'ai vraiment l'impression de faire du C++ quand je code avec (ce qui est plutôt drôle étant donné que c'est la seul lib des trois que ne soit qu'un binding du C).
C'est d'ailleurs un des arguments avancés par les dévs de gtkmm eux-mêmes (eux-mêmêmes :D) :

Citation:

---

Envoyé par http://www.gtkmm.org/

(…)
# Type-safe signal handlers, in standard C++.
(…)
# Use of Standard C++ Library, including strings, containers, and iterators.
(…)
# Full use of C++ namespaces.
# No macros.

---

Malheureusement, GTK ne s'intègre pas excellemment bien sous Windows (même si c'est pas tellement hideux). Pour un exemple, installez Wireshark (ex-Ethereal) ou Gimp.


Bref, le graal reste encore à être fait, selon moi.
Un truc avec les mêmes spec que wxWidgets (surcouche portable) avec une qualité de réalisation équivalente à celle de gtkmm, une bonne cohérence avec la STL et qui laisse gérer les trucs style threads, sockets et consort à ceux qui savent faire.

Citation:

---

Envoyé par three minute hero

Qt, je ne connais pas trop. Je me suis renseigné rapidement dessus, et j'ai fait demi-tour aussi vite que je suis arrivé. Deux gros points noirs rédhibitoires :

• redondances omniprésentes de la STL (qlist et consort)

---

C'est surtout qu'il utilise énormément le COW. Ils ont donc recréé leurs conteneur. Et historiquement il me semble que certain compilo avais une mauvaise implémentation de la STL

Citation:

---

Envoyé par three minute hero

• et surtout, son utilisation peut mener à du C++ non-standard (d'où le préprocesseur made-in Qt)

---

Le non-standard s'arrête là. Qt utilise énormément de meta-donné sur les class, en autre pour le les signal/slot.
Le moc est juste là pour simplifier la vie de développeur et surtout pour éviter des macro immonde.
J'avais lue que le moc est aussi une raison historique où il palliais à des manque du C++ de l'époque.

Aprés Qt est vieux, as un historique et une quantité de compilateur à supporter. Ce qui forme un sous-ensemble plutôt critiqué.

Gtkmm est beaucoup plus jeune et semble plus proche du C++ et surtout des compilo récent.

Toute façon toute ces api sont très proches. Au final c'est juste un choix de style de programmation.

humm je pense que le MOC a tout son intérêt quand ils ont besoin de rajouter des choses sans faire appel au programmeur. il permet de retirer l'observation au delete de l'objet par exemple, mais aussi de stoker les informations de l'objet. Avec Qt/Javascript, on voit qu'il faut ce genre d'information sans que ce soit une douleur pour le programmeur.

bref quand tu ne veux pas etre dependant de Qt (je suis aussi d'accord), on se rend malgré tout dependant d'une autre lib

on se dit qu'il ne vaut mieux pas devenir 100% dependant de Qt donc on se rajoute la maintenance de plusieurs libs (par ex. libxml2, soci++,etc)

par contre bienvenu dans le cauchemard de la maintenance des multiples libraries et de l'interface entre librairies. Maintenant je ne peux honnetement pas assumer tout seul la maintenance de toutes ces couches... avec Qt je peux au moins avancer dans mon produit, et me concentrer sur les fonctionnalités plutot que dans les couches d'abstractions de plusieurs lib et dependances.

au final de toute facon, si Qt est abandonné, bein ca reviendrait dans 90% des cas a refaire l'appli en la reconstruisant avec les bout de codes, composants qu'on pourrait reutiliser... On serait de toute facon dans le meme ordre de grandeur de difficulté.

Ce ne sont que des compromis, ou le temps de developpement joue un role essentiel.

ok petite question sur gtkmm
me basent sur ce que je fait avec mes librairies. a savoir faire des librairie statique ou dynamique.
et t il possible sans m arracher le peu de cheveux qui me reste :lol: de faire un executable qui contiendrai tout les librairie (de gtkmm et autre gui )dont j aurai besoin pour mon application pour ne pas avoir a installer gtk a chaque fois que je le fait tourner sur une autre machine ??

Citation:

---

Envoyé par epsilon68

h
au final de toute facon, si Qt est abandonné, bein ca reviendrait dans 90% des cas a refaire l'appli en la reconstruisant avec les bout de codes, composants qu'on pourrait reutiliser...

---

Pas la peine, le deale fait avec KDE est qu'il récupèrerons tout les droit si quelque chose comme cela arrivais ;)
Donc Qt ne risque pas de disparaitre :P

Citation:

---

Envoyé par Mongaulois

Pas la peine, le deale fait avec KDE est qu'il récupèrerons tout les droit si quelque chose comme cela arrivais ;)
Donc Qt ne risque pas de disparaitre :P

---

cela ne concerne que Qt/X11 si je me rappelle bien :-)

Citation:

---

Envoyé par epsilon68

cela ne concerne que Qt/X11 si je me rappelle bien :-)

---

Ben ils parlent des dernière sources donc les autres OS sont inclus dedans, non?
Puis Maintenant Que Qt est en GPL, n'importe qui peut reprendre en continuer

Citation:

---

Envoyé par Mongaulois

GTK et WxWidget sont aussi gros!!! quasiment les même fonctionnalités!!! avec de ce que j'ai vue beaucoup plus de dépendance que Qt!!!
Boost est bien plus gros!

Je ne voie pas ce que vous voulez dire.

---

C'est pas vraiment une question de volume ou de dépendances mais de philosophie d'utilisation : Qt est plus dans le style à fournir un cadre pour réaliser une application en t'indiquant où et comment personnaliser certaines parties.

Citation:

---

Envoyé par Mongaulois

Tu n'as aucune obligation, c'est juste un outils qu'il t'offre pour te simplifier la vie. Tu peut très bien utiliser d'autre générateur de makefile ou faire "à la main". SCONS, CMAKE et autre gère Qt. moc et uic ne sont que des générateurs de code. Rien de plus.

---

Y'a rien d'obligatoire dans Qt, c'est juste systématiquement la méthode qu'ils conseillent d'utiliser et on a l'impression qu'ils ont un malin plaisir à réinventer la roue à l'opposé de ce qui existe déjà.

Citation:

---

Envoyé par Mongaulois

Citation:

---

Envoyé par Moi

Je trouve que c'est comme ça pour un peu tout, Qt impose tout le temps plein de trucs, en général à l'encontre de la philosophie de la communauté C++ type boost.

---

:koi:
comme????

---

Comme toutes ces choses dans la philosophie Qt qui sont un peu particulières (gestion de la mémoire, signaux, avoir recours à des exécutables pour générer des trucs pour un oui ou un non, etc...) et qui influent sur la manière de l'utiliser (des new partout, une hiérarchie des composants père-fils, etc..).

Je conçois tout à fait que Qt puisse répondre aux besoins de plein de monde, c'est juste que je n'adhère pas à la philosophie...

MAT.

J'aime Qt pour la cohérence de l'ensemble.
J'apprecie qu'ils aient une philosophie et qu'ils s'y tiennent.

Citation:

---

Comme toutes ces choses dans la philosophie Qt qui sont un peu particulières (gestion de la mémoire, signaux,

---

C'est si particulier que cela? je ne pense pas.

Code:

---

avoir recours à des exécutables pour générer des trucs pour un oui ou un non, etc...)

---

Enfin ça s'arrête à l'utilisation pour les connect/source.

Tu peut même te passer du uic en chargeant le .ui dynamiquement (comme glade si je me trompe pas)
Puis c'est pas nouveau des lib qui te fournisse des outils pour générer des bout code :
Bison, adobe.ASL, ...
Je trouve cela propre. Il te permette d'éviter :arf: à cause de subtiliser qui ne nous sert à rien de connaitre

Après, je comprend très bien que cela ne plaise pas à tout le monde. Gtkmm semble plus être dans ta philosophie.

Citation:

---

Envoyé par dtrosset

Et j'ai le même problème avec Python : tkInter, PyQt ou PyWidgets ?

---

Autant j'aime Qt pour son côté C++, et pas wxWidgets, autant sous Python, je préfère wxPython qui a une interface très bien faite à la Python, contrairement à PyQt qui ne ressemble pas à du Python.

En fait ce qu'il manque à wxWidgets c'est... un wrapper C++ :)
Non, sans rire. On peut déjà lancer que wxWidgets n'est pas du C++, mais du C with classes. L'intérêt n'est pas seulement historique vis-à-vis de la compatibilité des compilateurs, il y a aussi le fait que c'est tout aussi facile de créer un wrapper pour cette biblio que pour une biblio C (on ne pourrait pas en dire autant de boost par exemple, swig aime moyennement les templates), c'est ce qui explique qu'on en trouve autant. A partir de la, une surcouche en "vrai" C++ semble être dans la logique des choses.

Perso j'ai essayé d'utiliser une seule fois et ça m'a paru "moins pire" que les anciennes MFC, d'où mon interet.


Par contre le truc d'Adobe a l'air sympas...

Bonjour à tous,
J'ai eu récemment à faire un choix entre QT wxwidget venant du monde majique de Builder C++ et j'ai finit par opter pour QT pour les raisons suivantes:

- C'est super professionnel comparé à wxwidget qui fait bricolage et le C...
- Une enorme communauté sur QT, au moindre probléme j'ai la solution dans l'heure qui suit. Et ca c'est super important.
- Pour les détracteur de qmake, je n'ai jamais eu besoin d'en ecrire un encore moins d'un utiliser un.
- Les moc et Uic, c'est contraigant mais vraiment simple
- Une fois compilé en static QT permet de ne fournir qu'un exe unique.
- par contre effectivement c'est pas donné, compter 5000€

Avec QT ce qui est à mon sens super important et de bien choisir son IDE, c'est ce qui va faire que QT devient super simple ou super compliqué. Et pour ma part au contraire de beaucoup de spécialistes de QT je conseille d'utiliser Qdesigner qui fournit une interface vraiment commode au developement de GUI

Qt et pas QT
:evilred::evilred::evilred::evilred::evilred::evilred:

Citation:

---

Envoyé par uriotcea

- par contre effectivement c'est pas donné, compter 5000€

---

Sachant que cette partie n'est nécessaire que si on développe une application qu'on fournira à quelqu'un à qui le code source doit être caché. En général, c'est inutile.

Moi, j'aime bien wxWidgets 8-)

Ok, c'est parfois moche (pas de namespaces, macros,....) mais tout ça c'est historiques, wxWidgets a été créé pour être le plus portable possible, non seulement du point de vue de l'application mais aussi au niveau du code, c'est à dire vis à vis du compilateur, leur objectif était de créer du code qui compile sur le plus de compilateur possible. Bien sûr, tout ça date un peu, ce qui explique la non utilisation de la STL (qui à l'époque n'était pas supporté par tous les compilateurs à cause des templates), ce qui explique les wxString et autres, ce qui explique aussi le non-utilisation de namespaces.... Évidement, aujourd'hui, tout ça est bien supporté par tous les compilateurs. Donc, ce dont wxWidgets a besoin c'est une ré-adaptation au C++ d'aujourd'hui, après, je pense que ce sera vraiment le graal dont parle three_minute_hero puisque tous les choix qui ont mené à du code moche sont surtout dû à des problèmes de compatibilité.

Citation:

---

Envoyé par lezurp

je n ai pas trouver d'editeur graphique pour wxwidget ( il faut avouer que c ets bien pratique)

---

wxGlade

Après, je rejoins Matthieu Brucher pour wxPython, j'aime bien wxWidgets mais je ne peux me passer de wxPython.

Citation:

---

Envoyé par Matthieu Brucher

Sachant que cette partie n'est nécessaire que si on développe une application qu'on fournira à quelqu'un à qui le code source doit être caché. En général, c'est inutile.

---

Je ne comprend pas bien ta remarque!
Si je veux vrendre mon code, j'ai bien besoin de la licence commercial ?

Sinon pour revenir à wxwidget, l'EDI code::block fournit un editeur graphique.

Citation:

---

Envoyé par uriotcea

Je ne comprend pas bien ta remarque!
Si je veux vrendre mon code, j'ai bien besoin de la licence commercial ?

---

Non, tu peux vendre avec la GPL.
Un exemple, si tu fais du conseil pour une autre entreprise qui veut que tu lui développes une application. De toute manière, tu dois lui donner le code source, donc ça ne te dérange normalement pas que ce soit du GPL (sauf précision contractuelle).

Si je prends ce que tu m'indiques.
Dans le cadre de mon boulot je développe actuellement un code avec interface Qt. Je peut trés bien vendre ce code, même si je l'ai developpé avec le Qt non-commercial, pour peu que je fournisse les sources.

si c'etait possible alors le code source n'appartiendrait pas réellement à l'entreprise... je ne pense donc pas que ce soit possible...

Ce qu'il dit, c'est que tu peux vendre ton code sous licence GPL à ton client. À ce moment là, tu entres dans le cas où Qt est gratuit.
Par contre, si ton client décide de changer la licence (si tu lui vends ce code et les droits qui vont avec) pour une licence propriétaire (s'il souhaite vendre le logiciel sous forme binaire à d'autres entreprises), c'est lui qui va devoir payer la licence Qt.

Le code que je develope est un outil scientifique non destiné à etre revendu. C'est juste que je voudrait faire payer une contribution aux laboratoires qui désire l'avoir et l'utiliser

Citation:

---

Envoyé par Florian Goo

Ce qu'il dit, c'est que tu peux vendre ton code sous licence GPL à ton client. À ce moment là, tu entres dans le cas où Qt est gratuit.
Par contre, si ton client décide de changer la licence (si tu lui vends ce code et les droits qui vont avec) pour une licence propriétaire (s'il souhaite vendre le logiciel sous forme binaire à d'autres entreprises), c'est lui qui va devoir payer la licence Qt.

---

Tu penses que le client qui paye 1 million d'euros voudrait voir son code en GPL? car tu lui delivre en GPL, ce qui veut dire que tu pourrais toi-aussi le revendre à d'autres sociétés... jusqu'a ce qu'il change la license ok mais la version initiale reste en GPL!

Aucun client ne peut accepter cela. En tous les cas pas les miens.

Citation:

---

Envoyé par epsilon68

Tu penses que le client qui paye 1 million d'euros voudrait voir son code en GPL? car tu lui delivre en GPL, ce qui veut dire que tu pourrais toi-aussi le revendre à d'autres sociétés... jusqu'a ce qu'il change la license ok mais la version initiale reste en GPL!

Aucun client ne peut accepter cela. En tous les cas pas les miens.

---

Citation:

---

Envoyé par uriotcea

Le code que je develope est un outil scientifique non destiné à etre revendu. C'est juste que je voudrait faire payer une contribution aux laboratoires qui désire l'avoir et l'utiliser

---

Je vois pas le rapport avec mon besoin

Citation:

---

Envoyé par epsilon68

Tu penses que le client qui paye 1 million d'euros voudrait voir son code en GPL? car tu lui delivre en GPL, ce qui veut dire que tu pourrais toi-aussi le revendre à d'autres sociétés... jusqu'a ce qu'il change la license ok mais la version initiale reste en GPL!

Aucun client ne peut accepter cela. En tous les cas pas les miens.

---

Je suis d'accord, c'est farfelu, mais certains l'ont fait.
La célèbre forge SourceForge, au début libre, s'est vue reprendre (légalement) les droits aux contributeurs. Ils ont ensuite changé la licence. Les évolutions du code de SourceForge sont aujourd'hui propriétaires.
Source : http://www.fsfeurope.org/news/articl...-20-01.fr.html

Ensuite, dans le cas où le logiciel développé est extrêmement spécifique au client, je ne vois pas en quoi il serait farfelu que le code vendu soit GPL (et même qu'il le reste).

Sourceforge a donné un papier à signer pour chaque auteur pour donner leur code à SourceForge.

un code GPL ne peut etre approprié avec un changement de license sauf l'auteur est d'accord ou cède le droit.

Citation:

---

Envoyé par epsilon68

si c'etait possible alors le code source n'appartiendrait pas réellement à l'entreprise... je ne pense donc pas que ce soit possible...

---

Si, il appartient à l'entreprise, elle en fait ce qu'elle veut. Elle est juste liée à Qt pour son utilisation, donc à publier le code en GPL. Par exemple dans mon boulot, on veut simpelemnt pouvoir continuer le développement si besoin est, donc on veut les sources. Après la licence, ce n'est pas un problème.

Citation:

---

Envoyé par Florian Goo

Ce qu'il dit, c'est que tu peux vendre ton code sous licence GPL à ton client. À ce moment là, tu entres dans le cas où Qt est gratuit.
Par contre, si ton client décide de changer la licence (si tu lui vends ce code et les droits qui vont avec) pour une licence propriétaire (s'il souhaite vendre le logiciel sous forme binaire à d'autres entreprises), c'est lui qui va devoir payer la licence Qt.

---

Il ne peut pas changer la licence. C'est indiqué dans le contrat avec Trolltech, si tu veux choisir ta licence à ta guise, tu dois avoir une licence commerciale dès le début du développement. En pratique, les gens enfreignent régulièrement ce point de leur contrat.

Citation:

---

Envoyé par epsilon68

Tu penses que le client qui paye 1 million d'euros voudrait voir son code en GPL? car tu lui delivre en GPL, ce qui veut dire que tu pourrais toi-aussi le revendre à d'autres sociétés... jusqu'a ce qu'il change la license ok mais la version initiale reste en GPL!

Aucun client ne peut accepter cela. En tous les cas pas les miens.

---

C'est toujours possible de reprendre le code que tu as développé pour un client X et de le revendre à un client Y. La licence n'a aucun rapport avec cet état de fait.

Citation:

---

Envoyé par epsilon68

Sourceforge a donné un papier à signer pour chaque auteur pour donner leur code à SourceForge.

un code GPL ne peut etre approprié avec un changement de license sauf l'auteur est d'accord ou cède le droit.

---

J'ai pas dit le contraire ;)

Bonjour,

J'arrive un peu tard, mais je vais essayer de réparer les choses inexactes que j'ai lu sur GTK+ :

Citation:

---

Envoyé par zais_ethael

Oula, tu as peut-être une astuce ancestrale perdue dans la nuit des temps, mais GTK est justement l'un des plus mauvais niveau déploiement (sous windows). Je m'étais amusé à faire un package minimal pour un hello world fait avec glade et gtkmm, ça prenant une quarantaine de dlls et la même chose en mos, et j'avais pas pour autant d'assurance que ça fonctionnerait correctement dans tous les cas (je pense à des fichiers de config, des ressources, etc... dont mon applic minimale n'avait pas besoin). Je pense même que pendant bien longtemps Gimp n'installait pas les dlls lui même et laissait le soin à l'utilisateur de télécharger et de lancer l'installeur de GTK+, ça c'est une politique de winner pour une applic grand public :lol:

---

Les développeurs de GTK+ ne voulaient pas faire d'installeur pour Windows à cause des lacunes de son gestionnaire de paquets (enfin vous voyez de quoi je veux parler :aie:). Heureusement ils ont quand même décidés de mettre à jour une archive tout-en-un :D

Après ce n'est pas difficile de faire une application pour Windows, il suffit d'avoir les bons outils : http://nicolasj.developpez.com/gtk/windows/

Au passage, vous noterez la possibilité de changez le thème de GTK+ pour qu'il utilise les fonctions natives de Windows pour dessiner les widgets.

Pour ceux qui veulent d'amuser à faire des fenêtres transparentes, c'est aussi possible : Comment créer un widget transparent ? et c'est prévu d'être inclue dans GTK+ 3.0

Citation:

---

Envoyé par zais_ethael

Bref c'est franchement naze par rapport à du WxWidgets (1 dll, 2-3 mos) ou du Qt (à peine plus).

---

Là je te donne le point, il y a beaucoup de dépendances, mais il ne faut pas oublier que GTK+ est constituée de plusieurs couches indépendantes (déjà toute la partie glib/gobject est présente dans le C++). Après je n'ai pas compris leur but avec l'ajout des loader (une fois ils existent et la fois d'après non, ils s'amusent :mouarf:).

Citation:

---

Envoyé par Mongaulois

et pour GTK dans la prochaine version.

Il fait donc plus qu'essayer de ressembler. Il demande comment faire

---

Oui GTK+ fonctionne sous Mac, il n'y a que le thème qui est en cours.

Citation:

---

Envoyé par zais_ethael

(deux packages séparés si je me souviens bien, avec chacun leurs compléments glade)

---

C'est de l'histoire ancienne pour glade (enfin libglade pour être précis), maintenant elle est inclue dans GTK+.

GTK+ possède aussi de nombreux binding, puisqu'écrit en C : http://www.gtk.org/language-bindings.html

Un autre bon point pour GTK+ est la récente intégration de GnomeVFS (bien sûr porté sous Windows), qui permet de nombreuses interactions avec le système de fichiers.

oulla un expers gtk+:mrgreen:

je me permet docn de reposser ma question bete sans responce , et t il possible de fait un executable avec toutes les librairie necesaire au gui sans que je m arrache je peu de cheveux qui me reste.

d autre detail tout mes libraires sont en c++. est ce que je suis donc obliger d utiliser gtkmm ? ou alors je peu linker des lib c++ avec un gui en c ??

gtk+ 3 sort quand ;) dasn 5 ans :aie:

Citation:

---

Envoyé par lezurp

d autre detail tout mes libraires sont en c++. est ce que je suis donc obliger d utiliser gtkmm ? ou alors je peu linker des lib c++ avec un gui en c ??

---

Tu peux mais gtkmm permet de coupler la puissance de C++ à celle de GTK+, t'as envie de faire des :

Code:

---

1 2	self = my_widget_new (); my_widget_do (self);

---

:aie:

Citation:

---

Envoyé par lezurp

gtk+ 3 sort quand ;) dasn 5 ans :aie:

---

Je pense d'ici deux ans : GTK roadmap notes :langue:

Citation:

---

Envoyé par gege2061

Citation:

---

et pour GTK dans la prochaine version

---

Oui GTK+ fonctionne sous Mac, il n'y a que le thème qui est en cours.

---

lol.
En faite je parlais toujours de Qt :aie:
la prochaine version aura un thème GTK pour faire des appli qui s'intègre bien à gnome.

Tout façon Qt fait quelque chose GTK copie et inversement...
La preuve GTK à déjà copié le futur thème gnome de Qt :langue:

Plus sérieusement, je pense qu'il faut arrêter de dire que wxwidget c'est la daube, Qt n'est pas du C++, GTK c'est lourd....

C'est du troll. Ce serait dire que toutes ses personnes qui se cassent les dents pour nous faciliter la vie n'y connaissent rien et ne réfléchissent pas...
Toute ces lib sont performante et ont à peu prés les même fonctionnalité.
Ce n'est qu'une question de goût et du plus adapté à nos besoin.

Ce qui serait pas mal se serait de réussir à faire un tableau comparatif de leurs fonctionnalités, licence, complexité de déploiement, portabilité, Points fort/Points faible,...

Citation:

---

Envoyé par Mongaulois

lol.
En faite je parlais toujours de Qt :aie:
la prochaine version aura un thème GTK pour faire des appli qui s'intègre bien à gnome.

---

:lol: Dans ce cas, c'est aussi vrai pour GTK+ (sauf pour le thème GTK+ :aie:)

Citation:

---

Envoyé par Mongaulois

Ce qui serait pas mal se serait de réussir à faire un tableau comparatif de leurs fonctionnalités, licence, complexité de déploiement, portabilité, Points fort/Points faible,...

---

On a déjà essayé avec d'autres membres de la rédaction mais sans grand succès :( Peut être qu'en lançant le débat dans le forum contribuez avec l'aide de tous les membres, on aurais plus de chance ?

Citation:

---

Envoyé par Mongaulois

la prochaine version aura un thème GTK pour faire des appli qui s'intègre bien à gnome.

---

Bonne nouvelle, ça !
Moi qui utilise quelques applis Qt sous Gnome, je vais enfin pouvoir les utiliser sans me piquer les yeux.

À noter que l'on peut donner un look Qt natif à une appli Gtk également. Ça se fait en installant un paquet spécifique (gtk-qt-engine). Mais bon, ce n'est même plus le problème du développeur à ce niveau là (et c'est tant mieux).