Discussion :

[liberforce]

Moi, personnellement, je n'apprécie ni KDE, ni Gnome, qui me fournissent bien trop de services inter dépendants.

La seule raison: l'intégration. Dès que tu commence à vouloir faire communiquer les applications entre elles, tu as besoin d'intégration et tu as donc une "glue" entre les applications, qui peut te donner une impression de lourdeur. Néanmoins tu n'es pas du tout obligé d'utiliser ces fonctionnalités supplémentaires. si tu n'en as pas besoin. Par exemple même si Evolution, le client mail de GNOME offre une intégration de l'agenda dans le calendrier, je ne m'en sers pas et utilise Mozilla Thunderbird à la place.

L'uniformisation des interfaces DBus devraient néanmoins simplifier cela, afin de permettre l'intégration d'applications extérieures à un environnement de bureau particulier.

[octal]

@octal


Moi aussi je développe avec QT et Gtkmm. Je préfère de loin Gtkmm + boost.
QT c'est du c++ des années 90. gtkmm du c++ moderne. Je suis bien plus efficace avec ce dernier.
QT fournis plein de trucs inutiles, dont on a pas besoin pour de la GUI, ni pour faire du code portable. Pour faire les backend, boost est bien mieux que QT, moins lourd, plus efficace, plus rapide.

Gtk 3 utilise des technos modernes, de l'introspection, l'accessibilité, theming css, width for height windowing. Dire que c'est vieux, c'est simplement ne rien comprendre à la GUI et la programmation.

Sinon, je ne saurais trop conseiller à ceux qui veulent utiliser Gtk, d'essayer Vala et Python. Bien plus facile d'accès, et diablement efficace.

Le problème que je soulève n'est **pas** Qt vs GTK ni Gnome vs KDE.

GTK devait (et devrait) évoluer vers un modèle objet propre, comme en propose la plus part des framework (qu'ils soient GUI ou pas) modernes.
GTKmm ne fait pas mieux, et quand je vois vers quoi va les nouvelles versions et l'énergie dépensée dans ce framework, je me dis que finalement le modèle open source n'est pas forcément le meilleur choix pour des briques logiciels aussi importantes.
Qt a aussi plein de défaut et nécessite pleins d'améliorations. Ce que je remarque personellement, c'est que le fait que Qt ait était soumis à la communauté open source par Nokia tout en restant sous contrôle est en train de s'améliorer rapidement.
La communauté open source (pour ne plus parler de fondations et autres) devrait "apprendre" à concentrer ces efforts dans des développements constructifs.
Personne ni aucun développeur avec un minimum de connaissance objets ne peut contredire le fait qu'une implémentation orienté objet apporte plus de confort et plus de productivité au développeur qu'une implémentation procédurale (aussi clean soit elle qu'est celle de GTK).
J'aurais bien aimé voir GTK évoluer pour offrir de base les éléments d'un framework objet bien plus mûr qu'il ne l'est maintenant, plutôt que d'aller vers des développement cross/web et autre.
En essayant de faire fonctionner des applications native dans un navigateur (pour moi) on ne va pas forcément dans la meilleur direction.

Gtk 3 utilise des technos modernes, de l'introspection...Dire que c'est vieux, c'est simplement ne rien comprendre à la GUI et la programmation.

Surement trop modernes ... qui datent de 1992 à peu près.
Il y a une différence entre utiliser des technos modernes et entre moderniser le produit.
Je peux utiliser C# et écrire une application de gestion en mode console avec des menus déclenchés par des F1/F2, Ctrl-ESC A ....

Ce n'est pas en faisant exécuter des applications GTK dans un navigateur qu'il deviendra plus moderne.

[liberforce]

• GTK évolue dans le sens où les développeurs le souhaitent: celui qui fait le boulot décide
• on a bien compris que tu n'aimes pas le C, que GObject ne semble pas être assez orienté objet. Tu oublies pourtant un peu vite que le C++ n'est pas assez objet non plus puisqu'il n'y a pas de notion de signal/callback (ou signal/slot pour Qt), d'introspection, de compteurs de référence, et que de toute façon tous les toolkits doivent réimplémenter une couche objet par dessus les langages car ces derniers n'offrent pas toutes les fonctionnalités de base.
• Encore une fois, inutile de s'acharner sur le C, les bindings offrent bien d'autres choix pour le développeur.

En revanche, je suis d'accord avec toi que GTK et Qt font un peu doublon. La liberté a pour effet pervers de diluer les efforts...

[octal]

[LIST][*]on a bien compris que tu n'aimes pas le C

Je n'ai jamais dis cela. J'utilise le C dans 99% de mes développement pour l'embarqué et j'en suis très très content. Le problème n'est pas au niveau du langage lui même, c'est pareil pour les technos, le problème n'est pas dans les technos elles même, le problème c'est là où et quand on les utilises.
J'utilise du C pour faire de l'embarqué, pour écrire des CGI, pour écrire des drivers de bas niveau, pour écrire des GUI pour des microcontrolleurs avec 1 ou 2 K octets de RAM et 64K octet de rom (flash). Je ne l'utiliserai jamais pour écrire une application de gestion de stock sous Windows (et pourtant c'est réalisable).
Pour faire un kit GUI pour petit microcontrolleur, utiliser la technique GTK pour écrire sous une forme plus ou moins orientée objet les éléments d'interface et gérer les arborescences d'objet visuel est tout à fait normal. Je trouverai qu'il est anormal de le faire pour un kit destiné au PC.
Après qu'on aime ou pas ce raisonnement, chacun fait ce qu'il veut, on n'a surement pas les même expériences au niveau expertise et métier de terrain au près de client utilisant l"'informatique pour vivre et faire vivre leur métier et pas pour faire des "proof of concepts".

[LIST][*]on a bien compris que tu n'aimes pas le C
En revanche, je suis d'accord avec toi que GTK et Qt font un peu doublon. La liberté a pour effet pervers de diluer les efforts...

++1
C'est juste ce que je voulais dire depuis mon premier post. L'acharnement sur le portage d'appli natives vers le monde web d'une manière brute n'est pas forcément la solution, et engendre une perte d"effort considérable qui pourrait être mise à profit des framework comme GTK pour en faire des produits bien plus mature. Et par mature, je veux dire qui répondent "rapidement et tout de suite" aux besoins de l'informatique moderne telle qu'elle a été influencée par les acteurs majeurs de l'industrie (qu'ils soient du monde Open ou pas).

[liberforce]

Je n'ai jamais dis cela. J'utilise le C dans 99% de mes développement pour l'embarqué et j'en suis très très content. Le problème n'est pas au niveau du langage lui même, c'est pareil pour les technos, le problème n'est pas dans les technos elles même, le problème c'est là où et quand on les utilises. J'utilise du C pour faire de l'embarqué, pour écrire des CGI, pour écrire des drivers de bas niveau, pour écrire des GUI pour des microcontrolleurs avec 1 ou 2 K octets de RAM et 64K octet de rom (flash). Je ne l'utiliserai jamais pour écrire une application de gestion de stock sous Windows (et pourtant c'est réalisable).

C'est sûr qu'on utilise pas un tournevis pour enfoncer un clou. On peut, mais c'est moins efficace. Je pense personnellement que le C n'est pas uniquement réservé à l'embarqué, et je l'utilise pour écrire mes applications GTK, mais juste parce que c'est le langage avec lequel je suis le plus à l'aise et parce que je ne fais pas de gros trucs. Je conseille évidemment au gens qui débutent en GTK de développer en python (pyGTK) ou C++ (GTKmm).

Pour faire un kit GUI pour petit microcontrolleur, utiliser la technique GTK pour écrire sous une forme plus ou moins orientée objet les éléments d'interface et gérer les arborescences d'objet visuel est tout à fait normal. Je trouverai qu'il est anormal de le faire pour un kit destiné au PC.

La frontière est de plus en plus floue. Les technos desktop se retrouvent de plus en plus dans des environnements embarqués...

Après qu'on aime ou pas ce raisonnement, chacun fait ce qu'il veut, on n'a surement pas les même expériences au niveau expertise et métier de terrain au près de client utilisant l"'informatique pour vivre et faire vivre leur métier et pas pour faire des "proof of concepts".

C'est sûr.

C'est juste ce que je voulais dire depuis mon premier post. L'acharnement sur le portage d'appli natives vers le monde web d'une manière brute n'est pas forcément la solution, et engendre une perte d"effort considérable qui pourrait être mise à profit des framework comme GTK pour en faire des produits bien plus mature. Et par mature, je veux dire qui répondent "rapidement et tout de suite" aux besoins de l'informatique moderne telle qu'elle a été influencée par les acteurs majeurs de l'industrie (qu'ils soient du monde Open ou pas).

C'est là qu'on est pas d'accord. Tu as un gars qui se dit qu'il y a une possibilité intéressante à explorer. Même s'il ne sait pas si ce sera vraiment utile ou utilisé, il le fait. Personnellement, je ne sais pas s'il l'a fait en étant payé (c'est un employé de Red Hat) ou sur son temps libre, mais tu as un gars qui fait ça, et toutes les applications GTK peuvent profiter de cette amélioration, sans avoir à les modifier ni même les recompiler. Il offre ainsi une possiblité que chaque développeur ou utilisateur sera susceptible d'utiliser, ou non.

[troumad]

Bonsoir

On parle de la sortie de GTK 3.2 . On ne parle pas de GTK3 sous Windows !

Ceci est d'autant plus gênant que maintenant, sous GTK3, il y a de nouvelles fonctions obsolètes dont les remplaçantes n'existent pas sous les dernières versions de GTK 2 disponibles sous Windows.

J'en reviens presque à regretter de m'être investi dans l'apprentissage de GTK l'an dernier ! À moins que GTK3 pour windows ne soit en cours d'arrivage ?

[Invité]

Personnellement, j'ai essayé de compiler GTK+3.2 sous Windows mais j'ai un problème avec la glib-2.30 qui a un bug (à mon avis) sous windows dans la gestion des threads.
J'arrive bien à tout compiler mais plus aucune application ne s'exécute sans planter. Pour le moment je reste donc à la version 3.0.

Quant à la version officiel pour windows, ce n'est à mon avis pas avant quelques temps. En effet, il y a quelques bugs très génant (https://bugzilla.gnome.org/show_bug.cgi?id=653204 par exemple) qu'il est impératif d'être corrigé mais bon... Tant que personne n'a le temps (les développeurs) ou les compétences (moi par exemple) pour se pencher sur la résolution des bugs GTK pour Windows, le problème de la compatibilité de la librairie pour Windows n'est pas prête d'être résolue.

Edit : je viens de trouver l'origine du bug : http://mail.gnome.org/archives/gtk-l.../msg00007.html et https://bugzilla.gnome.org/show_bug.cgi?id=652827

[troumad]

Qunad tu compiles en 3.0 pour windows, peux-tu facilement donner ton programme compiler à des relations non geek ? (genre installation des dll et autres outils gtk)

[Invité]

Oui oui, c'est très simple, il suffit de prendre le .exe et de le placer dans un dossier vide. Ensuite, à chaque fois que tu l'ouvres il va dire qu'il te manque une dll que tu déplaces dans le même dossier que l'application. Une fois que tu l'a fait pour chaque dll nécessaire (environ une trentaine), il te reste encore quelques DLLs à récupérer (chargées dynamiquement pour les images : librsvg.dll notamment) il convient donc de tous les récupérer. Une fois cette opération un peu lourde à faire, ton programme (.exe) peut être utilisable sur n'importe quel ordinateur à condition que l'ensemble des dlls se trouve dans le même dossier.

[troumad]

Donc...
Il faut deux systèmes à télécharger : l'ensemble des dll d'un côté et le programme de l'autre.

Mais, est-ce comme avec GTK2 où l'environnement ainsi récupéré n'est pas joli car on n'a pas configuré GTK ? (J'avais fait l'essai avec GTK2 pour ceux qui ne voulaient ou ne pouvaient pas installer GTK.

[Invité]

Absolument, il n'y a donc pas de thème à GTK+3 par cette méthode. Mais en fait, je n'ai jamais installé un thème pour accompagner GTK+, je ne sais même pas comment faire.

[troumad]

Le thème est indispensable pour avoir des icônes non ?

[Invité]

Euh... j'avoue ne pas savoir. En fait, j'ai toujours utilisé mes propres icônes...

[liberforce]

On parle de la sortie de GTK 3.2 . On ne parle pas de GTK3 sous Windows !

Ceci est d'autant plus gênant que maintenant, sous GTK3, il y a de nouvelles fonctions obsolètes dont les remplaçantes n'existent pas sous les dernières versions de GTK 2 disponibles sous Windows.

J'en reviens presque à regretter de m'être investi dans l'apprentissage de GTK l'an dernier ! À moins que GTK3 pour windows ne soit en cours d'arrivage ?

La situation de GTK 3 sous Windows est claire: il n'y a pas grand monde pour s'y coller. Il y a trop de boulot sur GTK et pas assez de mainteneurs. Tor Lillqvist s'est retiré, et il n'y a personne pour le remplacer. Clairement GTK 3 pour Windows n'est pas prêt, mais rester sur GTK 2 n'est pas non plus bloquant en soi, sachant qu'il y a à mon avis un bon paquet d'applications (même sous Linux) qui n'ont pas fait la migration, donc GTK 2 est encore présent sur ces systèmes. Une liste de diffusion pour le développement sous Windows a été ouverte, la windows-devel-list, mais il n'y a pas encore foule.

Donc si la compatibilité Windows est nécessaire, je te conseille de rester encore pour le moment sous GTK 2.

[troumad]

Pour la liste de sous windows, si elle est en anglais, je ne peux pas y aller.
Pour le moment, je me contente dans de faire du gtk3 compatible gtk2 ou du gtk2 compatible gtk 3 (malgré les warning depuis gtk 3.2 ).

[Invité]

Juste pour confirmer : je viens de réussir à compiler mon application avec GTK+3.2 sous Windows et c'est vraiment pas fameux... ça plante (drag&drop), ça bug (les images), ça tout (et j'en oublie sûrement beaucoup)... Par contre, sous Linux, pas de problème.

[troumad]

Pour compiler sous Windows, tu as du préalablement compiler gtk (les dll et le reste). Je suppose que tu n'es pas le seul à l'avoir fait !
Pourquoi personne ne met en ligne son travail de compilation de gtk ?

[Invité]

Je l'ai déjà fait : http://www.developpez.net/forums/d11...windows-mingw/

Même si depuis, ça a pas mal changé le principe reste le même. Si tu veux, je peux réinsérer ici la procédure de compilation sous MinGW.
Après, si tu parles de mettre en ligne les DLLs, c'est un autre problème. Je ne sais pas quels éléments ils faut récupérer. Si tu veux, je peux faire une tarball de tout mon dossier MinGW (sources compilées y compris) mais ça va faire dans les 2-3 Go (non compressé) (je compile mes dlls avec les options de débogage). Si je supprime mes sources compilées, ça divise par deux... d'où le problème de distribution. Parce que je ne vois pas vraiment l'intérêt de distribuer juste les dlls compilées sans les entêtes et autres...

[troumad]

2-3 go !
Mais, les systèmes d'installation complet de gtk 2 prenaient beaucoup moins de place !

[Invité]

oui oui oui. Mais ce que je propose de fournir c'est tout un pack : mingw pleinement fonctionnel, les sources de chaque paquet compilées et les DLLs. Si je ne fournis que les DLLs, je me retrouve avec environ 150Mo environ (avec les options de debug -g3 -ggdb3). Sans les options de debug, je devrais diviser la taille par environ 5.

Edit : ce que je peux te proposer c'est que j'insère demain (je ne l'ai pas avec moi en ce moment) le script qui permette de tout tout compiler en une fois.