Sébastien Wilmet a écrit 729 commentaires

C'est tout le débat entre les langages à typage statique et dynamique. Je suis tout à fait conscient que Python est utilisé pour des gros, voir très gros, logiciels. Mais je ne suis pas convaincu.

Quand on écrit from scratch un nouveau programme, et qu'on est le seul développeur, forcément on a une bonne connaissance du code (mais ça ne va plus de même quelques mois ou années plus tard). Mais quand on doit plonger dans du code Python qu'on ne connait pas, j'en ai l'expérience, je trouve ça horrible. Quand on voit le prototype d'une fonction, on ne sait même pas de quel type sont les arguments ! (bon, j'ai entendu qu'il était possible de définir le type, dans ce cas-là, mais combien de développeurs le font ?) Il faut trouver les appels de la fonction en question, voir quelles variables sont passées en arguments, pour espérer savoir de quel type sont les variables. Avec un peu de malchance, il faut recommencer le processus (trouver l'appel de la seconde fonction, etc).

Autre exemple, quand on veut faire du refactoring, renommer une méthode, une classe, etc. J'ai donné l'exemple dans le journal de la méthode « show ». Vas-y pour trouver tous les appels de la méthode show dans un code volumineux… Avec une bonne greppabilité du code, et une compilation pour détecter les erreurs, aucun soucis.

Et je suis loin d'être le seul à penser ce genre de choses. Bien sur ça ne fait pas très plaisir à entendre quand on est convaincu par les langages dynamique (pour des gros programmes), et qu'on y a travaillé de cette façon pendant plusieurs années… J'aimerais pourtant avoir tord, mais j'aimerais qu'on m'explique comment on procède dans les deux situations que je viens de décrire.

Evolution a l'air d'avoir quand même beaucoup d'éléments réutilisables, dont EDS qui sert à gérer le carnet d'adresses et le calendrier. Il y a aussi Camel pour gérer plein de choses en rapport avec les mails, comme les objets MIME, le protocole IMAP, etc.

Les développeurs de Yorba ont quand même sans doute raison sur un point, c'est que ces librairies sont assez vielles. Il n'y a pas que le code qui est ancien, il y a aussi l'API. Pour le code, c'est plus facile de le moderniser, tandis que pour l'API, ils sont un peu coincés. Il y a sans doute moyen de créer une API plus moderne, basée sur GIO notamment. Ils pourraient évidemment casser l'API, sortir une nouvelle version majeure, etc, mais ça demande beaucoup d'efforts, avec pour risque d'amener des régressions.

Mais de là à recommencer from scratch une toute nouvelle implémentation, il faut vraiment le vouloir.

Sans parler de Music, Photo, et d'autres noms pas pratique à chercher dans un moteur de recherche. Au lieu d'améliorer Rhythmbox ou Banshee (pour la musique); eog (Eye of GNOME), Shotwell ou encore gthumb (pour visionner des images).

J'aime bien les technologies de GNOME, en tant que programmeur. Mais il y a plein de choses pour lesquelles je ne suis pas d'accord dans les directions que prend GNOME. Heureusement, ça n'impacte pas le petit monde des éditeurs de texte et GtkSourceView.

Pour moi la chronologie logique d'apprentissage est GLib -> GObject -> GIO -> GTK+. Le livre Foundations of GTK+ Development commence direct par GTK+ et n'apprend que très tard comment créer une sous-classe d'un widget existant (ce qui est très utile dès le début, pour éviter de se retrouver avec des variables globales de plus en plus grosses, ce qui est à éviter à tout prix).

Par contre, le livre The Official GNOME 2 Developer's Guide a une chronologie logique, mais se fait un peu vieux, surtout pour les derniers chapitres, mais aussi pour GObject, il y a moins de boilerplate aujourd'hui, et on peut espérer d'autres simplifications dans le futur (GProperty notamment).

Merci pour ton retour d'expérience plus détaillé. Pour la documentation, où il faut se référer à l'API C et deviner la traduction dans le langage de plus haut niveau, il y a plus ou moins le même problème pour Vala. La solution est de lire le fichier vapi (qui décrit l'interface entre C et Vala).

Le lien fonctionne bien ici.

Pour l'organisation d'un projet en C pour GNOME, le mieux est d'analyser l'architecture d'un logiciel existant (gedit par exemple), et de s'en inspirer. Généralement on crée une sous-classe de GtkApplication pour la gestion générale de l'application, surtout au démarrage et à l'arrêt. On peut avoir quelques singletons par-ci par-là pour stocker certaines données, sous forme de fichier XML par exemple. Quand l'instance du singleton est créée, les données sont extraites et stockées dans des structures de données (en mémoire), et quand l'application quitte, les données sont sauvegardées. Ce n'est qu'un exemple bien sûr, il peut y avoir d'autres classes interagissant avec une base de données, etc. Il y a aussi généralement une sous-classe de GtkApplicationWindow, qui permet de coller les différents composants de la fenêtre principale ensemble. On peut imaginer une classe SidePanel, avec une instance stockée dans un attribut de la fenêtre principale.

Toutes les bonnes pratiques de l'orienté objets s'appliquent. Certains n'aiment pas les singletons, donc rien n'empêche d'utiliser d'autres design patterns. Il vaut mieux faire attention à ne pas créer des « God Classes », qui en savent un peu trop. Et éviter si possible trop de dépendances entre les différentes classes. La sous-classe de GtkApplicationWindow aura sans doute des attributs vers beaucoup d'autres classes, mais la dépendance ne va que dans un sens.

Enfin, pour apprendre GObject, il y a beaucoup d'explications dans la documentation officielle. La partie « I. Concepts » est très importante. Mais ça peut être assez difficile à comprendre au début. Il y a quelques livres sur GLib/GObject/GTK+, mais aucun n'est vraiment récent. C'est un reproche que je fais aux développeurs de GTK+, il faudrait qu'un des développeurs mette à jour un des livres…

Pour finir, j'ai écris récemment une page getting started pour gedit, ça peut toujours être utile pour d'autres projets. Mais comme je l'ai dit dans un commentaire plus haut, il vaut mieux contribuer à un projet existant.

Oui, je trouve aussi un peu dommage de réinventer la roue à chaque fois. D'un autre côté, Geary a une interface fort différente de Evolution ou Thunderbird je pense. C'est bien aussi d'avoir le choix du client mail qu'on utilise, pour que ça convienne le mieux à nos besoins et préférences. Mais c'est un peu bête que Geary n'utilise pas Evolution Data Server (EDS).

C'est pour ça qu'il est plus intéressant de contribuer à un projet existant plutôt que de commencer un projet dans son coin, qui la plupart du temps n'aboutit pas à grand chose. En contribuant à un projet existant, on profite aussi de l'expérience des autres développeurs. Un article intéressant à lire à ce sujet : Working on Free Software.

Oui chez Yorba ils aiment bien Vala. Et dans les nouvelles applications GNOME, il y en a quelques unes en Vala aussi, dont Clocks (mais Clocks est une petite application, contrairement à Shotwell ou Geary).

Donc Vala est aussi utilisé dans des grosses applications, mais peut-être qu'ils s'en mordront les doigts plus tard (si Vala n'est plus bien maintenu dans le futur, par exemple… d'ailleurs ces derniers temps il y a beaucoup moins de changements par rapport à il y a quelques années). Ou au contraire, peut-être qu'en choisissant Vala ils ont fait un excellent choix, si le compilateur s'améliore (basé sur LLVM par exemple), et que la toolchain en général s'améliore aussi.

Quel langage faut-il utiliser, alors ? Pour garder la plupart des avantages du C que j'ai cité, je vois Java et C#. Mais le support pour GNOME est moins bon. Quoi que, il y a eu un GSoC cette année pour GObject-introspection pour la JVM, donc on peut espérer avoir un bon support. C# a sorti une deuxième beta récemment pour GTK+ 3, donc ils sont un peu à la traine.

Dans tous les cas, le C restera le langage de choix pour les bibliothèques.

Je parle bien des changements autours de JavaScript dans GNOME. Il y a certainement eu des changements dans JS, mais en-dehors de GNOME.

Suite à la hackfest juste avant le FOSDEM en février 2013, les développeurs d'Anjuta (l'IDE de GNOME) ont travaillé dans le but de fournir un profil JavaScript à Anjuta. Je ne sais pas où ça en est actuellement. De mon côté, j'essaye de migrer certaines fonctionnalités de gedit vers GtkSourceView, avec comme but de pouvoir créer facilement des éditeurs de texte spécialisés (ou des IDE complets) basé sur GtkSourceView, sans réimplémenter les fonctionnalités de gedit ou Anjuta. Ça a commencé avec la recherche et remplacement pour le début de mon GSoC cet été. Et je continue maintenant avec le chargement et la sauvegarde de fichiers (contrairement à ce qu'on pourrait croire, ce n'est pas si simple).

Je ne connais vraiment pas bien JavaScript, mais de ce que j'ai pu en voir, il n'y a pas eu beaucoup de changements depuis que ce langage a été élu « le langage de GNOME » (pour les applications, pas pour les bibliothèques).

Et par exemple la libpeas, la bibliothèque pour gérer des plugins dans une application, a retiré récemment le support pour JavaScript, car c'était buggé depuis un moment, sans aucun rapport de bug. Donc on peut supposer que personne n'écrivait de plugin en JavaScript, pour une application basée sur libpeas (notamment gedit et totem). Évidemment GNOME Shell a toujours ses extensions en JavaScript, mais ce n'est pas basé sur libpeas.

Sur LWN, on peut lire :

An initial unstable release

Mais sur la FAQ il n'y a pas vraiment d'avertissement…

Je pense que tu voulais dire plutôt :

$ not !!

Pour compléter mon commentaire, il est à noter que les BSD sont moins génériques qu'une distribution Linux en ce qui concerne le système de base (kernel, lib C, système d'init, shell, commandes de base, etc), vu que leur système de base est stocké dans un seul repository (CVS, mais bon soit). Pour comparer avec le monde Linux, systemd se rapproche un peu de cette philosophie.

GNOME essaye clairement que ça Juste Marche™, alors que KDE se veut plus configurable.
La séparation entre Fedora et Debian est moins nette je trouve. Autant Debian que Fedora fonctionnent bien après installation. Il y a juste deux trois bricoles à installer ou configurer, pour une utilisation basique (et si le matériel fonctionne). Gentoo par contre est clairement très générique, à chaque étape de l'installation, le choix est laissé à l'utilisateur.

On voit une fois de plus que la famille Debian est une bonne base pour construire une nouvelle distrib.

Pourquoi ne pas se baser sur Fedora, OpenSUSE, Arch Linux ou encore Gentoo ?

Finalement, ça a des avantages de vouloir créer un système d'exploitation universel, et donc d'essayer que ça marche bien avec le plus de configurations possibles. Mais pour une utilisation classique, ça engendre des désavantages, vu qu'il y a une explosion combinatoire de configurations possibles, c'est beaucoup plus difficile pour les développeurs de tester à fond leurs logiciels, et donc il peut y avoir plus de bugs.

Vaut-il mieux développer un truc vraiment générique, hyper portable, avec une configuration compliquée, mais qui convient pour vraiment tout le monde ? Ou bien faire en sorte que ça fonctionne out-of-the-box, avec une configuration simple, qui convient pour la plupart des besoins, mais qui a plus de dépendances ? Je suppose qu'il faut choisir un juste milieu, selon le logiciel en question. Et la force du libre, c'est d'avoir généralement le choix, donc si une solution ne nous convient pas, on choisit un truc plus générique. {Insérez ici des exemples de votre choix, systemd, GNOME, KDE, Debian, Fedora, …}.

Une IA ne réfléchit pas de la même manière qu'un humain. L'IA contient certainement des heuristiques pour naviguer dans l'arbre des mouvements possibles (qui contient un nombre exponentiel de noeuds, un ordinateur n'a pas le temps de faire une recherche exhaustive, donc le brute force n'est pas possible pour un jeu d'échec).

En gros, l'IA peut te dire : « j'ai choisi de faire ce mouvement, car après avoir analysé un million de mouvements possibles (avec une profondeur plus ou moins grande), celui-ci me paraissait le meilleur selon mon heuristique. »

Donc, pour que l'ordinateur donne un feedback à l'utilisateur, il te faudra sans doute écrire d'autres algorithmes pour avoir une pensée plus proche de l'humain.

c'est pour quand ?

Quand il y aura davantage de packageurs pour faire le boulot ?

GNOME a quand même une meilleure finition. J'entends par là que ça forme un tout cohérent, notamment pour les préférences du système.

As-tu un lien vers ce salon de la photo ? C'était où ? Ça se passe chaque année ? Au même endroit ?

J'accorde plus de credit aux propos de Benjamin Otte qu'aux tiens.

Ah ben merci, ça fait toujours plaisir à entendre… Je suis très loin d'être au niveau de Benjamin Otte, mais il me semble juste que GTK+ 3 a plus d'activités que GTK+ 2. Et ça se confirme en regardant les stats. Et même si GTK+ 2 n'était pas très actif, ça n'a pas empêché à GNOME 2 d'être un réel succès. Il y a peut-être certains développeurs qui quittent le navire, mais d'autres rejoignent le projet aussi. Et le nombre total de contributeurs, qui est en croissance, montre une évolution de la mentalité chez les développeurs GNOME : au lieu d'avoir des workarounds dans le code d'une appli, c'est mieux de fixer le problème à la source.

GTK+ et GLib ont beaucoup de potentiel. Il y a pas mal de challenges techniques sur la route, mais je pense que ce sont des projets qui ont de l'avenir. Dire "GTK+ c'est de la merde, Qt est beaucoup mieux à tout point de vue" (en affichant une longue liste de citations) est faux, et n'encourage pas les nouveaux venus à choisir GTK+, alors que ça pourrait très bien leur convenir.

Bref, si quelqu'un aime bien Qt, ce n'est pas une raison pour vouloir rabaisser GTK+ à tout prix. C'est à force de rabaisser continuellement un projet qu'il fini par ne plus avoir de nouveaux contributeurs, et par mourir.

vu que GTK ne s'interesse pas aux mobiles

Les derniers à s'y intéresser sont Endless Mobile. Ils ont donné une keynote au GUADEC cette année. Il y a eu d'autres initiatives, voir la section Mobile sur cette page.

Pour avoir une plus grande stabilité, les développeurs recommandent de rester à GTK+ 2 […] Le plan est d'avoir GTK+ 4 de nouveau stable

Premiere nouvelle, je suis curieux de connaitre ta source.

GUADEC 2013, une des confs sur GTK+.

Quand on voit les statistiques, GTK+ est loin d'être abandonné. Plus de 3000 commits pour les 12 derniers mois, avec plus de 200 contributeurs: http://www.ohloh.net/p/gtk
Il y a eu un pic d'activité aux alentours de GTK+ 3.0 (un plus grand nombre de petits commits, sans doute).

Ca pourra aider ceux qui se posent la question GTK+ vs Qt, quel toolkit/framework choisir ?

Avoir une bonne intégration à un certain gestionnaire de bureaux, ça peut être aussi un critère pour le choix du toolkit. Pour GNOME ou Xfce, rien de mieux que GTK+.

Pour la question du multiplateforme, GTK+ 2 fonctionne très bien sur Windows et Mac. GTK+ 3 un peu moins bien, mais c'est normal vu que GTK+ 3 est beaucoup plus actif (et donc moins stable) et que Linux reste le système majoritaire utilisé par les développeurs. Pour avoir une plus grande stabilité, les développeurs recommandent de rester à GTK+ 2, mais il y a moins de fonctionnalités évidemment. Le plan est d'avoir GTK+ 4 de nouveau stable. GTK+ 3 est donc une période de transition.

Développant en GTK+ depuis pas mal d'années, j'en suis assez satisfait. Et il n'y a pas que GTK+, il y a aussi GLib, GObject, GIO, … qui sont très stables au niveau de l'API, et un réel plaisir à utiliser. Ces bibliothèques ont encore de beaux jours devant elles.

Le dev de GTK est très peu soutenu en comparaison avec Qt

Je ne connais pas pour Qt, mais les entreprises qui offrent du support ou développent GTK+ : Red Hat, Suse, Lanedo, Collabora, Igalia, Openismus, Codethink, Canonical, des indépendants, sans compter les célibataires la communauté. Il y a donc un bus factor > 1.

Le dev en GTK est une calamité

GTK+ 3 apporte quand même de plus en plus de nouvelles API bien foutues. Et utilisant GTK+ depuis pas mal d'années, je trouve que c'est loin d'être une calamité. Parfois quand on a une utilisation un peu plus poussée d'une API, on se rend compte que la documentation n'est pas suffisante, il faut aller voir le code. J'écris donc de temps en temps des patchs pour améliorer la doc, et il y a généralement une review assez rapidement.

Et quand on développe en GTK+, on utilise aussi GLib, GObject, GIO. Ce sont des bibliothèque très stable au niveau de l'API, et c'est un vrai bonheur de les utiliser. Pour écrire une application en console, ça fait d'ailleurs très bien l'affaire. Un truc qui m'a réjoui récemment, c'est GSubprocess, pour lancer des sous-processus facilement, tout en supportant pas mal de fonctionnalités avancées, comme lire ou écrire des flux de données de manière asynchrone entre plusieurs processus. Dans son domaine, GSubprocess est apparemment ce qui se fait de mieux dans le libre.

On dit libriste.