swilmet a écrit 647 commentaires

Donner un nom à une chose est important. Les design patterns en POO est très important par exemple. Si je te parles de méthode factory, tu comprends tout de suite de quoi je parle.

Une autre chose importante est de trouver des axes de différentiation. J'en ai donné quelques uns dans le journal, et d'autres en ont donné d'autres dans les commentaires.

Par exemple, savoir qu'un certain IDE possède un modèle de code est intéressant, car ça implique qu'il puisse y avoir des fonctionnalités plus intéressantes.

D'après les (plus vieux) développeurs de gedit, il ne manque pas grand chose à gedit pour être à la hauteur de sublime text. C'est juste une question de découvrir les différents plugins disponibles, et de s'habituer aux raccourcis clavier. Et gedit existe depuis plus longtemps que sublime text…

Le concept de projet, encore un autre axe de différentiation.

Une chose que je n'ai pas dit, c'est qu'avec le temps (ajouts de fonctionnalités), ou avec des plugins, il y a moyen de transformer un éditeur de texte en un IDE.

Par exemple gedit est considéré comme un simple éditeur de texte, mais avec des plugins il y a moyen de le configurer comme un IDE léger pour Vala.

Oui c'est vrai qu'avec les descriptions que j'ai donné, Emacs est plutôt un IDE. Pourtant on le présente plus comme un éditeur de texte, au même titre que Vim. La différence entre Emacs et Eclipse est le fait qu'Eclipse a une GUI, tandis qu'Emacs s'utilise plus en mode texte/commandes. C'est un autre point de différenciation, et comme je l'ai dit au début du journal, ce sont plutôt des niveaux de gris.

Dans tous les cas, Emacs est généraliste, il y a moyen de le configurer pour faire plein de tâches différentes, on est bien d'accord là-dessus.

Pas sûr qu'un éditeur de texte où le mode par défaut n'est pas l'édition de texte, soit un bon choix.

Si tu te réfères à Vi, par défaut c'est le mode d'édition de texte. Pour passer en mode insertion, il faut appuyer sur i.

Les étudiants sont sensés travailler du 19 mai au 22 août, avec une évaluation à mi-terme fin juin. Ce n'est pas un temps plein pendant toute la période, les étudiants peuvent prendre une semaine ou deux de vacances, avoir des examens, etc.

Mais dans l'unif où j'ai étudié, les examens finissent fin juin, après l'évaluation à mi-terme ! Et c'est un peu près comme ça partout en Belgique, et sans doute dans de nombreux pays européens (la France aussi ?).

L'année passée le GSoC se passait de mi-juin à fin septembre, ce qui correspondait bien à mes études (et donc j'ai fait le GSoC). Lors des évaluations des étudiants, ils ont posé comme question si les dates les arrangeaient bien. Peut-être que beaucoup se sont pleins, et donc ils sont revenus aux dates d'avant. Ou bien ils comptent alterner, pour qu'une année ça arrange bien les européens, une autre année ça arrange mieux d'autres, etc. L'idéal serait d'avoir un système plus flexible, où chaque étudiant choisis les dates parmi plusieurs choix (mais pour l'organisation ce serait plus difficile).

(il n'a quasi pas de dépendance)

Ça aurait été mieux d'avoir une dépendance à GtkSourceView au lieu d'avoir une copie des sources d'une très vielle version, sans doute contenant des bugs qui ont été corrigés upstream…

Il innove sur le design, j'imagine.

Sinon, pour l'avoir implémenté, la recherche (et remplacement) par regex est mieux que dans Vim, en tout cas pour certains aspects : les occurrences peuvent faire plusieurs lignes ; et il y a le report d'erreurs dans l'UI quand une regex ou le texte de remplacement contient des erreurs de syntaxe ; une fois que les occurrences sont trouvées dans le text buffer, les emplacements sont retenus, il ne faut plus refaire de recherche pour naviguer dans les occurrences.

Une solution serait d'utiliser plus de composants de GNOME, au lieu de réinventer la roue dans Xfce.

Quand on installe Xfce dans Debian ou Fedora, on se retrouve avec plein d'applications différentes que celles de GNOME. Les applications GNOME pourraient être installées à la place.

Pour le window manager, ça doit être faisable de réutiliser mutter à la place de Xfwm4. Xfce profiterait ainsi du portage de mutter à Wayland.

Pour le stockage des paramètres, GSettings et dconf feraient très bien l'affaire. Pour la configuration du desktop, celui de GNOME pourrait être utilisé, avec peut-être quelques modifications.

Les devs d'Xfce pourraient ainsi se concentrer sur le panel, les applets, et quelques autres modules. Ça remplacerait en quelque sorte le mode fallback de GNOME 3. On pourrait reprendre les bonnes idées de gnome-shell pour les amener dans un bureau traditionnel, comme la meilleure gestion des notifications.

Mate a forké l'ensemble de Gnome 2, incluant aussi les applications. C'est beaucoup plus sein d'esprit de « simplement » continuer à maintenir gnome-panel, metacity, gnome-applets, et les autres modules qui vont avec. Rien qu'avec ces modules-là, il y a déjà beaucoup de travail de maintenance. Alors avec l'ensemble de Gnome, c'est de la pure folie.

Mais comme dit le monsieur en haut, les développeurs de Mate reviennent à la raison il parait.

CentOS est donc en quelque sorte une Fedora LTS (long term support).

La question était plutôt quel terme on utilise dans une discussion.

En français, on a la chance de ne pas avoir le même mot pour libre et gratuit. En anglais, le mot « libre » est aussi utilisé. Par exemple « libre software », ou « free/libre software ».

Et avec des applications comme LibreOffice, il faut espérer que le mot libre rentre plus facilement dans le vocabulaire des anglophones (pour les adeptes du libre en tout cas).

Entièrement d'accord. Il parait que GObject en C++ vérifie plus de choses à la compilation.

(l'exemple est assez ancien, GtkObject et GtkSignal n'existent plus depuis un bon bout de temps, mais les principes restent valides)

On peut espérer dans le futur avoir des plugins pour GCC ou Clang pour faire ce genre de vérifications. Et un développeur a justement commencé ce boulot récemment pour Clang.

Le style épuré du Python vient principalement du fait que ce n'est pas un langage à typage explicite. Étant donné que le type d'une variable est une forme d'auto-documentation, je ne vois pas où est l'avantage.

Au lieu de fixer un langage qui n'est pas bien conçu dès le départ (pour des grosses applications), c'est plus intéressant de créer un nouveau langage. Rust est un excellent exemple, puisque le compilateur fait plus de vérifications que pour le C.

TypeScript (pour JavaScript) et mypy (pour Python) démontrent bien que des gens sont intéressés par le typage statique, tout en bénéficiant de fonctionnalités de haut niveau.

Mes questions posées dans le journal ainsi que dans ce thread restent toujours sans réponse… J'ai pu aussi remarquer quelques moinssages du journal. Ce qui prouve sans doute que certains ne sont pas d'accord (alors que marquer un journal comme « inutile » est différent de marquer son désaccord).

Comme dirait je ne sais plus qui, « On a toujours tord d'avoir raison trop tôt. »

On en reparle dans 20 ans :-) ?

Intéressant, en effet.

TypeScript is designed for development of large applications

Ça confirme mon point de vue.

Quoi qu'on en pense, Microsoft est assez bon dans les langages de programmation. Je n'irais pas à dire que Visual Basic est bien, il faut quand même pas exagérer. Mais C# et .NET ont l'air bien foutu. Et des initiatives comme TypeScript est une bonne idée aussi je trouve.

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.