swilmet a écrit 647 commentaires

Il y a plus de détails dans cet article écrit récemment.

Pour ajouter des infos, créer un projet C++ en GTK demande d'avoir les bindings C++ pour une partie de la GLib aussi (glibmm). Quand une fonction de GTK prend en paramètre ou retourne une structure de donnée définie dans la GLib, il faut que ce soit utilisable de manière pratique en C++ aussi.

À la fois GTK 2, 3 et 4 dépendent de la GLib 2. Au plus on avance dans les versions de GTK, au plus on dépend de fonctionnalités plus récentes de la GLib (dont des bindings C++ sont donc requis).

Mais, GTK 2 et 3 n'évoluent plus. Ces versions de GTK ne dépendent pas des toutes dernières nouveautés de la GLib. Et je suppose que gtkmm, glibmm, etc couvrent assez bien toutes les API (en ce qui concerne GTK 2 et 3).

En ce qui concerne GTK 4, c'est bien sûr une autre histoire.

Ce qui veut dire que les projets C++ utilisant GTK 2 ou 3 ne se sentent pas forcés d'aider à la maintenance de gtkmm etc (chose qui peut-être ne leur sera jamais utile si le projet ne migre pas à GTK 4).

Il y a aussi Ardour comme gros projet en C++ et GTK (mais c'est du GTK 2).

Oh, les journaux ne se limitent pas à l'informatique et le logiciel libre, on peut - de temps en temps - parler d'autres choses, écrire une petite nouvelle de science-fiction, parler de livres à lire (romans), H2G2 et autres :-)

Je pense à ça qui est en phase de développement :

https://www.whist.com/

Un nouveau navigateur web ("cloud-powered Chrome").

Et, maintenant que j'y pense, voir aussi :

https://drewdevault.com/2021/01/04/A-culture-of-stability-and-reliability.html

(qui je pense s'applique en partie à fontconfig).

Et, maintenant que j'y pense, c'est sans doute mieux un modèle comme ça qu'un modèle à la npm.

Effectivement, ça peut poser problème. Heureusement, certaines distributions n'hésitent pas à prendre une version de développement de fontconfig, ou en tout cas faire du cherry-picking de certains commits.

Je vois par exemple du côté de Fedora :
- https://koji.fedoraproject.org/koji/packageinfo?packageID=174
- https://koji.fedoraproject.org/koji/buildinfo?buildID=1786608

Avec dans le Changelog (mais en 2020) :

cherry pick some upstream patches

---

En ce qui concerne le peu de contributions, je pense que c'est pcq les développeurs sont occupés à développer des trucs au-dessus, et comme fontconfig fonctionne bien, qu'il n'y a pas (trop) de bugs, ou des bugs qui ne les concernent pas, alors ils ne pensent pas à améliorer fontconfig.

C'est le problème des logiciels libres qui fonctionnent (trop) bien, où il n'y a quasi aucuns bugs, et qui ont suffisamment de fonctionnalités. C'est à croire qu'il faut faire exprès d'introduire un bug, pour avoir des contributeurs en plus.

Oui, c'est pareil quand on utilise l'option --filter, par exemple :

#!/bin/sh

src='/home/foo'
dest='/run/media/foo/backup/home-foo'

rsync --archive --delete --force --progress --stats \
        --filter '- /foo/.cache/'                   \
        "$src" "$dest"

(version simplifiée d'un de mes scripts de backup).

--filter '- foo/.cache/' ou
--filter '- .cache/' n'ont pas le même effet.

C'est prévu qu'il y ait du développement (par Red Hat) pour mieux intégrer systemd-homed dans GNOME et Fedora, pour que ça Juste Marche™.

Voir cet article du blog de Christian Schaller (comme d'habitude en ce qui concerne GNOME && Fedora).

En attendant, c'est comme au bon vieux temps où il faut bidouiller avec son système Linux :-)

Profil Guided Optimization (PGO) et JIT (compilation Just In Time) ne sont pas la même chose.

Basé sur un profil, ça veut dire que ça se base sur les exécutions précédentes du programme. Il y a des patterns d'exécution qui sont les mêmes d'une exécution à une autre, donc autant optimiser ces parties-là. Surtout pour des programmes batch.

En tout cas c'est comme ça que je le comprends.

Pour WSL (Windows Subsystem for Linux), du PGO est aussi à l'ordre du jour pour le kernel Linux. On verra donc peut-être ça débarquer dans certaines distribs Linux classiques :-) (c'est drôle pcq Microsoft emploie des développeurs pour Linux et la GNU toolchain, chose inimaginable il y a une décennie).

Bien que je ne m'y connaisse pas dans tout ça, je sais juste que le support pour HDR est dans le pipeline de l'équipe desktop de chez Red Hat (de manière générale dans GNOME, pas GIMP en particulier, je présume). Voir cet article de blog et Ctrl+F "HDR".

Sinon lire les 3 pages de la table des matières du PDF, ça résume sans doute bien les fils de discussion twitter (mais c'est de l'anglais juridique).

Et lire les 173 pages du PDF (surtout que c'est du droit américain), ça n'aide sans doute pas pour la décompression.

Il manque un c dans le titre ;-)

GLib fait partie du projet GTK et GNOME.

glibc, ou GNU libc, c'est plus bas niveau, c'est l'implémentation GNU de la bibliothèque standard du langage C.

• Il y a Qt, qui fonctionne du tonnerre de Zeus (le cours de l'action a fort grimpé).
• SUSE qui s'est lancé récemment.
• Red Hat à l'époque qui a fort grimpé, puis racheté par IBM comme vecteur de croissance pour le mastodonte qui stagnait un peu.

J'en connais pas des masses, en connaissez-vous d'autres ? Qui font (principalement) du logiciel libre, bien entendu.

Je vois que je ne suis pas le seul dont ce journal interpelle.

Étant belge (province du Brabant-Wallon), j'ai une envie d'agir au niveau local au sujet du déploiement de LibreOffice et de la bureautique libre au sens plus large.

Pas qu'au sein des écoles et de l'éducation, mais au sein de n'importe quelle organisation qui déploie un parc informatique (à usage bureautique), ainsi que pour les citoyens, etc.

Il y a beaucoup à faire, et je sais qu'il existe déjà les différents LUGs et l'InterLUG belge (regroupement des LUGs). (Je fais partie du LouviLUG, toujours un peu actif).

Il faut selon moi créer une sorte de carrefour, pour mettre en lien différentes organisations et différentes personnes. Créer des ponts, à un niveau plus ou moins local. Entre organisations, entre citoyens, entre informaticiens, vers les politiciens, vers les médias, etc (cibler différents publics).

Par exemple :
- Avoir une liste d'entreprises de consultance belges spécialisées en déploiement de LibreOffice, du desktop Linux, etc. Plus d'autres acteurs européens actifs dans ce secteur (SUSE, Canonical, Collabora, …).
- Poster des annonces d'organisations qui cherchent des informaticiens ayant des compétences en LibreOffice, desktop Linux, etc.

Il y a Collabora Office, qui a des partenaires un peu partout dans le monde. Il y a les différentes certifications LibreOffice. Il y a SUSE, la plus grosse entreprise Linux européenne.

Étant donné que le sujet trotte dans ma tête depuis un certain temps, ce journal LinuxFr a été le coup d'envoi pour que je crée, hier, ce nouveau site web :

https://informatique-libre.be/

(Attention, c'est une ébauche, un prototype, work-in-progress, release early, release often, appelez ça comme vous voulez. Il manque bien évidemment beaucoup beaucoup de choses).

Mon commentaire ici décrit en partie ce dont je souhaite élaborer dans le site web, les idées sont encore vagues. Mais j'ai en ce moment du temps. Le « .be » est volontaire, c'est pour agir au niveau local, comme vous l'aurez compris ;-)

Autre idée, ce que je compte faire prochainement aussi, c'est postuler, envoyer des candidatures spontanées vers des écoles ou autre (pour s'occuper du parc informatique), avec comme titre du mail et du CV « Informaticien - logiciel libre », quelque chose comme ça. Qui sait, on me répondra peut-être un an plus tard, et si je ne suis plus disponible sur le marché de l'emploi à ce moment-là, je peux diffuser l'offre d'emploi autour de moi (sur le site web ci-dessus, ou s'il n'existe plus, vers les LUGs ;-).

Autrement dit, si le marché n'existe pas, s'il y a une ou plusieurs structures manquantes, il faut les créer !

Caml qu'on m'a forcé à apprendre durant mes études

Pour ma part c'était Oz, qui supporte aussi le pattern matching (depuis longtemps).

Super dépêche, bien écrit, pas trop long.

Et moi qui suit sur SLE depuis moins d'un an, j'ai appris des choses. (L'abonnement pour le desktop est abordable, 50€/an, et ça permet de contribuer financièrement au desktop Linux qui en a bien besoin).

L'entreprise SUSE a aussi fait une introduction en bourse récemment.

PipeWire est sûrement déjà dispo et empaqueté dans la plupart des distributions Linux, oui. Mais peut-être pas une version suffisamment récente pour l'audio, pcq PipeWire était déjà utilisé depuis quelques années pour la vidéo (screencast notamment) dans Gnome.

De plus il faut que le paquet à installer en plus (si PipeWire pour l'audio n'est pas la config par défaut) soit correctement empaqueté pour faire le basculement de PulseAudio vers PipeWire (je pense aux services systemd).

Bref, dans tous les cas il faut se référer à la doc de la distrib Linux qu'on utilise. Mais si ça devient un peu galère, autant passer à une distrib ayant déjà sauté le pas pour la config par défaut.

(sans parler de l'éventuelle config d'autres paquets faisant partie de la distrib, peut-être le kernel doit être configuré un peu différemment, etc ;-) ).

Tout est dans le titre ;-) Donc merci pour ces très bonnes explications.

Pour néanmoins trouver une piste de solution :
- Chercher dans les bugtrackers et mailing lists de différents logiciels libres relatifs au scannage de documents (sane et simple-scan me viennent à l'esprit) ou alors les logiciels qui travaillent directement avec le format PDF (donc s'adresser aux développeurs upstream qui connaissent et ont touché à la spec PDF). Si aucune info trouvée, rapporter un bug / demande de fonctionnalité en espérant avoir une réponse (même si la réponse ne vient que 5 ans plus tard, avec la fonctionnalité implémentée dans un autre logiciel 5 ans encore après, c'est mieux que rien (expérience typique)).
- Avec peut-être une chance de trouver un bout de script quelque part bien caché au fin fond du web^W^W de GitHub ;-)

PipeWire est justement la nouvelle technologie sous Linux qui règle tous ces problèmes. Le son "normal" (venant de youtube pour reprendre ton exemple) utilise PulseAudio (plus précisément : ça utilise l'API de PulseAudio, qui est implémenté par le démon PulsoAudio ou le démon PipeWire).

Je ne pense pas que pop os utilise déjà PipeWire pour le son.

Il te faut peut-être une autre distribution Linux. PipeWire a été développé en très grande majorité par un employé de Red Hat, et je sais que la dernière version de Fedora est passée à PipeWire pour l'audio (et Fedora est une distribution Linux faisant partie de la "famille" Red Hat).

Mais il y a sûrement d'autres distributions Linux qui sont aussi passées à PipeWire pour l'audio, il n'y a pas que Fedora (ou alors c'est juste un paquet à installer en plus).

Peut-être que PipeWire (même sur la dernière Fedora) est encore un peu jeune pour l'audio, mais en tout cas c'est à essayer ;-)

Un livre qui explique entre-autres le "Separation of concerns" (et plein d'autres choses intéressantes) :

Feature-Oriented Software Product Lines: Concepts and Implementation

Je recommande vivement ! Ce livre a influencé mes contributions à GNOME il y a quelques années, dans le domaine des éditeurs de texte et outils de développement.

J'ai un mal fou à comprendre pourquoi l'article parle de DNF (le gestionnaire de paquets de Fedora) au lieu de Zypper.

Auto-réponse : https://www.niallkennedy.com/blog/2006/11/feed-publishing-best-practices.html

ça ne doit pas avoir fort changé depuis 2006, ce côté-là du web.

Un peu hors sujet, je profite de l'occasion pour demander lequel est le mieux (le plus simple, le plus moderne, etc) : RSS ou Atom ?

J'avais un vague souvenir qu'on dit toujours "RSS", un peu comme MP3, mais qu'il existe Atom qui est préférable de nos jours (et depuis sans doute déjà une bonne quinzaine d'année).

Me trompe-je ?

Yep, je suis d'accord que d'avoir une application lancée pour le C++, et une autre pour CMake, c'est pas terrible à l'usage.

Imaginons que pour CMake la GUI aurait un intérêt d'être différente (plus simple, sans doute), que pour éditer du C++. C'est bien je trouve d'avoir des GUI spécifiques pour un usage particulier (menu et barre d'outils avec contenu différent selon le contexte).

Le truc c'est que, habituellement, les onglets pour ouvrir plusieurs fichiers dans une même fenêtre se trouvent en-dessous du menu et de la barre d'outils. Et si ces derniers veulent changer selon le contexte, ça peut faire bizarre. Pareil pour ce qui se trouve dans le panneau latéral.

Donc voici mon idée du jour : avoir les onglets au-dessus du menu et de la barre d'outils (et du panneau latéral), pour que tous ces éléments puissent changer selon le contexte. Et certains onglets pourraient d'ailleurs afficher un terminal au lieu d'un éditeur de texte.

Et ces onglets qui se trouvent au-dessus, ça pourrait même s'appeler une barre des tâches. Oh tiens… :-)