Sébastien Wilmet a écrit 713 commentaires

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.

Debian supporte plus d'architectures matérielles, différents systèmes d'init, différents noyaux (Linux, FreeBSD), etc. Debian essaye d'être le plus universel possible. Et ça engendre plus de travail pour qu'un gros desktop comme GNOME fonctionne correctement dans toutes les configurations possibles de Debian.

Fedora, et sans doute Arch aussi, ont moins de configurations possibles.

À propos des compilateurs, j'ai presque fini de lire Engineering a compiler, de Cooper et Torczon (de l'université de Rice). Je n'ai pas regretté mon achat, c'est bien expliqué, on a une bonne vue d'ensemble de ce que fait un compilateur, et les différents moyens d'implémentation pour chaque phase. Il faut évidemment avoir de bonnes notions d'algorithmique pour comprendre un livre sur les compilos.

C'est là qu'on se rend compte qu'un compilateur comme GCC est un véritable monstre, qu'il y a plein d'algos compliqués, et que ça doit pas être évident d'arriver à un tel résultat (toutes les optimisations possibles, le nombre d'architectures supportées, …).

C'est juste que le style d'écriture s'adresse aux adolescents.
Il y a des très bons bouquins pour un public plus adulte pour apprendre le HTML ou la programmation facilement.

De rien ;-) J'espère que je ne verrai pas arriver trop de rapports de bugs une fois que gedit 3.10 débarquera dans les versions stables des distributions. Donc merci pour beta tester avec le PPA.

(C'est le thread où on peut se lacher, allez-y !)

Les tutos sont écrits par des débutants, pour des débutants.

Le site du zéro, c'est fait pour les 12-14 ans (voir 8-16 ans si on prend large).

C'est le principe de la méritocratie, en gros.

Je ne vois pas où tu veux en venir.

Oui, dans des cas très particuliers, grep te sortira un ou deux résultats non voulus, mais le but premier est de savoir où est appelé telle ou telle fonction. Donc c'est très loin d'être grave…

Exact. Pour éviter ce souci, les dernières versions des bibliothèques GNOME comprennent une surcouche nommée GObject-Introspection qui permet de régénérer des bindings "fiables" pour chaque nouvelle version de Vala.

Je ne parlais pas des bindings, je parlais du fait que les mainteneurs d'applications doivent adapter le code pour utiliser les nouvelles API, si ils veulent rester à jour par rapport à GTK+ etc.

Si ce boulot est fait petit à petit, au fur et à mesure des versions, ça ne demande pas trop trop de temps. Mais si on rajoute les incompatibilités entre les différentes versions de Vala, ça rajoute du boulot supplémentaire, dont on se passerait bien.

ne sortir que des méthodes et pas de variables du même nom par exemple

Tu as déjà vu une variable portant le nom gtk_text_view_new_with_buffer ?

si tu as plusieurs méthodes avec des paramètres différents mais du même nom

Ça n'existe pas en C.

Là où grep fonctionne très bien pour du code C, pour d'autres langages comme Java il faut utiliser les fonctionnalités d'un IDE comme Eclipse (outil refactoring pour renommer une méthode ou une classe, par exemple).

Mais la verbosité du C est aussi utile pour la compréhension du code. Quand on a une hiérarchie importante de classes, le fait d'avoir le nom complet des fonctions permet de savoir de quelle classe elle vient, et donc on retrouve plus rapidement la documentation.

sur le code «greppable», soit j'ai pas compris, soit ça s'applique à plus ou moins tous les langages objets (en C++, Java, … t'auras le même problème pour «grepper», non ?)

Oui. Le C est un langage un peu plus verbeux, mais ça a des avantages.

Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients.

Si on veut faire du GLib/GObject en C, c'est vrai qu'il y a pas mal de code de « remplissage ». En Vala, les spécificités de GObject (interfaces, classes, propriétés, signaux, etc) sont directement intégrés dans la syntaxe du langage.

Ce qui est pas mal aussi, c'est les closures, ou fonctions anonymes où on peut appeler des variables qui sont déclarées en-dehors du corps de la closure. C'est pratique pour attacher un callback à un signal : le code de la fonction est au même endroit. C'est à réserver que pour les petites fonctions, bien évidemment.

Autre point fort de Vala : la gestion automatique de la mémoire (qui se fait avec un compteur, quand il tombe à 0 la mémoire est libérée). Mais ça peut être vu aussi comme un point faible pour Vala, car le compilateur valac fait parfois des trucs vraiment pas optimisé, notamment quand des chaines de caractères sont manipulées.

Il y a d'autres (gros) désavantages à Vala. Déjà, valac est assez buggé (bon, avec le temps ça s'améliore, mais c'est pas encore ça). Donc quand on trouve un bug dans Vala, on perd énormément de temps rien que pour se rendre compte que ça vient de Vala, il faut analyser le code C généré (qui est assez immonde), rapporter/corriger le bug, trouver un contournement en attendant, etc.

Quand vous faites du C, vous regardez souvent le code assembleur que GCC génère, pcq GCC est buggé ? Non, évidemment pas.

Faire du Vala, c'est rajouter une couche de maintenance en plus. L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps). Mais la « couche » Vala peut changer aussi. Ça demande du travail de maintenance en plus, qu'on n'a pas quand on fait du C.

Bref, pour développer une application Gnome, je conseillerais plutôt le C. Quand on voit une classe GObject en C, on se demande d'abord qu'est-ce que c'est ce bazar, mais finalement on s'habitue, c'est pas si dérangeant que ça.

Ce qui est bien avec le C, aussi, c'est que le code est facilement « greppable » : on utilise le nom complet des fonctions. En Vala, on utilise objet.méthode(). Quand « méthode » est un nom très court qui revient pour beaucoup d'objets (get, set, …), c'est difficile de trouver tous les endroits dans le code où la méthode est appelée. Dans ce cas c'est plus facile de grepper dans le code C généré, puis d'essayer de retrouver l'endroit exact dans le code Vala, ce qui n'est pas très pratique.

Peut être qu'ils veulent que le code soit aussi compilable avec un compilateur C des années 70 (ce qui ne m'étonnerait pas).

En voyant ce récent commit, justement on dirait que ce n'est plus une priorité.

Il y aura toujours un peu de maintenance à faire, pour que ça fonctionne toujours bien avec les dernières versions des dépendances, et pour porter si besoin le code sur d'autres plateformes. Bien que pour sed il ne doit pas y avoir beaucoup de dépendances, et elles sont à mon avis très stable (pas de cassage de l'API à tout bout de champ).

Et si un jour un chercheur publie un article avec un tout nouveau algorithme ayant une complexité calculatoire moindre, c'est toujours intéressant de l'implémenter, pour ne pas rester à la traine par rapport aux autres implémentations.

Paolo Bonzini était le seul mainteneur de sed ? Il y a quelqu'un pour le remplacer ? Je ne vois aucune information à ce sujet.

Beaucoup d'outils comme sed conviennent maintenant à la plupart des besoins des utilisateurs. Il y a de moins en moins de raisons de vouloir contribuer. Ce n'était à mon avis pas le cas dans les années 90. Je peux me tromper, mais je pense qu'en faisant des statistiques, on pourrait voir que ces dernières années il y a moins de contributions que dans les années 90. Pourtant, pour la pérennité à long terme de ces logiciels, il faut de nouveaux développeurs, qui doivent être suffisamment calé dans le domaine.

Y aura-t-il toujours des développeurs suffisamment compétents pour maintenir les trucs comme sed ?

Le risque est qu'un jour, plus personne ne comprenne pourquoi certaines parties du code ont été écrite d'une telle manière, puisque plus personne n'y a touché depuis des années, et que la personne ayant écrit le code n'a pas laissé suffisamment de documentation ou de commentaires, et que la personne n'est plus disponible.

Je pense qu'à long terme, c'est un risque qu'il ne faut pas négliger, et donc, raison de plus pour bien documenter son code ;)