Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Mars 2021 -
Sommaire
Bonjour à tous
Le 10 février dernier, pris de nostalgie et d'ennui, je me suis lancé dans un projet un peu fou, probablement inutile et vain (donc indispensable) : faire revivre un projet auquel j'ai beaucoup contribué à une époque mais que j'ai perdu de vue ces dernières années. Le projet en question est complexe et volumineux puisqu'il s'agit de Calligra, la suite bureautique du projet KDE. Ayant été co-mainteneur de Calligra Words, je me focaliserai surtout sur ce dernier.
Histoire du projet
Calligra est né en 2010 d'un fork de KOffice par la majorité de l'équipe suite à un désaccord interne. Défaut usuel de gouvernance d'un projet libre : difficile d'éjecter une ou deux personnes, donc tout le monde est parti avec un clone du code voir ailleurs si l'herbe y était plus verte, et elle y était. À l'époque, beaucoup de gens contribuaient à Calligra, et pas mal de gens rémunérés par notamment Nokia (par l'intermédiaire de Ko Gmbh) qui voulait une suite bureautique pour afficher des documents sur sa nouvelle plateforme Meego… Si la communication avait été meilleure des deux côtés, j'eus même pu avoir en premier emploi de ma carrière un poste de développeur chez Ko…
Puis vint 2011 et l'Elopcalypse : un gradé de Microsoft prend le contrôle de Nokia, annonce que «même si le N9 rencontre un succès, on ne fera pas de suite» et décide que l'avenir de Nokia est le Windows Phone… C'est dans une ambiance morose que nous faisons fin 2011 le dernier sprint Calligra de la grande époque, invités dans les locaux d'un Nokia à la dérive, avec nos interlocuteurs en mode, je cite, «distribuons l'argent tant qu'on en a encore»…
Les années suivantes sont délicates : pour ma part, pour des raisons personnelles (santé) et professionnelles (travail chronophage), je m'éloigne du projet… les développeurs salariés ne le sont plus, les contributions chutent très vite : de 8000 à 9000 commits par an, on chute à 3000 commits. Seuls deux projets intégrés à la suite vivent encore, Krita et Kexi.
En 2015, ces deux logiciels décident d'aller vivre leurs aventures de leur côté : leurs objectifs sont différents de ceux du reste du projet, et ils ne peuvent se ralentir en ayant à maintenir tout le reste de la suite bureautique. Le passage à Qt5/KF5 est à l'horizon (KF 5.0 est sorti en 2014), ils ne peuvent en assumer le poids à eux seuls.
En 2017, c'est une équipe restreinte qui sort Calligra 3.0, première version Qt5/KF5, privée de certains outils par manque de mainteneurs et de temps, mais qui reste fonctionnelle. Il n'y a plus que 400 commits par an, et la chute continue : 238 en 2019, 194 en 2020…
Bref, le projet est dans le coma, alors essayons de lui donner un choc, on verra si ça reprend.
Résurrection
Environnement de travail
Bon, Calligra est un projet à base de technologies KDE… donc j'utilise l'environnement de développement KDevelop, qui s'est bien bonifié avec sa version 5. Je clone le projet depuis mon bon vieil alias git kde://calligra et… ha… non, ils sont passés à gitlab… dans un sens je préfère, les anciens outils étaient pas intégrés et ça posait franchement des soucis.
Donc je clone le projet, je l'ouvre dans KDevelop, je demande une compilation et… non, ça marche pas, ninja râle…
Premier patch…
Pourquoi ninja ? Et pourquoi râle-t-il ? Alors moi je dis pourquoi pas pour ninja, je m'en fous à vrai dire, mais c'est supposé marcher, donc qu'il ne marche pas n'est pas acceptable. Il se plaint d'avoir deux cibles avec le même nom sur le projet. Allons bon…
Ce sera donc le premier patch, très simple : https://invent.kde.org/office/calligra/-/commit/5866cef575c92803ff6970eaeb608602b9bec5b6
Première compilation
Ouch… l'arbre de noël… ça fait des warnings dans tous les sens ! Mais méchamment… D'où ça vient ?
Le port à Qt5/KF5 a été fait, oui. Il est fonctionnel, oui. Mais Qt 5 a gardé des éléments de compatibilité avec Qt 4, et au fil des années des méthodes ont été dépréciées en faveur d'autres. De plus, le langage C++ a évolué, avec C++11 et C++14 des constructions ont été largement simplifiées, des éléments sont recommandés pour fiabiliser le code (le mot clef override par exemple).
Où en est Calligra dans ses pré-requis, pour savoir quoi éliminer ?
set(REQUIRED_KF5_VERSION "5.7.0")
set(REQUIRED_QT_VERSION "5.3.0")
Qt 5.3 c'est 2014, KF 5.7 c'est 2015… Je doute que quiconque teste le projet sur ces antiquités, et je vois mal comment me restreindre à ce point (il manque au projet une CI actuellement).
Je lance donc la discussion sur la mailing list pour passer à Qt 5.9 ou 5.12 minimum, avec l'équivalent en terme de chronologie pour KF5… et dans la discussion, il apparait que ce choix «peinerait» l'un de nos clients extérieurs. Car Calligra ce n'est pas qu'un ensemble de composants finis, c'est également des briques intégrables, qui peuvent servir à construire un afficheur de documents, notamment sur mobile, comme c'est le cas sur les téléphones Jolla… qui reste en Qt 5.6 par peur de la licence (L)GPLv3…
Bon.
Pour leur faire plaisir, passons, on va se limiter à Qt 5.6 et le KF5 de la même époque, ça devrait éliminer une partie des endroits où les bactéries se déposent, mais ce sera difficile de se limiter à ça très longtemps avec l'approche de Qt 6, qui implique au moins de passer à Qt 5.15 pour limiter la taille du saut derrière.
Du coup, nouveaux patchs, pas trop compliqués…
https://invent.kde.org/office/calligra/-/commit/a48d9611b77c3d67855f0febec2891def2576c78
https://invent.kde.org/office/calligra/-/commit/afb2049d785e7db374d574e675e8ceaad1b1d606
https://invent.kde.org/office/calligra/-/commit/8a6faa4c6e23f5da197a0249a4122afdb81ae597
Ok, mais ça ne calme pas tant que ça l'arbre de Noël.
Il n'y a pas une source de warning, hélas. Pire, des choses dans le code m'inquiètent qui ne font pas de warning, notamment l'utilisation de l'ancienne syntaxe de connexion de Qt, à savoir :
connect(source, SIGNAL(mySignal()), target, SLOT(mySlot()));
Alors que la syntaxe moderne permet de faire contrôler les paramètres par le compilateur, et non pas à l'exécution :
connect(source, &Source::mySignal, target, &Target::mySlot);
Du coup, pour cela, j'ai sorti Clazy : https://github.com/KDE/clazy/
Un outil qui va automatiquement corriger tout un ensemble de bugs, en signaler d'autres que le compilateur ne va pas lever… Parce que j'avais pas encore assez d'avertissements.
Je ne vous liste pas les commits, mais Clazy a généré des milliers de correctifs sur connect, des correctifs de perfs mineurs, signalé des syntaxes obsolètes…
Corrigeons des bugs
Bon, rendre le projet plus maintenable, c'est une chose, mais il faut aussi s'occuper un peu des bugs qui trainent…
Un bug sur un filtre, pourquoi pas, c'est simple, isolé…
L'analyse a été l'occasion de remettre le pied à l'étrier, et même d'explorer un code que je n'avais pas regardé (à savoir les filtres ms office). Le fichier de test est très simple et permet rapidement de voir le problème (c'est à l'origine un rapport de bug des testeurs de Nokia d'ailleurs).
Bon… je pourrais dire que le correctif était à la hauteur de l'analyse, mais perdu… Avec gdb, je me suis rendu compte que le code dans la fonction read_background ne lisait pas l'arrière plan à cause d'un paramètre displayBackgroundShape qui n'était pas valorisé comme il faut…
Du coup, le correctif…
https://invent.kde.org/office/calligra/-/merge_requests/11/diffs
Un bug sur un autre filtre, cas simple à nouveau, mais avec un peu de windowseries, et la difficulté du format binaire historique de Word…
Donc on reproduit le fonctionnement : trouver le code incriminé, le lire… et en déduire que c'est juste des encodages non gérés… Facile à nouveau…
https://invent.kde.org/office/calligra/-/commit/be82faae699790e8b5d4f68a2e9e2663ff40477e
En 2014, un plugin Okular a été ajouté dans Calligra pour donner à Okular un affichage bien plus complet pour les fichiers OpenDocument. Manque de bol, une fuite mémoire assassine les performances.
Je m'apprête à une recherche compliquée, sortir valgrind… Je teste le plugin Okular, et effectivement, ça fuit. Enfin. Non. Ça explose façon challenger.
J'ouvre le code pour une première imprégnation, et j'en déduis que ce code n'a jamais été relu ni testé sur plus que «ça affiche = ça marche»…
https://invent.kde.org/office/calligra/-/commit/3e3b602aff077e189d2d38826f38fcc8a9e1e486
Et la suite…
J'ai pas fait que ça ces dernières semaines sur Calligra. J'ai aussi travaillé sur des trucs qui m'ont concerné, comme https://invent.kde.org/office/calligra/-/commit/94c7e8fdc7fec0a51cfb2ebe88595712fc7e67e5 qui corrige un vieil ennemi personnel qui est revenu me hanter lorsque j'ai essayé un document Word que je n'arrivais pas à lire dans LibreOffice et qui marche parfaitement dans Calligra, na. Également, un peu de refactoring, l'introduction de nouveaux tests unitaires qui remplacent des fichiers de test perdus il y a plus de 15 ans…
J'espère continuer comme ça les prochaines semaines. Déjà parce que ça m'amuse, mais aussi parce que j'espère qu'en forçant de l'activité sur le projet je pourrai redonner à des gens envie de venir contribuer. C'est loin d'être difficile. Le code est bien découpé, assez bien organisé, avec plein de choses à faire qui ne sont pas nécessairement compliquées.
Il faut que j'arrive à faire marcher une CI digne de ce nom, pour m'assurer que les prochains commits n'introduisent pas de régression et pour faciliter l'arrivée de nouveaux développeurs.
Puis ça reste une suite bureautique largement moins lourde que LibreOffice. Sur mobile, notamment Plasma Mobile, ça me semble bien adapté… Et je me dis qu'on pourrait aussi en faire quelque chose couplé à Nextcloud notamment…
Commentaires :
voir le flux Atom
ouvrir dans le navigateur
LinuxFr.org : Journaux
Téléphone sous Linux ?
- 25 avril -
Aujourd'hui, avoir un téléphone avec un Android libéré, c'est possible, on pense en particulier à Murena.Avoir un téléphone sous GNU/Linux, c'est (...)
Quand votre voiture vous espionne… et vous le fait payer
- 23 avril -
Ceci se passe aux États-Unis, pour l’instant, aucune preuve qu’une telle fuite existe en Europe. Mais… si votre assurance augmente brutalement, (...)
firefox, nouvelle fenêtre dans une session isolée
- 15 avril -
Les fenêtres de navigation privées de firefox partagent leurs cookies de session or je souhaitais avoir des fenêtres de navigation isolées, (qui ne (...)
Pretendo tente de déprogrammer l'obsolescence des consoles Nintendo
- 9 avril -
Ah Nal,Gros N vient de faire un gros doigt aux utilisateurs de ses consoles 3DS et Wii U en annonçant la fermeture des services en ligne pour (...)
[Trolldi] Vulgarisation sur l'IA pour décideur pressé
- 5 avril -
Cher 'Nal,Je fais un article-marque-page sur un post tout frais de Ploum où il est question d'un fantasme vieux comme le Talmud avec le Golem. (...)
