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 :
(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 !
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 ;-)
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.
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).
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… :-)
De manière graphique : GUI, pas en CLI. Mais ça pourrait être en ncurses dans un terminal aussi. Ne pas confondre CLI (lignes de commandes), avec une interface style ncurses.
C'est vrai que de nos jours quand on parle d'un IDE, on a tendance à penser à une seule grosse application GUI qui sait tout faire.
Mais, en GUI, rien n'empêche de développer des applications séparées, mais qui communiquent entre-elles avec un mécanisme d'IPC. L'avantage est que chaque application a une GUI plus simple, et ça fait donc moins « usine à gaz ».
Exemple (dont j'ai participé au développement) : Devhelp (navigateur d'API), qui sait être utilisé séparément, ou alors être lancé par l'éditeur de texte (pour voir la doc d'une fonction ou d'un autre symbole) ou être intégré à un IDE (il y a pour ça la libdevhelp, en GTK).
Perso j'adore le fait d'appuyer sur un raccourcis clavier depuis mon éditeur de texte, pour sauter vers la doc correspondante dans Devhelp (pour le symbole qui se trouve sous le curseur dans l'éditeur de texte). Puis un simple Alt+Tab pour revenir à l'éditeur de texte. Simple mais efficace.
Arduino est un exemple où c'est la même entreprise qui a développé le matériel, la plateforme de développement et l'éditeur de texte. Le tout pour que ça convienne à des débutants (pour commencer et écrire son hello-world avec une led qui clignote, ça fait le job). Mais c'est clair que ce ne sont pas des spécialistes (à la base) pour créer un éditeur de texte.
Autre exemple, la société JetBrains qui a développé IntelliJ Idea (pour Java), CLion (pour le C/C++), etc. Ce sont des IDEs spécialisés. Mais ce n'est pas JetBrains qui a créé Java évidemment. JetBrains s'est spécialisé dans le développement d'outils pour les développeurs, et ça a plutôt bien fonctionné. Ils ont créé une software product line, partageant du code entre leurs différents IDEs et outils.
Donc, je dirais, l'approche LSP est une bonne approche dans un premier temps (pour les concepteurs d'un langage), et si le langage devient suffisamment populaire, d'autres personnes/entreprises s'occupent de créer d'autres outils autours, des plugins additionnels pour certains éditeurs de texte, ou un éditeur de texte spécialisé, etc.
Il en faut donc pour tous les goûts : pour les débutants qui veulent un petit éditeur de texte spécialisé qui fait bien son boulot, out-of-the-box ; des éditeurs multi-usages et hyper-configurables ; etc.
Et si le LSP pour un certain langage est implémenté avec du code réutilisable (en-dehors du protocole LSP), c'est d'autant mieux pour ceux qui ont envie de créer un éditeur spécialisé. Je pense notamment à la libclang (du projet LLVM), qui est une brique de base pour l'implémentation d'outils autours du C et C++ (auto-complétion, refactoring, et bien d'autres). La libclang permet notamment l'implémentation du protocole LSP, mais ça peut être aussi utilisé directement en-dehors de LSP. Bref, la flexibilité à son maximum ;-)
Je vois la différence entre un éditeur de texte et un IDE différemment.
Pour moi un IDE est un éditeur de texte (le composant principal) plus d'autres outils qui ont été intégrés :
- Compiler/faire tourner le code (au lieu de le faire dans un terminal).
- Git/gestionnaire de versions, mais de manière graphique.
- Un navigateur d'API, pour lire la doc.
- Un débogueur.
- Etc.
Mais rien n'empêche à un éditeur de texte d'avoir une auto-complétion intelligente, avec donc une connaissance du langage en question. Pareil évidemment pour la coloration syntaxique, etc.
Ça aide pas mal, mais ce n'est pas le seul choix possible (pour les concepteurs d'un langage ou d'une plateforme de développement). LSP est un bon premier choix, mais il y a souvent moyen de faire mieux en développant des outils spécialisés (en se basant quand même sur des bibliothèques plus générales qui font déjà une grosse partie du boulot).
Il y a l'exemple d'Arduino qui a développé son propre éditeur de texte. Ça a l'avantage que les fonctionnalités sont mieux intégrées, avec une application qui Juste Marche (si tout va bien). Mais ça demande plus d'efforts de développement, par exemple il y a quelques années il n'y avait pas d'onglets pour ouvrir plusieurs fichiers dans la même fenêtre, plutôt embêtant…
Pour catégoriser un peu, je dirais que :
- Il y a les éditeurs généralistes, qui essayent de convenir à un maximum de langages (et souvent avec un système d'extensions/plugins). Plus fastidieux pour tout installer et configurer.
- Il y a les éditeurs spécialisés, qui intègrent mieux les fonctionnalités pour un langage particulier.
C'est là que LSP ne convient pas toujours pour les éditeurs spécialisés.
Pour faire une analogie : la question entre utiliser une clé à molette ou plusieurs clés de tailles spécifiques.
PS : j'ai été de ceux qui ont développé des bibliothèques pour faciliter le développement d'outils de programmation (édition de texte, navigateur d'API). Donc mon avis est peut-être baisé (biaisé pardon).
En supprimant une dépêche (manuellement donc, lors d'un nettoyage de printemps), est-ce qu'il y a quand même une sauvegarde derrière ? Un peu comme un git rm, il y aurait quand même moyen de récupérer le contenu en revenant en arrière dans l'historique ?
Si jamais l'auteur original re-débarque 6 mois plus tard, et grogne "mais où est donc passée ma dépêche" ?
Mais sinon, je pense qu'internet et le web sont déjà suffisamment chargés d'informations que pour vouloir à tout pris tout garder. Donc, autant supprimer, sans regrets. Quitte à faire un bête copier-coller en-dehors de LinuxFr, avant de supprimer du site.
J'ai appris LaTeX il y a 15 ans, et je ne regrette absolument pas. J'ai même développé un certain éditeur LaTeX.
Par contre maintenant je recommande plutôt ConTeXt, un cousin (avec la même base TeX). C'est plus simple à apprendre, et plus flexible. Pour un livre ou pour un CV, c'est ce que je recommande en tout cas.
Voir le site http://tug.org/ pour tout ce qui concerne l'univers TeX.
Bon dans ton cas ça ne s'applique pas, puisque budget limité (besoin perso).
Mais pour les organisations qui utilisent LibreOffice, il est recommandé de passer par une société de consultance comme Collabora, qui déjà fournit une version LTS, mais aussi s'occupe de développer des solutions pour ses clients.
Le problème de BountySource et autres, c'est qu'il y a beaucoup trop de tickets ouverts dans le bugtracker, donc les dons sont dispersés par-ci par-là, et un ticket n'atteint presque jamais assez d'argent pour intéresser un développeur.
Pour qu'une plateforme comme BountySource ait du succès, il faudrait donc une solution entre les deux approches, par exemple (à la grosse louche) :
1. Les développeurs de LibreOffice choisissent, disons, 5 tickets dans le bugtracker (pas pris au hasard évidemment).
2. Ils font ensuite une petite campagne pour récolter des dons pour ces 5 tickets.
3. Des développeurs travaillent sur les tickets et sont payés.
4. Retour au point 1 :-)
# Faire tourner l'économie belge et européenne (pas les GAFAM)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal En Belgique, l’usage de LibreOffice est interdit par les (certaines ?) Écoles !. Évalué à 6.
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 !
[^] # Re: filtrage par motif
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Java 17 LTS. Évalué à 3.
Pour ma part c'était Oz, qui supporte aussi le pattern matching (depuis longtemps).
# SUSE
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche openSUSE Leap 15.3 est sortie !. Évalué à 5.
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.
[^] # Re: PipeWire
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au message Problème son et configuration de JACK. Évalué à 2.
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 ;-) ).
# Je ne sais pas vraiment t'aider, mais j'ai appris des choses
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au message Numériser en PDF comme en DjVu. Évalué à 2.
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^Wde GitHub ;-)# PipeWire
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au message Problème son et configuration de JACK. Évalué à 3.
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 ;-)
# Software product lines (livre)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Separation of Concerns (SoC). Évalué à 2.
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.
# dnf ??
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au lien openSUSE Leap 15.3 . Évalué à 2.
J'ai un mal fou à comprendre pourquoi l'article parle de DNF (le gestionnaire de paquets de Fedora) au lieu de Zypper.
[^] # Re: RSS ou Atom, bonnes pratiques pour développer un site web
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au lien Chrome va rajouter un bouton "Suivre" pour s'abonner aux flux RSS (oui oui, en 2021). Évalué à 4.
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.
# RSS ou Atom, bonnes pratiques pour développer un site web
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au lien Chrome va rajouter un bouton "Suivre" pour s'abonner aux flux RSS (oui oui, en 2021). Évalué à 3.
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 ?
[^] # Re: Utile aussi aux développeurs de langages
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 3.
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… :-)
[^] # Re: Pour le C++ soyez très méfiant envers votre IDE
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 3.
Pour le C il y a l'outil Cscope que j'utilise de temps en temps, mais la plupart du temps un petit
git grepfait très bien l'affaire, en effet :-)[^] # Re: Éditeur de texte / IDE
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 4.
De manière graphique : GUI, pas en CLI. Mais ça pourrait être en ncurses dans un terminal aussi. Ne pas confondre CLI (lignes de commandes), avec une interface style ncurses.
C'est vrai que de nos jours quand on parle d'un IDE, on a tendance à penser à une seule grosse application GUI qui sait tout faire.
Mais, en GUI, rien n'empêche de développer des applications séparées, mais qui communiquent entre-elles avec un mécanisme d'IPC. L'avantage est que chaque application a une GUI plus simple, et ça fait donc moins « usine à gaz ».
Exemple (dont j'ai participé au développement) : Devhelp (navigateur d'API), qui sait être utilisé séparément, ou alors être lancé par l'éditeur de texte (pour voir la doc d'une fonction ou d'un autre symbole) ou être intégré à un IDE (il y a pour ça la libdevhelp, en GTK).
Perso j'adore le fait d'appuyer sur un raccourcis clavier depuis mon éditeur de texte, pour sauter vers la doc correspondante dans Devhelp (pour le symbole qui se trouve sous le curseur dans l'éditeur de texte). Puis un simple Alt+Tab pour revenir à l'éditeur de texte. Simple mais efficace.
[^] # Re: Utile aussi aux développeurs de langages
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 7.
Arduino est un exemple où c'est la même entreprise qui a développé le matériel, la plateforme de développement et l'éditeur de texte. Le tout pour que ça convienne à des débutants (pour commencer et écrire son hello-world avec une led qui clignote, ça fait le job). Mais c'est clair que ce ne sont pas des spécialistes (à la base) pour créer un éditeur de texte.
Autre exemple, la société JetBrains qui a développé IntelliJ Idea (pour Java), CLion (pour le C/C++), etc. Ce sont des IDEs spécialisés. Mais ce n'est pas JetBrains qui a créé Java évidemment. JetBrains s'est spécialisé dans le développement d'outils pour les développeurs, et ça a plutôt bien fonctionné. Ils ont créé une software product line, partageant du code entre leurs différents IDEs et outils.
Donc, je dirais, l'approche LSP est une bonne approche dans un premier temps (pour les concepteurs d'un langage), et si le langage devient suffisamment populaire, d'autres personnes/entreprises s'occupent de créer d'autres outils autours, des plugins additionnels pour certains éditeurs de texte, ou un éditeur de texte spécialisé, etc.
Il en faut donc pour tous les goûts : pour les débutants qui veulent un petit éditeur de texte spécialisé qui fait bien son boulot, out-of-the-box ; des éditeurs multi-usages et hyper-configurables ; etc.
Et si le LSP pour un certain langage est implémenté avec du code réutilisable (en-dehors du protocole LSP), c'est d'autant mieux pour ceux qui ont envie de créer un éditeur spécialisé. Je pense notamment à la libclang (du projet LLVM), qui est une brique de base pour l'implémentation d'outils autours du C et C++ (auto-complétion, refactoring, et bien d'autres). La libclang permet notamment l'implémentation du protocole LSP, mais ça peut être aussi utilisé directement en-dehors de LSP. Bref, la flexibilité à son maximum ;-)
# Éditeur de texte / IDE
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 4.
Je vois la différence entre un éditeur de texte et un IDE différemment.
Pour moi un IDE est un éditeur de texte (le composant principal) plus d'autres outils qui ont été intégrés :
- Compiler/faire tourner le code (au lieu de le faire dans un terminal).
- Git/gestionnaire de versions, mais de manière graphique.
- Un navigateur d'API, pour lire la doc.
- Un débogueur.
- Etc.
Mais rien n'empêche à un éditeur de texte d'avoir une auto-complétion intelligente, avec donc une connaissance du langage en question. Pareil évidemment pour la coloration syntaxique, etc.
[^] # Re: Utile aussi aux développeurs de langages
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 4.
Ça aide pas mal, mais ce n'est pas le seul choix possible (pour les concepteurs d'un langage ou d'une plateforme de développement). LSP est un bon premier choix, mais il y a souvent moyen de faire mieux en développant des outils spécialisés (en se basant quand même sur des bibliothèques plus générales qui font déjà une grosse partie du boulot).
Il y a l'exemple d'Arduino qui a développé son propre éditeur de texte. Ça a l'avantage que les fonctionnalités sont mieux intégrées, avec une application qui Juste Marche (si tout va bien). Mais ça demande plus d'efforts de développement, par exemple il y a quelques années il n'y avait pas d'onglets pour ouvrir plusieurs fichiers dans la même fenêtre, plutôt embêtant…
Pour catégoriser un peu, je dirais que :
- Il y a les éditeurs généralistes, qui essayent de convenir à un maximum de langages (et souvent avec un système d'extensions/plugins). Plus fastidieux pour tout installer et configurer.
- Il y a les éditeurs spécialisés, qui intègrent mieux les fonctionnalités pour un langage particulier.
C'est là que LSP ne convient pas toujours pour les éditeurs spécialisés.
Pour faire une analogie : la question entre utiliser une clé à molette ou plusieurs clés de tailles spécifiques.
PS : j'ai été de ceux qui ont développé des bibliothèques pour faciliter le développement d'outils de programmation (édition de texte, navigateur d'API). Donc mon avis est peut-être baisé (biaisé pardon).
# Plus d'explications sur LWN
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au lien The Story Of PipeWire & How It's Getting Ready To Handle Linux Audio + Video. Évalué à 4.
PipeWire: The Linux audio/video bus (LWN)
[^] # Re: Six mois plus tard
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à l’entrée du suivi Réduire la liste de dépêche en cours de rédactions. Évalué à 3 (+0/-0).
En supprimant une dépêche (manuellement donc, lors d'un nettoyage de printemps), est-ce qu'il y a quand même une sauvegarde derrière ? Un peu comme un
git rm, il y aurait quand même moyen de récupérer le contenu en revenant en arrière dans l'historique ?Si jamais l'auteur original re-débarque 6 mois plus tard, et grogne "mais où est donc passée ma dépêche" ?
Mais sinon, je pense qu'internet et le web sont déjà suffisamment chargés d'informations que pour vouloir à tout pris tout garder. Donc, autant supprimer, sans regrets. Quitte à faire un bête copier-coller en-dehors de LinuxFr, avant de supprimer du site.
# Question existentielle
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal MakeMake - the dwarf planet. Évalué à 4.
Et avec tout ça, est-ce que GNU Make utilise un Makefile pour être compilé ?
# À ne pas confondre avec les pipelines du shell / de Shell
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au lien un pipeline américain victime d'une cyber attaque. Évalué à 2.
Bon OK, on est lundi matin.
https://en.wikipedia.org/wiki/Royal_Dutch_Shell
;-)
# À ne pas confondre avec crates.io (Rust)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au lien Les raisons pour lesquelles Crate.io est retourné à ses racines Open Source. Évalué à 6. Dernière modification le 10 mai 2021 à 08:42.
https://crate.io/
https://crates.io/
J'avoue avoir été confus l'espace de quelques instants.
[^] # Re: Latex
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Outils pour écrire un livre. Évalué à 5.
J'ai appris LaTeX il y a 15 ans, et je ne regrette absolument pas. J'ai même développé un certain éditeur LaTeX.
Par contre maintenant je recommande plutôt ConTeXt, un cousin (avec la même base TeX). C'est plus simple à apprendre, et plus flexible. Pour un livre ou pour un CV, c'est ce que je recommande en tout cas.
Voir le site http://tug.org/ pour tout ce qui concerne l'univers TeX.
[^] # Re: Dur…
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 3.
Certains en profitent aussi sur le Microsoft Store, et sans doute sur d'autres App Stores (macOS etc).
# Sociétés de consultance autours de LibreOffice (Collabora et d'autres)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 5.
Bon dans ton cas ça ne s'applique pas, puisque budget limité (besoin perso).
Mais pour les organisations qui utilisent LibreOffice, il est recommandé de passer par une société de consultance comme Collabora, qui déjà fournit une version LTS, mais aussi s'occupe de développer des solutions pour ses clients.
Voir cette page : LibreOffice in business
Le problème de BountySource et autres, c'est qu'il y a beaucoup trop de tickets ouverts dans le bugtracker, donc les dons sont dispersés par-ci par-là, et un ticket n'atteint presque jamais assez d'argent pour intéresser un développeur.
Par contre, il est très facile de faire un don (général) au projet LibreOffice.
Pour qu'une plateforme comme BountySource ait du succès, il faudrait donc une solution entre les deux approches, par exemple (à la grosse louche) :
1. Les développeurs de LibreOffice choisissent, disons, 5 tickets dans le bugtracker (pas pris au hasard évidemment).
2. Ils font ensuite une petite campagne pour récolter des dons pour ces 5 tickets.
3. Des développeurs travaillent sur les tickets et sont payés.
4. Retour au point 1 :-)
[^] # Re: Dur…
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 6.
Sur BountySource le développeur est payé seulement quand le ticket associé est clôturé.