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 :-)
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.
Scintilla se situe au niveau de GtkTextView + GtkSourceView, mais il y a des différences dans les fonctionnalités fournies. Je pense que GtkTextView est meilleur pour l'internationalisation (bon support d'Unicode, texte de droite à gauche etc, grâce à Pango). Je pense que GtkSourceView a une meilleure recherche et remplacement (incluant la recherche par regex, c'était mon sujet de GSoC). Scintilla a le code folding, …
Pour écrire une appli en GTK, l'API de GtkSourceView sera plus familière au développeur pcq ce sont des classes GObject comme tous les widgets GTK. Scintilla a une API un peu étrange je trouve, mais c'est peut-être pcq je ne suis pas habitué. Je trouve la documentation de Scintilla assez horrible, en comparaison GtkSourceView est documenté avec gtk-doc ce qui permet de l'ouvrir avec Devhelp. Enfin bon, je suis évidemment biaisé.
Scintilla a des backends pour différents toolkits : GTK+, Qt, pour Windows, etc. Et GTK+ lui-même (ou plutôt GDK pour être plus précis) a lui aussi des backends pour différentes plateformes : Wayland, X11, Windows, Mac, etc. GtkSourceView utilise directement GTK+, donc il n'y a qu'une seule couche de backend.
Mais là où ça devient intéressant du côté de GtkSourceView est le framework dans Tepl, qui fournit des APIs de plus haut niveau (ça utilise par exemple GtkApplication, GtkApplicationWindow, GtkNotebook), ce que Scintilla ne sait pas faire. J'ai bon espoir qu'en 1000 lignes de code il soit possible d'écrire un éditeur de texte basique comme gedit (sans les plugins), tandis qu'avec Scintilla ça demande je pense beaucoup plus de boulot (comme c'est le cas actuellement si on utilise seulement GtkSourceView). Mais bon il y a encore du boulot dans Tepl, mais à ce stade-ci je pense que le reste qu'il y a à faire est entièrement faisable (1% inspiration, 99% transpiration, là je pense être à 50% de transpiration ;-).
Comme ce commentaire et celui-ci dans le bugzilla l'indique, il n'est pas prévu de rendre gnome-shell sous Wayland crashproof, en tout cas pas à court terme. Matthias Clasen est un des managers de l'équipe desktop chez Red Hat, et gnome-shell/mutter est développé en très grande partie par Red Hat.
Mais à long terme, il y a peut-être de l'espoir, en lisant ce commentaire d'un des développeurs de gnome-shell/mutter.
À la sortie de GNOME 3.0, il y a eu beaucoup d'utilisateurs de GNOME 2 qui n'étaient pas satisfait, le paradigme du bureau avait fort changé, il fallait changer ses habitudes (ou changer d'environnement de bureau), etc.
Pour apprendre GLib/GTK+, je te conseille de lire ce guide que j'ai écrit.
Pour apprendre à contribuer à un logiciel libre, ce vieux article d'un ancien développeur GNOME est intéressant. Sinon il suffit de lire le fichier README, HACKING (ou CONTRIBUTING), et ce genre d'autres fichiers TOUT_EN_MAJUSCULE.
Pour GtkSourceView et Tepl, ce sont des bibliothèques donc il n'y a pas de fonction main() comme point d'entrée, chaque fonction publique est un point d'entrée. Tout est bien documenté, donc en ouvrant la doc avec Devhelp, il ne devrait pas y avoir de soucis à apprendre l'API (une fois que tu connais suffisamment bien GLib et GTK+).
Mais développer une bibliothèque est plus difficile que développer une application, il faut faire attention à l'API. Et il faut que l'API convienne à un maximum d'applications. Il faut choisir une bonne balance entre la simplicité et la flexibilité. L'avantage avec Tepl c'est qu'on peut faire des expérimentations, casser l'API tous les 6 mois, si ce n'est pas parfait du premier coup ce n'est pas grave.
J'ai un peu d'expérience avec WebKitGTK+ en étant mainteneur de Devhelp, mais je n'ai jamais essayé de créer un éditeur de texte avec WebKitGTK+. En lisant l'article de arstechnica, on se rend compte assez vite que ça devient au final du développement web, avec du HTML, CSS et JavaScript.
Je sais qu'Evolution est passé à WebKitGTK+ pour écrire des mails. Sans doute que ça convient pour ce cas d'utilisation. Mais gitg, qui utilisait WebKitGTK+, est (re?)passé à GtkSourceView (gitg est développé par les mêmes développeurs que gedit/GtkSourceView). Pour gitg, je me rappelle vaguement de la conversation sur IRC, ils disaient que WebKitGTK+ n'était pas vraiment approprié pour ce qu'ils voulaient faire, que l'API n'était pas très pratique, et qu'ils avaient un plus grand contrôle avec GtkTextView/GtkSourceView.
Pour Red Hat Enterprise Linux (RHEL), CentOS et autres dérivés, il y a énormément de documentation en ligne, disponible gratuitement : https://access.redhat.com/documentation/en/
-> puis clique sur "Red Hat Enterprise Linux", il y a alors plein de guides, en particulier "System Administrator's Guide".
Pour l'administration système, je te conseille d'apprendre un outil d'automatisation comme Ansible ou Puppet. J'ai écris ce journal récemment sur ce sujet.
Pour écrire des scripts, je te conseille d'apprendre Python, le code est plus propre qu'avec des scripts shell. De plus en plus d'administrateurs systèmes utilisent Python (au lieu de shell et Perl, principalement).
Bon apprentissage ! Il y a pas mal d'offres d'emploi comme administrateur système Linux.
Sous le capot, est-ce que cette nouvelle version de Firefox utilise davantage de composants écrit en Rust, provenant de Servo ? Autrement dit, est-ce que le projet Quantum avance comme prévu ?
Donc, normalement, ce sera pour bientôt \o/ Mais j'imagine qu'ils ne portent pas Firefox tout d'un coup aux composants de Servo, je suppose que chaque version se rapproche un peu plus du but final. Par exemple Electrolysis (E10S) n'est toujours pas complètement finalisé.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ?
Parce que si par exemple la synchro audio-vidéo est citée comme un plus alors que c'est une fonctionnalité assez basique de jack (même moi, c'est ce que j'utilise le plus; je suis un très faible utilisateur audio avec jack)… Ou alors cette comparaison vient de toi, et pas de ce développeur? :-)
Oui cette comparaison vient de moi, c'était une vraie question. Je ne connais vraiment pas bien Jack.
Le développeur de PipeWire je pense qu'il s'y connait vraiment bien, c'est Wim Taymans, le co-créateur de GStreamer. C'est lui qui a le plus de commits dans GStreamer (en tout cas dans le repo git principal).
At the same time we don’t want to make this another painful subsystem transition so PipeWire so we will need to ensure that PulseAudio applications can still be run without modification.
Merci. Je note quand même que ce souci d’éviter de trop grandes souffrances ne concerne que les développeurs d’applications utilisant PulseAudio. Développeurs d’applications Jack, vous allez en chier […]
Ce n'est pas pcq il n'est rien dit au sujet de Jack qu'il faut imaginer que les développeurs d'applications Jack vont en chier… Comme pour PulseAudio, il sera peut-être possible que Jack utilise en interne PipeWire.
PipeWire est un projet encore très jeune, en ce qui concerne les plans pour l'audio pro et Jack, les plans sont encore peut-être flous.
Aussi, Christian Schaller a l'air d'avoir écrit son blog post assez vite, en tout cas il ne s'est pas relu attentivement pcq il y a pas mal de phrases avec des petites erreurs (comme celle ci-dessus). Donc ça ne sert à rien d'essayer d'extrapoler sur des choses qui sont omises dans ce blog post.
Bref, je pense qu'on n'a pas assez d'informations sur PipeWire pour avoir un avis raisonné, en tout cas en ce qui concerne l'audio pro.
Pour ma part, après avoir lu les fichiers README et doc/design.txt (en plus des blog posts de Christian Schaller), PipeWire m'a l'air d'être un projet très prometteur.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ? Est-il possible de sandboxer des applications Jack et qu'elles puissent toujours communiquer entre-elles ? PipeWire règle en tout cas ces deux problèmes, avec une solution plus générale, c'est-à-dire qui convient pour n'importe quel flux multimédia (audio et/ou vidéo), pas seulement pour l'audio. Et puisque PipeWire se base en grosse partie sur GStreamer, il y a énormément de code existant qui peut être réutilisé. Je suis sûr que l'équivalent de PulseAudio réécrit dans PipeWire aura beaucoup moins de lignes de code. Réutiliser la même stack multimédia que fournit GStreamer, ça a tout à fait son sens, selon moi.
[^] # Re: Chouette dépêche
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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.
[^] # Re: Vala
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Peek, capture d'écran au plus simple. Évalué à 8.
Les avis sont partagés dans la communauté GNOME :
- Blog post d'Emmanuele Bassi, avis contre
- Blog post de Michael Catanzaro, avis pour (voir la conclusion)
[^] # Re: Scintilla
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 4.
Scintilla se situe au niveau de GtkTextView + GtkSourceView, mais il y a des différences dans les fonctionnalités fournies. Je pense que GtkTextView est meilleur pour l'internationalisation (bon support d'Unicode, texte de droite à gauche etc, grâce à Pango). Je pense que GtkSourceView a une meilleure recherche et remplacement (incluant la recherche par regex, c'était mon sujet de GSoC). Scintilla a le code folding, …
Pour écrire une appli en GTK, l'API de GtkSourceView sera plus familière au développeur pcq ce sont des classes GObject comme tous les widgets GTK. Scintilla a une API un peu étrange je trouve, mais c'est peut-être pcq je ne suis pas habitué. Je trouve la documentation de Scintilla assez horrible, en comparaison GtkSourceView est documenté avec gtk-doc ce qui permet de l'ouvrir avec Devhelp. Enfin bon, je suis évidemment biaisé.
Scintilla a des backends pour différents toolkits : GTK+, Qt, pour Windows, etc. Et GTK+ lui-même (ou plutôt GDK pour être plus précis) a lui aussi des backends pour différentes plateformes : Wayland, X11, Windows, Mac, etc. GtkSourceView utilise directement GTK+, donc il n'y a qu'une seule couche de backend.
Mais là où ça devient intéressant du côté de GtkSourceView est le framework dans Tepl, qui fournit des APIs de plus haut niveau (ça utilise par exemple GtkApplication, GtkApplicationWindow, GtkNotebook), ce que Scintilla ne sait pas faire. J'ai bon espoir qu'en 1000 lignes de code il soit possible d'écrire un éditeur de texte basique comme gedit (sans les plugins), tandis qu'avec Scintilla ça demande je pense beaucoup plus de boulot (comme c'est le cas actuellement si on utilise seulement GtkSourceView). Mais bon il y a encore du boulot dans Tepl, mais à ce stade-ci je pense que le reste qu'il y a à faire est entièrement faisable (1% inspiration, 99% transpiration, là je pense être à 50% de transpiration ;-).
[^] # Re: Est il prévu de rendre la session Wayland "crashproof"
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.
Comme ce commentaire et celui-ci dans le bugzilla l'indique, il n'est pas prévu de rendre gnome-shell sous Wayland crashproof, en tout cas pas à court terme. Matthias Clasen est un des managers de l'équipe desktop chez Red Hat, et gnome-shell/mutter est développé en très grande partie par Red Hat.
Mais à long terme, il y a peut-être de l'espoir, en lisant ce commentaire d'un des développeurs de gnome-shell/mutter.
[^] # Re: A quand une IHM révolutionnaire ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.
À la sortie de GNOME 3.0, il y a eu beaucoup d'utilisateurs de GNOME 2 qui n'étaient pas satisfait, le paradigme du bureau avait fort changé, il fallait changer ses habitudes (ou changer d'environnement de bureau), etc.
[^] # Re: Double participation
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 5.
Merci pour ta première participation :-)
Pour apprendre GLib/GTK+, je te conseille de lire ce guide que j'ai écrit.
Pour apprendre à contribuer à un logiciel libre, ce vieux article d'un ancien développeur GNOME est intéressant. Sinon il suffit de lire le fichier README, HACKING (ou CONTRIBUTING), et ce genre d'autres fichiers TOUT_EN_MAJUSCULE.
Pour GtkSourceView et Tepl, ce sont des bibliothèques donc il n'y a pas de fonction
main()comme point d'entrée, chaque fonction publique est un point d'entrée. Tout est bien documenté, donc en ouvrant la doc avec Devhelp, il ne devrait pas y avoir de soucis à apprendre l'API (une fois que tu connais suffisamment bien GLib et GTK+).Mais développer une bibliothèque est plus difficile que développer une application, il faut faire attention à l'API. Et il faut que l'API convienne à un maximum d'applications. Il faut choisir une bonne balance entre la simplicité et la flexibilité. L'avantage avec Tepl c'est qu'on peut faire des expérimentations, casser l'API tous les 6 mois, si ce n'est pas parfait du premier coup ce n'est pas grave.
[^] # Re: GtkSourceView vs WebKitGTK+ ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 9. Dernière modification le 21 septembre 2017 à 12:57.
J'ai un peu d'expérience avec WebKitGTK+ en étant mainteneur de Devhelp, mais je n'ai jamais essayé de créer un éditeur de texte avec WebKitGTK+. En lisant l'article de arstechnica, on se rend compte assez vite que ça devient au final du développement web, avec du HTML, CSS et JavaScript.
Je sais qu'Evolution est passé à WebKitGTK+ pour écrire des mails. Sans doute que ça convient pour ce cas d'utilisation. Mais gitg, qui utilisait WebKitGTK+, est (re?)passé à GtkSourceView (gitg est développé par les mêmes développeurs que gedit/GtkSourceView). Pour gitg, je me rappelle vaguement de la conversation sur IRC, ils disaient que WebKitGTK+ n'était pas vraiment approprié pour ce qu'ils voulaient faire, que l'API n'était pas très pratique, et qu'ils avaient un plus grand contrôle avec GtkTextView/GtkSourceView.
[^] # Re: un gros morceau
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 2.
J'ai utilisé la commande
apt-cache rdepends <package_name>, pour GtkSourceView 3 et 2. Et récursivement pour les bindings.[^] # Re: un gros morceau
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 6.
Pour la complétion des fonctions de math, et peut-être aussi le undo/redo.
# Quelques références en vrac
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au message Se former à l'administration Linux : par où commencer ?. Évalué à 2.
Pour Red Hat Enterprise Linux (RHEL), CentOS et autres dérivés, il y a énormément de documentation en ligne, disponible gratuitement :
https://access.redhat.com/documentation/en/
-> puis clique sur "Red Hat Enterprise Linux", il y a alors plein de guides, en particulier "System Administrator's Guide".
Quelques bouquins :
Pour l'administration système, je te conseille d'apprendre un outil d'automatisation comme Ansible ou Puppet. J'ai écris ce journal récemment sur ce sujet.
Pour écrire des scripts, je te conseille d'apprendre Python, le code est plus propre qu'avec des scripts shell. De plus en plus d'administrateurs systèmes utilisent Python (au lieu de shell et Perl, principalement).
Bon apprentissage ! Il y a pas mal d'offres d'emploi comme administrateur système Linux.
[^] # Re: Rust, Servo, projet Quantum
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 2.
Cool, merci pour les infos.
# Rust, Servo, projet Quantum
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Firefox 55 est prêt pour la rentrée 2017. Évalué à 7.
Sous le capot, est-ce que cette nouvelle version de Firefox utilise davantage de composants écrit en Rust, provenant de Servo ? Autrement dit, est-ce que le projet Quantum avance comme prévu ?
La Roadmap de Firefox indique, dans la catégorie Responsiveness:
Donc, normalement, ce sera pour bientôt \o/ Mais j'imagine qu'ils ne portent pas Firefox tout d'un coup aux composants de Servo, je suppose que chaque version se rapproche un peu plus du but final. Par exemple Electrolysis (E10S) n'est toujours pas complètement finalisé.
[^] # Re: Bye
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Claude Rich bronsonisé. Évalué à 7.
Désolé.
[^] # Re: Leave Jack alone!
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 2.
Oui cette comparaison vient de moi, c'était une vraie question. Je ne connais vraiment pas bien Jack.
Le développeur de PipeWire je pense qu'il s'y connait vraiment bien, c'est Wim Taymans, le co-créateur de GStreamer. C'est lui qui a le plus de commits dans GStreamer (en tout cas dans le repo git principal).
[^] # Re: Leave Jack alone!
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 4.
Ce n'est pas pcq il n'est rien dit au sujet de Jack qu'il faut imaginer que les développeurs d'applications Jack vont en chier… Comme pour PulseAudio, il sera peut-être possible que Jack utilise en interne PipeWire.
PipeWire est un projet encore très jeune, en ce qui concerne les plans pour l'audio pro et Jack, les plans sont encore peut-être flous.
Aussi, Christian Schaller a l'air d'avoir écrit son blog post assez vite, en tout cas il ne s'est pas relu attentivement pcq il y a pas mal de phrases avec des petites erreurs (comme celle ci-dessus). Donc ça ne sert à rien d'essayer d'extrapoler sur des choses qui sont omises dans ce blog post.
Bref, je pense qu'on n'a pas assez d'informations sur PipeWire pour avoir un avis raisonné, en tout cas en ce qui concerne l'audio pro.
Pour ma part, après avoir lu les fichiers README et doc/design.txt (en plus des blog posts de Christian Schaller), PipeWire m'a l'air d'être un projet très prometteur.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ? Est-il possible de sandboxer des applications Jack et qu'elles puissent toujours communiquer entre-elles ? PipeWire règle en tout cas ces deux problèmes, avec une solution plus générale, c'est-à-dire qui convient pour n'importe quel flux multimédia (audio et/ou vidéo), pas seulement pour l'audio. Et puisque PipeWire se base en grosse partie sur GStreamer, il y a énormément de code existant qui peut être réutilisé. Je suis sûr que l'équivalent de PulseAudio réécrit dans PipeWire aura beaucoup moins de lignes de code. Réutiliser la même stack multimédia que fournit GStreamer, ça a tout à fait son sens, selon moi.