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 :-)
C'est en supposant que les grosses applis ont les moyens de créer des custom widgets pour les trucs qui manquent dans GTK.
Mais ce n'est pas seulement pour les grosses applis, les applis préférant garder une GUI traditionnelle ont de plus en plus de mal à le faire avec les dernières versions de GTK.
Ceci dit, en regardant dans gtk4-demo et en cherchant "menu", il y a plusieurs exemples qui montrent une barre de menu avec GtkPopoverMenuBar : c'est une barre de menu comme avec GTK 3 (plus ou moins), sauf que le style est différent et c'est implémenté avec des "popover". Mais il n'y a apparemment pas de signal émis quand un item de menu est sélectionné/quand la souris passe dessus (ce qui, en GTK 3 ou GTK 2, permet d'afficher des infos en plus, comme le fait GIMP).
Et, je pense que même en GTK 4, Amtk serait utile (si la bibliothèque était portée à GTK 4), notamment pour ne pas dupliquer les informations pour créer les items du menu et les items de la barre d'outils.
Par curiosité, j'ai testé SLED récemment. Utilisateur de Fedora/CentOS depuis des années, j'avais envie de voir ce qui se fait du côté de SUSE.
Je trouve que zypper (le gestionnaire de paquets en ligne de commandes de SUSE) est mieux fait que dnf (celui de Fedora). D'ailleurs sous le capot, la libsolv, développé par SUSE et initialement utilisé par zypper, est maintenant utilisé par dnf aussi.
La documentation de SUSE est incroyablement bien faite, et on peut choisir le format (html, single-html, pdf, epub). Il y a plus de projets logiciels qui devraient faire pareil, pouvoir imprimer ou sauvegarder facilement toute la doc.
Ce qui marche moins bien, c'est le multimédia. Je trouve que RPM Fusion pour Fedora est mieux fait que l'équivalent chez SUSE, Packman (Additional package repositories). Après avoir installé je pense ce qu'il faut, totem (donc avec GStreamer) "lagge", mais heureusement il y a VLC qui tourne bien. Sans doute un paquet GStreamer qu'il faut que j'installe en plus pour avoir l'accélération matérielle ou un truc du genre. Je dois encore voir ça plus en détails. Dans tous les cas sur Fedora je n'ai pas ce soucis de "lag".
Et, en tant que client qui paye (environ 50€ par an), l'expérience client est vraiment bien faite je trouve, il y a notamment le Customer Center, et ce n'est pas si embêtant que ça de devoir rentrer un code d'enregistrement lors de l'installation. Alors bien sûr, pourquoi payer alors qu'openSUSE est gratuit ? C'était avant tout par curiosité, SUSE est meilleur marché que Red Hat, et comme ça je soutiens une entreprise qui développe le desktop Linux. Ce n'est cependant pas l'activité principale de SUSE évidemment, le secteur serveur/cloud ayant plus de poids, mais en payant une souscription pour SLED, j'ose espérer que l'argent est utilisé pour le Desktop, comme le D l'indique. Hé, si tous les utilisateurs du bureau Linux faisaient de même, le bureau Linux se porterait déjà mieux ;-)
devoir passer tout notre code de GtkAction à GAction
GtkAction (et GtkUIManager) fonctionnent encore en GTK 3, mais ces APIs sont obsolètes. Ça a été rendu obsolète dans GTK 3.10. Pour migrer à GTK 3, pas mal d'applis GNOME sont d'abord passées par GTK 3.0, puis 3.2, etc. Ce n'est que quelques années plus tard que ces applis sont passées aux "headerbar" (au lieu d'une barre de menu et une barre d'outils classique), avec le passage à GAction, GMenu, etc.
Donc, grosso modo, faut pas se sentir obligé de tout passer à GAction pour pouvoir sortir une version stable de GIMP 3. Ça peut être fait pour une version mineure suivante.
Dans tous les cas, j'ai développé une petite bibliothèque appelée Amtk:
Amtk is the acronym for “Actions, Menus and Toolbars Kit”. It is a basic GtkUIManager replacement based on GAction. It is suitable for both a traditional UI or a modern UI with a GtkHeaderBar.
Je l'utilise notamment pour migrer GNOME LaTeXprogressivement vers GAction (dans cette appli il y a encore un mix de GAction et GtkAction, et de GtkUIManager et Amtk). Bref on peut faire la migration à son aise.
À noter que dans GTK 4, GtkMenu a disparu, c'est GMenu qu'il faut utiliser, ce qui je pense réduit ce qu'il est possible de faire avec (faudrait que je regarde ça plus en détails).
J'allais dire « Soutenir les entreprises européennes », mais il y a sûrement des québecois parmi nous.
Les GAFA ont pris un peu trop de pouvoir, et – bien que je n'ai rien contre les américains – toutes les grosses boites en informatique proviennent des USA (à quelques exceptions près).
Dans le monde Linux, je préfère maintenant privilégier des entreprises comme SUSE ou Canonical plutôt que Red Hat/IBM.
J'ai longtemps utilisé Fedora, mais je suis maintenant en train de migrer vers SUSE. Et SUSE est franchement pas mal. Voilà, c'est mon petit projet du moment qui me tient à coeur :-)
Posté par swilmet .
En réponse à la dépêche CentOS se saborde‑t‑elle ?.
Évalué à 3.
Dernière modification le 09 décembre 2020 à 17:48.
Je suis d'accord que c'est un coup bas de la part de Red Hat.
Mais en même temps, les utilisateurs de CentOS n'ont pas signé un contrat de support à long terme, et ne payent généralement rien. Voici un extrait de la licence GPL :
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
Le projet CentOS est tout à fait dans leurs droits, donc.
Mais c'est vrai que, il y a quelques années d'ici, le projet CentOS était encore un projet communautaire. Puis Red Hat a engagé deux ou trois développeurs clés du projet CentOS, pour initialement continuer le projet CentOS comme avant. Puis ils ont lancé ce CentOS Stream, puis voilà maintenant où ils en sont… Red Hat a en quelques sortes pris le contrôle du projet CentOS (!).
En LaTeX, quand on veut sortir des sentiers battus et modifier drastiquement l'apparence du document, ça peut vite devenir la galère.
Tandis qu'en ConTeXt, c'est beaucoup plus configurable de base.
À l'heure actuelle j'aurais plutôt tendance à recommander ConTeXt plutôt que LaTeX (je suis l'auteur de l'éditeur de texte GNOME LaTeX). Seul bémol, il manque un éditeur de texte spécialisé pour ConTeXt, et qui soit facilement installable sur tous les OS, y compris Linux ;-)
As-tu regardé du côté de la bibliothèque GStreamer ainsi que sa suite d'outils en ligne de commande ? Il y a peut-être un outil de haut-niveau pour le transcodage.
Sinon oui, le Alt+r me manque aussi, mais… un petit redémarrage n'a tué personne ? Si ?
En lien avec le Alt+r :
Quand gnome-shell plante sous Wayland, les applications plantent avec. Donc, ça ne tue personne, mais ça peut tuer des applications (et les données qui vont avec).
Tandis que quand gnome-shell plante sous X11, gnome-shell est redémarré automatiquement. gnome-shell n'étant qu'un client X11 parmi d'autres.
On pourrait ajouter que Fedora Workstation est maintenant pré-installé avec certains ordinateurs vendus dans le commerce : First Lenovo laptop with Fedora now available on the web! (c'est le blog du manager de l'équipe desktop chez Red Hat).
Lenovo contribue à Fedora et à certaines couches bas-niveau pour que Fedora offre une bonne expérience utilisateur à ses clients.
Alors, peut-être (ce n'est qu'une supposition) que c'est Lenovo qui voulait apporter Btrfs à Fedora Workstation. En attendant que Silverblue soit prêt pour le grand public. Silverblue apporte, notamment, un système robuste pour les rollbacks complets. Btrfs le permet également, dans une moindre mesure (en faisant des snapshots du système de fichier).
OpenSUSE et SUSE utilisent aussi Btrfs, et c'est un concurrent principal de Red Hat. Ça pourrait être une autre raison.
[^] # Re: Pour le C++ soyez très méfiant envers votre IDE
Posté par swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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é.
[^] # Re: Chouette dépêche
Posté par swilmet . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 7.
C'est en supposant que les grosses applis ont les moyens de créer des custom widgets pour les trucs qui manquent dans GTK.
Mais ce n'est pas seulement pour les grosses applis, les applis préférant garder une GUI traditionnelle ont de plus en plus de mal à le faire avec les dernières versions de GTK.
Ceci dit, en regardant dans gtk4-demo et en cherchant "menu", il y a plusieurs exemples qui montrent une barre de menu avec GtkPopoverMenuBar : c'est une barre de menu comme avec GTK 3 (plus ou moins), sauf que le style est différent et c'est implémenté avec des "popover". Mais il n'y a apparemment pas de signal émis quand un item de menu est sélectionné/quand la souris passe dessus (ce qui, en GTK 3 ou GTK 2, permet d'afficher des infos en plus, comme le fait GIMP).
Et, je pense que même en GTK 4, Amtk serait utile (si la bibliothèque était portée à GTK 4), notamment pour ne pas dupliquer les informations pour créer les items du menu et les items de la barre d'outils.
# Essai de SLED (SUSE Linux Enterprise Desktop)
Posté par swilmet . En réponse à la dépêche openSUSE Leap 15.2. Évalué à 10.
Par curiosité, j'ai testé SLED récemment. Utilisateur de Fedora/CentOS depuis des années, j'avais envie de voir ce qui se fait du côté de SUSE.
Je trouve que zypper (le gestionnaire de paquets en ligne de commandes de SUSE) est mieux fait que dnf (celui de Fedora). D'ailleurs sous le capot, la libsolv, développé par SUSE et initialement utilisé par zypper, est maintenant utilisé par dnf aussi.
La documentation de SUSE est incroyablement bien faite, et on peut choisir le format (html, single-html, pdf, epub). Il y a plus de projets logiciels qui devraient faire pareil, pouvoir imprimer ou sauvegarder facilement toute la doc.
Ce qui marche moins bien, c'est le multimédia. Je trouve que RPM Fusion pour Fedora est mieux fait que l'équivalent chez SUSE, Packman (Additional package repositories). Après avoir installé je pense ce qu'il faut, totem (donc avec GStreamer) "lagge", mais heureusement il y a VLC qui tourne bien. Sans doute un paquet GStreamer qu'il faut que j'installe en plus pour avoir l'accélération matérielle ou un truc du genre. Je dois encore voir ça plus en détails. Dans tous les cas sur Fedora je n'ai pas ce soucis de "lag".
Et, en tant que client qui paye (environ 50€ par an), l'expérience client est vraiment bien faite je trouve, il y a notamment le Customer Center, et ce n'est pas si embêtant que ça de devoir rentrer un code d'enregistrement lors de l'installation. Alors bien sûr, pourquoi payer alors qu'openSUSE est gratuit ? C'était avant tout par curiosité, SUSE est meilleur marché que Red Hat, et comme ça je soutiens une entreprise qui développe le desktop Linux. Ce n'est cependant pas l'activité principale de SUSE évidemment, le secteur serveur/cloud ayant plus de poids, mais en payant une souscription pour SLED, j'ose espérer que l'argent est utilisé pour le Desktop, comme le D l'indique. Hé, si tous les utilisateurs du bureau Linux faisaient de même, le bureau Linux se porterait déjà mieux ;-)
[^] # Re: Chouette dépêche
Posté par swilmet . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 10.
GtkAction (et GtkUIManager) fonctionnent encore en GTK 3, mais ces APIs sont obsolètes. Ça a été rendu obsolète dans GTK 3.10. Pour migrer à GTK 3, pas mal d'applis GNOME sont d'abord passées par GTK 3.0, puis 3.2, etc. Ce n'est que quelques années plus tard que ces applis sont passées aux "headerbar" (au lieu d'une barre de menu et une barre d'outils classique), avec le passage à GAction, GMenu, etc.
Donc, grosso modo, faut pas se sentir obligé de tout passer à GAction pour pouvoir sortir une version stable de GIMP 3. Ça peut être fait pour une version mineure suivante.
Dans tous les cas, j'ai développé une petite bibliothèque appelée Amtk:
Je l'utilise notamment pour migrer GNOME LaTeX progressivement vers GAction (dans cette appli il y a encore un mix de GAction et GtkAction, et de GtkUIManager et Amtk). Bref on peut faire la migration à son aise.
À noter que dans GTK 4, GtkMenu a disparu, c'est GMenu qu'il faut utiliser, ce qui je pense réduit ce qu'il est possible de faire avec (faudrait que je regarde ça plus en détails).
# Soutenir les entreprises "non-USA"
Posté par swilmet . En réponse au journal Linux ne m'intéresse plus. Évalué à 2.
J'allais dire « Soutenir les entreprises européennes », mais il y a sûrement des québecois parmi nous.
Les GAFA ont pris un peu trop de pouvoir, et – bien que je n'ai rien contre les américains – toutes les grosses boites en informatique proviennent des USA (à quelques exceptions près).
Dans le monde Linux, je préfère maintenant privilégier des entreprises comme SUSE ou Canonical plutôt que Red Hat/IBM.
J'ai longtemps utilisé Fedora, mais je suis maintenant en train de migrer vers SUSE. Et SUSE est franchement pas mal. Voilà, c'est mon petit projet du moment qui me tient à coeur :-)
[^] # Re: pourquoi ?
Posté par swilmet . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 3. Dernière modification le 09 décembre 2020 à 17:48.
Je suis d'accord que c'est un coup bas de la part de Red Hat.
Mais en même temps, les utilisateurs de CentOS n'ont pas signé un contrat de support à long terme, et ne payent généralement rien. Voici un extrait de la licence GPL :
Le projet CentOS est tout à fait dans leurs droits, donc.
Mais c'est vrai que, il y a quelques années d'ici, le projet CentOS était encore un projet communautaire. Puis Red Hat a engagé deux ou trois développeurs clés du projet CentOS, pour initialement continuer le projet CentOS comme avant. Puis ils ont lancé ce CentOS Stream, puis voilà maintenant où ils en sont… Red Hat a en quelques sortes pris le contrôle du projet CentOS (!).
# ConTeXt, alternative à LaTeX
Posté par swilmet . En réponse à la dépêche Les doigts dans l’engrenage fatal. Évalué à 2.
Il y a aussi ConTeXt, développé principalement par la société néerlandaise PRAGMA Advanced Document Engineering.
En LaTeX, quand on veut sortir des sentiers battus et modifier drastiquement l'apparence du document, ça peut vite devenir la galère.
Tandis qu'en ConTeXt, c'est beaucoup plus configurable de base.
À l'heure actuelle j'aurais plutôt tendance à recommander ConTeXt plutôt que LaTeX (je suis l'auteur de l'éditeur de texte GNOME LaTeX). Seul bémol, il manque un éditeur de texte spécialisé pour ConTeXt, et qui soit facilement installable sur tous les OS, y compris Linux ;-)
# GStreamer
Posté par swilmet . En réponse au journal Encodage de DVD, suite. Évalué à 3.
As-tu regardé du côté de la bibliothèque GStreamer ainsi que sa suite d'outils en ligne de commande ? Il y a peut-être un outil de haut-niveau pour le transcodage.
[^] # Re: état de Wayland ?
Posté par swilmet . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 5.
En lien avec le Alt+r :
Quand gnome-shell plante sous Wayland, les applications plantent avec. Donc, ça ne tue personne, mais ça peut tuer des applications (et les données qui vont avec).
Tandis que quand gnome-shell plante sous X11, gnome-shell est redémarré automatiquement. gnome-shell n'étant qu'un client X11 parmi d'autres.
Voir : https://bugzilla.redhat.com/show_bug.cgi?id=1367666
[^] # Re: état de Wayland ?
Posté par swilmet . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 4.
État de Wayland ? Le Massachusetts, évidemment !
(Le nom « Wayland » a été choisi par son créateur, vivant dans les environs de cette ville aux États-Unis ;-)
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#History
[^] # Re: Merci
Posté par swilmet . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 2.
Pour plus d'infos sur cette nouvelle version de GNOME : Notes de version de GNOME 3.38, en français.
[^] # Re: btrfs, ce n'est à plus rien comprendre
Posté par swilmet . En réponse à la dépêche Nouvelle version de Fedora dite 33. Évalué à 3.
On pourrait ajouter que Fedora Workstation est maintenant pré-installé avec certains ordinateurs vendus dans le commerce : First Lenovo laptop with Fedora now available on the web! (c'est le blog du manager de l'équipe desktop chez Red Hat).
Lenovo contribue à Fedora et à certaines couches bas-niveau pour que Fedora offre une bonne expérience utilisateur à ses clients.
Alors, peut-être (ce n'est qu'une supposition) que c'est Lenovo qui voulait apporter Btrfs à Fedora Workstation. En attendant que Silverblue soit prêt pour le grand public. Silverblue apporte, notamment, un système robuste pour les rollbacks complets. Btrfs le permet également, dans une moindre mesure (en faisant des snapshots du système de fichier).
OpenSUSE et SUSE utilisent aussi Btrfs, et c'est un concurrent principal de Red Hat. Ça pourrait être une autre raison.