Sébastien Wilmet a écrit 719 commentaires

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.

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.