Sommaire
Cher journal,
En ce jour pluvieux, je profite de réécrire un rapport au sujet de mes contributions au monde open-source.
Le dernier que j'ai écrit date déjà de janvier dernier, je ne vais donc pas aller dans les détails. Je me rends compte d'ailleurs, que d'après mon gitlab, j'ai eu pas mal d'activités, mais je ne me souviens pas de tout :)
Depuis février, je travaille à 80% (ce qui fait environ 33 heures par semaine pour mon contrat). Le lundi, je peux donc passer du temps avec ma fille de 6 ans et, pendant ses cours, prendre un peu de temps pour coder 2-3 trucs open-source. C'est un rythme que j'aime bien et que je compte garder encore quelques temps.
HomeBank
Depuis mon dernier rapport, j'ai reçu les retours de Maxime Doyen pour ma demande de fusion. J'ai modifié le code pour suivre ces très bonnes suggestions et le code est disponible dans la pre-release 5.3 sortie en octobre dernier.
Pour la version 5.3, Maxime m'a demandé d'activer uniquement la visualisation du budget sous forme de tableau. Pour les plus motivés, vous pouvez récupérer les sources du code et modifier la macro HB_BUD_TABVIEW_EDIT_ENABLE dans le fichier ui-budget-tabview.h pour activer l'édition du budget directement dans le tableau. Mais attention, l'édition est expérimentale car je ne l'ai testée qu'à la main sur mes données.
Ibex
J'ai continué un peu le développement d'Ibex, un projet que je voulais faire pour expérimenter le C++, Gtk 3 et XMPP. Malheureusement, le C++ ne sait pas encore utiliser les introspections de Gtk3 et je me suis retrouvé à dépendre de tout un tas de projets qui créent à la main les bindings pour les APIs de Gtk 3 (gtkmm, glibmm…).
Pour les APIs les plus connues qui sont maintenues, ce n'est pas un problème. Ce qui est dommage, c'est que certaines APIs que j'avais besoin ne proposent plus ces bindings manuels (libsoupemm est dans les archives de GNOME).
J'ai entendu parler du projet cppgir pour justement utiliser l'introspection pour remplacer les bindings manuels, mais je n'avais pas réussi à l'utiliser. Je ne me suis pas attardé très longtemps, car je ne comprends pas bien comment fonctionne l'introspection ni cppgir. J'espérais voir de la documentation ou des tutoriels fleurir, mais je n'ai pas trouvé beaucoup d'activité autour de ce projet depuis novembre 2018.
acme-dns-tiny
Pour ce projet, j'ai effectué simplement de la maintenance pour la fusion des corrections proposées. Je l'utilise encore, mais comme le RFC d'ACME est sorti en version stable, je pense qu'il n'y aura plus beaucoup de développement à faire.
LinuxFr
J'ai utilisé pas mal de mon temps libre pour hacker LinuxFr: je trouve Ruby on Rails vraiment sympa et j'ai pu faire pas mal de tests.
J'ai d'abord fait quelques petites modifications, comme: mettre à jour le logo de KDE dans les sections, autoriser le schéma tel: pour les liens, documenter l'installation sur Debian Stretch, l'ajout des icônes de téléchargement pour les sources. Avec ces modifications, j'ai compris que je ne pouvais pas utiliser des outils trop récent comme le layout avec les grilles CSS. Du coup, je me suis mis comme limite de support dans le temps Internet Explorer 10 (qui est sorti en 2012) et j'ai découvert que ce navigateur, bien que vieux, me permet déjà d'utiliser les flexbox pour implémenter des règles de design plus fluides et réactives aux changements de tailles d'écran.
Je voulais ensuite implémenter le nouveau design proposé par mjourdan. J'ai réussi à faire une preuve de concept, comme je l'ai annoncé en juin. Comme les changements étaient très nombreux, grâce aux nombreux retours de Mathieu, j'ai décidé de couper en plusieurs parties les changements.
D'abord, j'ai intégré les nouvelles polices Merriweather et Lato qui était proposées par la maquette. Je me suis un peu planté sur les règles CSS pour intégrer ces nouvelles polices d'écriture, ce qui a permis d'avoir rapidement plein d'avis, désolé 😅
Ensuite, j'ai repris le design en 3 colonnes de la preuve de concept pour l'espace de rédaction. Malheureusement, les rédacteurs nous ont fait remarqué que ça ne marchait finalement pas si bien: il y avait assez peu de textes affichés, ça ne marchait pas bien quand le navigateur n'était pas maximisé ou quand on zoom sur le texte 😑
Pour pouvoir faire plus de tests avant de fusionner mes changements, j'ai monté un site de développement [https://dlfp.adorsaz.ch] pour permettre à Mathieu et aux autres de tester correctement les modifications proposées. Grâce à ça, on a pu faire plusieurs essais pour remplacer le design en 3 colonnes avec un design en 2 colonnes plus proche de ce qui existait avant, mais plus joli.
A titre de comparaison, voilà des captures d'écran qui permettent de comparer avant / après nos modifications:
| Fin 2018 (commit 340eacd) | Fin 2019 (commit 069d28) |
|---|---|
 |
 |
Je trouve que Mathieu et moi avons réussi à avoir finalement un assez bon résultat 😃
Mon souhait aurait été de terminer l'intégration des images d'illustrations dans les dépêches pour 2019, mais je pense que ça arrivera début 2020.
Avec tout ces changements, les feuilles de style CSS autres que celle par défaut, Ronronnement, sont cassées pour l'espace de rédaction.
Quand on va intégrer les images dans les dépêches, je pense qu'il va falloir définitivement supprimer les autres feuilles de styles, car je ne pourrais pas toutes les faire évoluer en même temps.
GNOME et gitg
Enfin, j'ai eu le temps de m'amuser à proposer 1-2 corrections au projet gitg. Ca m'a fait bizarre d'ouvrir mon compte sur le Gitlab de GNOME pour contribuer, c'est chouette ! N'empêche avec Gnome Builder, Gitlab, Flatpak, Meson et Ninja, GNOME a fait d'énormes progrès pour aider les nouveaux contributeurs à modifier les projets. Avant, je me souviens avoir juste essayé de construire un des projets de GNOME avec jhbuild et de l'exécuter. C'était hyper difficile à l'époque, car, selon le projet, il fallait quasiment compiler GNOME au complet pour pouvoir le démarrer. En plus, si on arrivait à passer à la suite ou si on voulait proposer des suggestions, il fallait passer par l'interface vieillote de Bugzilla.
Maintenant, avec Flatpak et Gnome Builder, il faut cloner le projet, patienter un peu que le bon SDK est téléchargé et cliquer sur Run. Le projet est compilé hyper rapidement (merci Meson et Ninja !) et s'exécute facilement ! Je confirme donc que leur guide du nouveau contributeur est beaucoup plus simple.
Bref, je voulais encore m'amuser un peu avec Gtk et je voulais corrigé 1-2 trucs dans gitg. Le projet est à nouveau actif et évolue bien. J'ai pu corrigé un bug ou un bouton disparaissait dans gitg après la recherche de projet. Je voulais aider un peu pour l'interface de recherche en ajouter des boutons Précédent et Suivant dans la barre de recherche, mais ça a été malheureusement refusé.
Conclusion
Quand j'ai commencé à écrire ce journal, je ne pensais pas avoir autant à écrire, bravo aux lecteurs qui ont tout lu !
Je suis vraiment content de cette année, je me suis bien amusé et j'ai l'impression d'avoir pu aider les projets à avancer un peu 😃
# Merci
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Merci pour ces contributions, bien évidemment pour LinuxFr.org, mais je trouve ça génial de voir un compte-rendu de contributions à divers projets libres. Bref, juste merci.
[^] # Re: Merci
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
De rien :)
Pour LinuxFr, c'est agréable d'être entouré d'une bonne équipe: Mathieu trouve de bonnes idées d'améliorations et de test et Bruno réagit vite aux demandes de fusion et donne de bons conseils.
Ça prend un peu de temps à écrire les comptes rendus, mais c'est assez chouette pour moi aussi de voir ce qui s'est passé.
[^] # Re: Merci
Posté par raphj . Évalué à 3. Dernière modification le 02 décembre 2019 à 20:44.
Je me joins à Benoît pour les remerciements, d'autant que j'ai fait partie des gens qui ont un peu râlé sur l'utilisation des polices web quand c'est arrivé.
[^] # Re: Merci
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1.
Pareil que raphj en fait.
Un grand merci pour tout.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Gtk et le C++
Posté par Philippe F (site web personnel) . Évalué à 8.
Je me lance, ca fait une bonne quinzaine d'année qu'on s'est pas fait un petit flamewar sur Gtk vs Qt vs C++, ça me rappellera mes brulures de jeunesse !
L'ex-développeur de GtkMM Guillaume Laurent m'avait expliqué à une époque que Gtk souffrait d'un vrai handicap pour la génération de binding: le C qui est utilisé pour décrire l'ensemble des widgets et autres éléments de Gtk n'est pas un langage suffisamment expressif pour en générer automatiquement une version C++. Il faut un travail manuel considérable d'annotation et d'aide au générateur pour arriver à une solution qui se tienne. La conséquence est que ce travail a eu tendance à épuiser les mainteneurs motivés et que GtkMM a souvent été fortement à la traîne de Gtk, le rendant au mieux difficilement utilisable en dehors des widgets très standards et au pire, inutilisable.
A jeter un coup d'oeil sur le site, cela n'a plus l'air d'être le cas aujourd'hui mais ton commentaire laisserai entendre que si en fait.
Un autre handicap de gtkmm, c'est clairement que les dév qui aiment bien Gtk ne sont absolument pas attiré par le C++. Il faut une combinaison assez particulière de développeur aimant bien Gtk et le C++ pour travailler ou utiliser Gtk. C'est peut-être un peu moins vrai aujourd'hui où le C++ a gagné des lettres de noblesses même dans le monde du logiciel libre.
A l'inverse, Qt bénéficie de pas mal d'avantages pour la génération de binding: le C++ et les classes de retour gérant la mémoire intelligemment (du type QString) fournissent une information suffisamment riche pour automatiser une grosse partie du travail. C'est ce qu'a fait Phil Thompson pour les binding Python-Qt et Richard Dale pour tous les autres (KDE principalement). PyQt bénéficie d'un autre très gros avantages: Phil Thompson a basé une partie de son business de consulting dessus, ce qu'il fait qu'il maintient ça depuis 15 ans avec une régularité et une rigueur qui m'impressionnent. Toutes les versions de Qt sont supportées dans la semaine qui suit et les bindings manquants concernent des parties de Qt vraiment peu utilisées.
L'outil qu'il utilise pour générer ses bindings - sip - a même été repris par WxPython pour refondre les binding vers WxWidget en Python 3 (projet Phoenix).
Du coup, si tu aimes le C++, mieux vaut rester côté Qt. Et j'en dira autant pour le Python sans prendre un gros risque.
[^] # Re: Gtk et le C++
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Merci beaucoup pour ce retour, c'est intéressant.
Mon objectif était d'apprendre le C++-17 avec la création de ce nouveau projet. Comme j'avais déjà pas mal jouer avec Glib/Gtk récemment, je voulais l'utiliser pour la Gui simplement.
Si j'ai bien compris, un des grands intérêts d'utiliser Gtk 3, c'est que cette version implémente Gobject Introspection. Cet outil devrait permettre de ne plus avoir besoin de faire manuellement les binding dans le langage cible (comme tu expliquais que c'était le cas pour le C++ gtkmm, glibmm…).
En fait, ça définit la syntaxe d'un fichier
.girqui expose l'interface de manière abstraite du langage d'implémentation (C en l'occurrence pour Gtk). Ce fichier est généré directement par le projet source (donc Gtk).En lisant ce fichier avec un programme (
cppgirpour le C++), il serait possible de générer de manière automatique les interfaces dans le langage cible (ici, C++).Donc, en théorie,
cppgirdevait résoudre mon problème, mais je n'ai pas réussi à l'utiliser :-) Peut-être qu'on ne peut pas faire de C++-17 avec, je ne sais pas.[^] # Re: Gtk et le C++
Posté par Philippe F (site web personnel) . Évalué à 4.
Je vais pas être la bonne personne pour te répondre sur des questions spécifiques Gtk / C++. La seule chose que je peux dire, c'est qu'entre la théorie "Gtk 3 a de l'introspection donc gtkmm peut profiter de tout ça" et la pratique, il y a beaucoup d'efforts. Le site web de gtkmm donne peu d'informations qui permettraient de savoir si le boulot a été fait ou pas.
Mais si tu veux vraiment faire du C++, mieux vaut quand même choisir un toolkit nativement C++. Les bibliothèques adaptées dans un autre langage tendent à conserver beaucoup de modèles de conception du langage originel et restent un peu étranges dans le langage cible.
Typiquement, pour bouffer du C++ moderne, va voir du côté de chez Boost, une partie de leur travail à pour volonter d'être réintégrer dans le standard C++. Ils adorent le C++ moderne (que je trouve plutôt imbitable perso). Un coup d'oeil rapide me montrer une lib C++ pour faire du GUI: https://github.com/kosenko/ui .
# Ronronnement
Posté par Anonyme . Évalué à 4.
Sans vouloir remettre en cause les efforts que tu as fait (merci pour ce que tu fais pour DLFP), je trouve le nouveau style peu lisible. Tout est trop gros et, en même temps, les polices sont trop « fine » (je sais si c’est le bon mot).
Du coup, je suis passé (retourné) sur
RonRonnement-Classicet, effectivement, l’espace de rédaction n’est plus utilisable.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.