Ton application utilise Qt, mais le runtime Flatpak pour Qt/KDE est toujours en développement. Flatpak a pour l'instant un meilleur support pour GTK+/GNOME (puisque Flatpak est principalement développé par des développeurs GNOME).
Donc, pour l'instant je conseillerais AppImage pour une application Qt (même si j'ai jamais essayé moi-même, il parait que ça fonctionne bien).
AppImage s'occupe uniquement de l'empaquetage/installation. Flatpak et Snappy vont plus loin pour isoler les applications dans une sandbox.
Entre Flapak et Snappy, j'ai tendance à préférer Flatpak. Lire cet article par exemple.
Nautilus utilise la bibliothèque gnome-autoar pour compresser/décompresser les archives. Peut-être que File Roller utilise la même bibliothèque, je ne sais pas.
You may be aware that we have been using File Roller since forever to handle compressed files. However, this makes integration with Nautilus none. It misses the progress report integration, undo, redo, and possibility to close the application while the operation continues.
Plusieurs applications peuvent utiliser le même runtime, le runtime est partagé. Si une application a besoin d'une bibliothèque qui n'est pas présente dans le runtime, cette bibliothèque doit être "bundlée" avec l'application.
Il peut y avoir plusieurs runtime bien entendu : il y a le runtime freedesktop.org, un runtime GNOME, un runtime pour Qt/KDE est en développement, et certaines entreprises ont leur propre runtime. Et il y a généralement plusieurs versions pour un certain runtime : GNOME 3.20, GNOME 3.22, etc.
L'énorme avantage, pour un développeur d'application, c'est que le développement et les tests sont faits avec un runtime précis (et une version précise). Par exemple le runtime GNOME 3.22. Quand GNOME 3.24 sortira, l'application pourra toujours utiliser le runtime GNOME 3.22, donc il y a beaucoup plus de garanties que l'application fonctionnera toujours bien (càd les utilisateurs utilisent la même chose que ce que les développeurs ont utilisé).
Certes, ça utilisera plus de RAM puisque toutes les applications n'utiliseront pas la même version du runtime. Mais de la RAM, les ordinateurs récents en ont assez, et avoir des applications moins buggées (et qui demande moins de travail pour les développeurs) semble être plus important.
Je suis tout à fait d'accord, Mate a forké l'ensemble de GNOME 2, alors qu'il aurait suffit de continuer de maintenir metacity, gnome-panel, gnome-applets et quelques autres modules.
Au début de GNOME 3, il y avait le mode fallback qui utilisait toujours metacity et gnome-panel. Puis ces modules sont devenus obsolètes, avec la session GNOME Classic comme remplacement. GNOME Classic est un ensemble d'extensions de gnome-shell, et qui sont bien maintenues (à la sortie d'une nouvelle version de GNOME, GNOME Classic fonctionne directement). Pour lancer GNOME Classic, il suffit de choisir cette session dans gdm (sur Fedora, GNOME Classic est déjà installé; sur RHEL/CentOS 7, GNOME Classic est la session par défaut).
Pour metacity, gnome-panel etc, au moment où ça a été rendu obsolète, il y a eu une annonce comme quoi d'autres développeurs pouvaient reprendre le flambeau. Ce qui a donné GNOME Flashback (je ne sais pas vraiment ce qu'il en est à l'heure actuelle, je ne sais pas si c'est bien maintenu).
Ceci dit, puisque Mate a forké l'ensemble de GNOME 2, toutes les applications de Mate ont toujours une barre de menu et barre d'outils, à la place d'une headerbar pour la plupart des applications de GNOME 3 maintenant. Par exemple pour totem je trouve la headerbar et le menu hamburger pas mal, mais je préférais la barre de menu et barre d'outils pour gedit.
Dans le cas de gedit, il y a pas mal d'efforts ces dernières années pour rendre le code davantage réutilisable (i.e. avoir du code en commun dans une bibliothèque), avec comme but de pouvoir créer un éditeur de texte aussi bien que gedit, mais beaucoup plus facilement qu'actuellement (au lieu de forker ~60k lignes de code, ne forker par exemple que ~5k lignes). (oui je suis à l'origine de cette initiative).
En fait tout le monde à le droit de ne pas donner (encore heureux je dirais)
Sauf que si personne ne paye pour ce genre de logiciels libres (qui sont quand même assez appréciés et utilisés), ces logiciels libres ne seront plus développés, et un logiciel propriétaire prendra le dessus à la place.
Par exemple pas mal de monde a l'air d'apprécier Sublime Text (et de payer pour), mais les gens devraient se souvenir que c'est un logiciel propriétaire, et qu'il y a des éditeurs de texte libres qui acceptent les donations.
Le marché du desktop vise principalement le grand public (les entreprises aussi, pour ça il y a Red Hat et SUSE par exemple qui ont aussi des offres pour le desktop). Ce que je veux dire par là est que la plupart des applications desktop, ou le desktop lui-même, sont destinés au grand public, pour un usage personnel. Donc si très peu d'utilisateurs payent pour ces logiciels libres, le logiciel propriétaire prendra le dessus (ou plutôt, le logiciel libre ne prendra pas les devants).
Quand j'écris des tests unitaires, je me console en me disant que ce sera utile (et ça l'est vraiment). Et quand je découvre un bug, je me dis que j'ai bien fait d'écrire des tests. Mais bon c'est clair que ce n'est pas la partie la plus amusante.
Il y a beaucoup de choses possibles à faire dans GtkSourceView.
Si tu trouves un bug, ou que tu trouves que la documentation à un endroit n'est pas claire, tu peux toujours rapporter un bug sur le bugzilla. Pareil pour les demandes de fonctionnalités, si tu trouves que ça a du sens d'implémenter ça dans GtkSourceView.
Pour créer des style schemes graphiquement, il y a un plugin de gedit. Il y a surement moyen de rendre le code réutilisable. Voir cette page wiki pour rendre le code de gedit davantage réutilisable.
En suivant les versions LTS d'Ubuntu, ça ne garanti pas à ton programme qu'il fonctionne sur une version plus récente de GTK+ 3 (par exemple pour le CSS, il y a eu des changements importants dans GTK+ 3.20 qui demandent des adaptations). Les développeurs GNOME utilisent Jhbuild pour compiler toutes les sources à partir de Git, sans interférer avec les paquets de la distro.
PS: tu fais beaucoup de fautes d'orthographe et de grammaire… Mais je suppose qu'on te l'a déjà dit ;-)
Ça fait plaisir de voir que mon travail dans GtkSourceView sert à quelque chose.
Je vois que tu ne suis pas vraiment la Programmation Orientée Objets. Oui, en C c'est possible aussi. Il y a bien sûr la bibliothèque GObject, mais sans GObject il y a quand même moyen d'écrire du code semi-orienté-objets facilement. Mais quand on écrit une application en GTK+, c'est de toute façon recommandé d'écrire ses propres classes GObject, comme la plupart des applications GNOME font.
J'ai récemment rajouté une section "Semi-Object-Oriented Programming in C" dans un tutoriel sur GLib/GTK+ que je suis en train d'écrire.
En tout cas, bonne continuation dans IT-Edit !
(Ça me rappelle mes débuts avec LaTeXila, à l'époque où je parlais encore de mes projets sur LinuxFr…)
GVfs permet d'écrire et lire des métadonnées. Soit en ligne de commande avec gvfs-set-attribute et gvfs-info, soit en utilisant l'API de GIO.
C'est ce qu'utilise par exemple gedit pour enregistrer des métadonnées, comme par exemple la position du curseur, la langue pour la correction orthographique, le langage utilisé pour la coloration syntaxique, le type d'encodage des caractères (UTF-8, …), etc.
Si je devais ne recommander qu'un seul livre, ce serait Code Complete. Oui, c'est édité par Microsoft Press, mais le livre n'a pas grand chose à voir avec Microsoft ou Windows. C'est avec ce livre que j'ai le plus appris, pour écrire du code propre et plus stable, plus maintenable, etc. J'ai écris cet article sur mon blog à propos de Code Complete.
Si, GtkSourceView est une sous-classe de GtkTextView. Mais la correction orthographique n'est pas implémentée par GtkSourceView (c'est mieux d'avoir une bibliothèque séparée, comme ça GtkSourceView ne dépend pas d'Enchant).
En bref, gspell rajoute le support pour la correction orthographique pour une application GTK+. (c'est la description qu'il y a dans le fichier README).
Pour la correction orthographique, il y déjà Enchant qui s'occupe de la partie backend. Enchant fait une abstraction des différents moteurs de dictionnaires (hunspell, aspell, etc), et a une API pour savoir si un mot est bien orthographié, avoir une liste de suggestions, avoir la liste des langues supportées, et quelques autres trucs. Enchant ne dépend que de GLib, il n'y a pas d'interface graphique.
Ce que faisait le plugin de gedit, et donc maintenant gspell, est d'ajouter le support pour GtkTextView, qui est le widget pour afficher plusieurs lignes de texte (la base d'un éditeur de texte, ou pour une zone de texte dans un formulaire). Donc gspell dépend de GTK+. Le travail que j'ai fait était de rendre le code de gedit réutilisable, le moderniser (utiliser les nouvelles API de GLib et GTK+), faire quelques améliorations, etc.
Pour l'instant (à ma connaissance), gspell n'est utilisé que par LaTeXila. Mais il est bien entendu prévu d'utiliser gspell dans le plugin de gedit. Ce qui est prévu dans un futur plus lointain est le support pour GtkEntry, qui est un autre widget de GTK+ pour l'édition d'une seule ligne de texte (pour écrire son message dans un client IRC par exemple, ou une zone de texte plus courte dans un formulaire).
Fedora/RHEL se lancent dans le monde des conteneurs (Docker, xdg-app).
Le projet Atomic (encore un autre buzzword), est un OS fait pour installer uniquement des conteneurs, qui est basé sur rpm-ostree, qui est basé sur OSTree (un projet GNOME initialement). Avec rpm-ostree, c'est un tout autre modèle de déploiement, de mises à jours, les rollbacks sont possibles, etc.
Pour le desktop, une Fedora "Atomic" Workstation est en préparation aussi. Lire à ce sujet ce mail qui explique assez bien le contexte, et qu'un système sans état (stateless) était déjà un des objectifs il y a plus de 10 ans, ce qui a conduit aux LiveCD (un OS générique qui fonctionne partout, sans besoin de config/état, par exemple pas besoin de config d'X.org, tout le matériel est détecté au démarrage).
Pour le refactoring de code dans la correction orthographique, le but était de créer une nouvelle librairie, appelée gspell, ce qui est maintenant fait (la première version devrait sortir bientôt). Voir ce billet de mon blog. Normalement pour la version 3.20 de GNOME, gspell sera présent dans les notes de version (pour l'instant gspell ne fait pas encore partie de GNOME).
En gros, Red Hat fait la majeure partie du travail. En nombre de commits, lignes de code, et surtout mainteneurs. Dans GNOME les mainteneurs ont tout le « pouvoir » sur leurs modules, il n'y a pas de comité au-dessus en ce qui concerne les décisions techniques. (La GNOME Foundation s'occupe des trucs légaux, les finances, les conférences, etc, mais pas les décisions techniques).
Donc, comme Red Hat a beaucoup de mainteneurs dans GNOME, Red Hat a beaucoup de pouvoirs de décision sur la direction de GNOME. Ce qui n'arrange pas toujours d'autres entreprises, comme Canonical qui a préféré développer Unity.
Mais ce serait intéressant d'avoir des statistiques sur l'ensemble de GNOME, pas seulement GLib/GTK+.
Avec un wiki, n'importe qui peut modifier une page. La barrière d'entrée est donc assez basse, ce qui est un avantage pour qu'il y ait plus de contributions.
D'un autre côté les logiciels libres sont développés différemment. Il y a des mainteneurs et des revues de code. Quand un contributeur a fait pas mal de contributions (par exemple 200 commits), il peut devenir mainteneur (éventuellement que pour une partie du code, au début). Pour certains projets, les mainteneurs peuvent pusher leurs changements directement (pour les petits changements), et il y a des post-reviews si les autres mainteneurs ont du temps.
Le gros problème avec les reviews, c'est que ça peut prendre du temps pour avoir une réponse, ce qui freine énormément les contributions. Il faut des mainteneurs actifs.
Est-ce une solution pour Wikipédia ? Ça rendrait sans doute l'encyclopédie plus crédible, j'ai souvent entendu des remarques négatives à ce sujet (de gens qui ne connaissent pas bien le libre), puisque « n'importe qui peut éditer les pages, on peut tomber sur des articles de mauvaise qualité », ce qui n'est pas tout à fait faux. En pratique on peut se restreindre à lire les contenus de qualité, où quand il y a du vandalisme sur ces pages, c'est sans doute remarqué et corrigé rapidement.
# Flatpak, Snappy, AppImage
Posté par swilmet . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 3. Dernière modification le 08 octobre 2016 à 20:47.
Ton application utilise Qt, mais le runtime Flatpak pour Qt/KDE est toujours en développement. Flatpak a pour l'instant un meilleur support pour GTK+/GNOME (puisque Flatpak est principalement développé par des développeurs GNOME).
Donc, pour l'instant je conseillerais AppImage pour une application Qt (même si j'ai jamais essayé moi-même, il parait que ça fonctionne bien).
AppImage s'occupe uniquement de l'empaquetage/installation. Flatpak et Snappy vont plus loin pour isoler les applications dans une sandbox.
Entre Flapak et Snappy, j'ai tendance à préférer Flatpak. Lire cet article par exemple.
[^] # Re: Wayland et copier-coller à la souris
Posté par swilmet . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2.
Effectivement :
https://fedoraproject.org/wiki/Wayland_features#BLOCKER:_primary_selection
Le copier/coller en sélectionnant du texte puis en le collant en faisant un click milieu s'appelle Primary selection.
[^] # Re: Un avis
Posté par swilmet . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2.
Mais les développeurs GNOME risquent de ne plus maintenir File Roller.
[^] # Re: Un avis
Posté par swilmet . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2.
Nautilus utilise la bibliothèque gnome-autoar pour compresser/décompresser les archives. Peut-être que File Roller utilise la même bibliothèque, je ne sais pas.
Pour la raison d'avoir intégré ça à Nautilus, voir le post de Carlos Soriano:
[^] # Re: Un "progrès" rigolo de Wayland...
Posté par swilmet . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 4.
Wayland (le protocole) n'y est pour rien. C'est l'architecture de mutter/gnome-shell qui est en faute ici. Lit ce commentaire :
https://bugzilla.redhat.com/show_bug.cgi?id=1367666#c4
[^] # Re: Flatpak
Posté par swilmet . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 6.
Plusieurs applications peuvent utiliser le même runtime, le runtime est partagé. Si une application a besoin d'une bibliothèque qui n'est pas présente dans le runtime, cette bibliothèque doit être "bundlée" avec l'application.
Il peut y avoir plusieurs runtime bien entendu : il y a le runtime freedesktop.org, un runtime GNOME, un runtime pour Qt/KDE est en développement, et certaines entreprises ont leur propre runtime. Et il y a généralement plusieurs versions pour un certain runtime : GNOME 3.20, GNOME 3.22, etc.
L'énorme avantage, pour un développeur d'application, c'est que le développement et les tests sont faits avec un runtime précis (et une version précise). Par exemple le runtime GNOME 3.22. Quand GNOME 3.24 sortira, l'application pourra toujours utiliser le runtime GNOME 3.22, donc il y a beaucoup plus de garanties que l'application fonctionnera toujours bien (càd les utilisateurs utilisent la même chose que ce que les développeurs ont utilisé).
Certes, ça utilisera plus de RAM puisque toutes les applications n'utiliseront pas la même version du runtime. Mais de la RAM, les ordinateurs récents en ont assez, et avoir des applications moins buggées (et qui demande moins de travail pour les développeurs) semble être plus important.
[^] # GNOME Classic, GNOME Flashback, avoir du code en commun dans des bibliothèques, …
Posté par swilmet . En réponse à la dépêche Sortie de MATE 1.16. Évalué à 6.
Je suis tout à fait d'accord, Mate a forké l'ensemble de GNOME 2, alors qu'il aurait suffit de continuer de maintenir metacity, gnome-panel, gnome-applets et quelques autres modules.
Au début de GNOME 3, il y avait le mode fallback qui utilisait toujours metacity et gnome-panel. Puis ces modules sont devenus obsolètes, avec la session GNOME Classic comme remplacement. GNOME Classic est un ensemble d'extensions de gnome-shell, et qui sont bien maintenues (à la sortie d'une nouvelle version de GNOME, GNOME Classic fonctionne directement). Pour lancer GNOME Classic, il suffit de choisir cette session dans gdm (sur Fedora, GNOME Classic est déjà installé; sur RHEL/CentOS 7, GNOME Classic est la session par défaut).
Pour metacity, gnome-panel etc, au moment où ça a été rendu obsolète, il y a eu une annonce comme quoi d'autres développeurs pouvaient reprendre le flambeau. Ce qui a donné GNOME Flashback (je ne sais pas vraiment ce qu'il en est à l'heure actuelle, je ne sais pas si c'est bien maintenu).
Ceci dit, puisque Mate a forké l'ensemble de GNOME 2, toutes les applications de Mate ont toujours une barre de menu et barre d'outils, à la place d'une headerbar pour la plupart des applications de GNOME 3 maintenant. Par exemple pour totem je trouve la headerbar et le menu hamburger pas mal, mais je préférais la barre de menu et barre d'outils pour gedit.
Dans le cas de gedit, il y a pas mal d'efforts ces dernières années pour rendre le code davantage réutilisable (i.e. avoir du code en commun dans une bibliothèque), avec comme but de pouvoir créer un éditeur de texte aussi bien que gedit, mais beaucoup plus facilement qu'actuellement (au lieu de forker ~60k lignes de code, ne forker par exemple que ~5k lignes). (oui je suis à l'origine de cette initiative).
Donc, il y a d'autres solutions.
[^] # Re: autre système de financement
Posté par swilmet . En réponse au journal elementary OS 0.4 Loki, l'autre Linux pour êtres humains. Évalué à 3.
Sauf que si personne ne paye pour ce genre de logiciels libres (qui sont quand même assez appréciés et utilisés), ces logiciels libres ne seront plus développés, et un logiciel propriétaire prendra le dessus à la place.
Par exemple pas mal de monde a l'air d'apprécier Sublime Text (et de payer pour), mais les gens devraient se souvenir que c'est un logiciel propriétaire, et qu'il y a des éditeurs de texte libres qui acceptent les donations.
Le marché du desktop vise principalement le grand public (les entreprises aussi, pour ça il y a Red Hat et SUSE par exemple qui ont aussi des offres pour le desktop). Ce que je veux dire par là est que la plupart des applications desktop, ou le desktop lui-même, sont destinés au grand public, pour un usage personnel. Donc si très peu d'utilisateurs payent pour ces logiciels libres, le logiciel propriétaire prendra le dessus (ou plutôt, le logiciel libre ne prendra pas les devants).
[^] # Re: Ce manuel est publié sous licence GPLv3
Posté par swilmet . En réponse à la dépêche Les cahiers du débutant Debian, un guide non conventionnel ouvert en écriture. Évalué à 3.
La GPL est plutôt faite pour les logiciels, pas les manuels.
Voir la FAQ sur gnu.org:
https://www.gnu.org/licenses/gpl-faq.html#WhyNotGPLForManuals
Ceci dit, je trouve l'initiative une excellente chose !
[^] # Re: Et les tests?
Posté par swilmet . En réponse au sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :. Évalué à 1.
Quand j'écris des tests unitaires, je me console en me disant que ce sera utile (et ça l'est vraiment). Et quand je découvre un bug, je me dis que j'ai bien fait d'écrire des tests. Mais bon c'est clair que ce n'est pas la partie la plus amusante.
[^] # Re: Programmation Orientée Objets ?
Posté par swilmet . En réponse à la dépêche Sortie de it-edit (Integrated Terminals Editor) 2.91. Évalué à 1.
Il y a beaucoup de choses possibles à faire dans GtkSourceView.
Si tu trouves un bug, ou que tu trouves que la documentation à un endroit n'est pas claire, tu peux toujours rapporter un bug sur le bugzilla. Pareil pour les demandes de fonctionnalités, si tu trouves que ça a du sens d'implémenter ça dans GtkSourceView.
Pour créer des style schemes graphiquement, il y a un plugin de gedit. Il y a surement moyen de rendre le code réutilisable. Voir cette page wiki pour rendre le code de gedit davantage réutilisable.
En suivant les versions LTS d'Ubuntu, ça ne garanti pas à ton programme qu'il fonctionne sur une version plus récente de GTK+ 3 (par exemple pour le CSS, il y a eu des changements importants dans GTK+ 3.20 qui demandent des adaptations). Les développeurs GNOME utilisent Jhbuild pour compiler toutes les sources à partir de Git, sans interférer avec les paquets de la distro.
PS: tu fais beaucoup de fautes d'orthographe et de grammaire… Mais je suppose qu'on te l'a déjà dit ;-)
# Programmation Orientée Objets ?
Posté par swilmet . En réponse à la dépêche Sortie de it-edit (Integrated Terminals Editor) 2.91. Évalué à 6.
Ça fait plaisir de voir que mon travail dans GtkSourceView sert à quelque chose.
Je vois que tu ne suis pas vraiment la Programmation Orientée Objets. Oui, en C c'est possible aussi. Il y a bien sûr la bibliothèque GObject, mais sans GObject il y a quand même moyen d'écrire du code semi-orienté-objets facilement. Mais quand on écrit une application en GTK+, c'est de toute façon recommandé d'écrire ses propres classes GObject, comme la plupart des applications GNOME font.
J'ai récemment rajouté une section "Semi-Object-Oriented Programming in C" dans un tutoriel sur GLib/GTK+ que je suis en train d'écrire.
En tout cas, bonne continuation dans IT-Edit !
(Ça me rappelle mes débuts avec LaTeXila, à l'époque où je parlais encore de mes projets sur LinuxFr…)
[^] # Re: Une autre manière de faire
Posté par swilmet . En réponse au journal Playtag : paramètres de lecture audio/vidéo en métadonnées. Évalué à 1.
GVfs permet d'écrire et lire des métadonnées. Soit en ligne de commande avec gvfs-set-attribute et gvfs-info, soit en utilisant l'API de GIO.
C'est ce qu'utilise par exemple gedit pour enregistrer des métadonnées, comme par exemple la position du curseur, la langue pour la correction orthographique, le langage utilisé pour la coloration syntaxique, le type d'encodage des caractères (UTF-8, …), etc.
# Livres qui m'ont le plus appris
Posté par swilmet . En réponse au journal Comment être un développeur désirable. Évalué à 2.
Si je devais ne recommander qu'un seul livre, ce serait Code Complete. Oui, c'est édité par Microsoft Press, mais le livre n'a pas grand chose à voir avec Microsoft ou Windows. C'est avec ce livre que j'ai le plus appris, pour écrire du code propre et plus stable, plus maintenable, etc. J'ai écris cet article sur mon blog à propos de Code Complete.
Pour la programmation orientée objets, le livre qui m'a le plus appris est Object-Oriented Design Heuristics. J'ai aussi écris un article sur mon blog pour ce livre.
Voilà, j'ai lu beaucoup d'autres bouquins, mais ces deux-là, c'est ceux que je recommande le plus.
[^] # Re: Vous pouvez répéter la question ?
Posté par swilmet . En réponse au sondage Êtes-vous prof ?. Évalué à 4.
LinuxFr != LinuxFrance
Il y a aussi des belges, des suisses, des canadiens, …
[^] # Re: gedit
Posté par swilmet . En réponse à la dépêche GNOME 3.18 Göteborg est disponible. Évalué à 2.
Si, GtkSourceView est une sous-classe de GtkTextView. Mais la correction orthographique n'est pas implémentée par GtkSourceView (c'est mieux d'avoir une bibliothèque séparée, comme ça GtkSourceView ne dépend pas d'Enchant).
[^] # Re: gedit
Posté par swilmet . En réponse à la dépêche GNOME 3.18 Göteborg est disponible. Évalué à 1.
En bref, gspell rajoute le support pour la correction orthographique pour une application GTK+. (c'est la description qu'il y a dans le fichier README).
[^] # Re: gedit
Posté par swilmet . En réponse à la dépêche GNOME 3.18 Göteborg est disponible. Évalué à 6. Dernière modification le 06 octobre 2015 à 11:53.
Pour la correction orthographique, il y déjà Enchant qui s'occupe de la partie backend. Enchant fait une abstraction des différents moteurs de dictionnaires (hunspell, aspell, etc), et a une API pour savoir si un mot est bien orthographié, avoir une liste de suggestions, avoir la liste des langues supportées, et quelques autres trucs. Enchant ne dépend que de GLib, il n'y a pas d'interface graphique.
Ce que faisait le plugin de gedit, et donc maintenant gspell, est d'ajouter le support pour GtkTextView, qui est le widget pour afficher plusieurs lignes de texte (la base d'un éditeur de texte, ou pour une zone de texte dans un formulaire). Donc gspell dépend de GTK+. Le travail que j'ai fait était de rendre le code de gedit réutilisable, le moderniser (utiliser les nouvelles API de GLib et GTK+), faire quelques améliorations, etc.
Pour l'instant (à ma connaissance), gspell n'est utilisé que par LaTeXila. Mais il est bien entendu prévu d'utiliser gspell dans le plugin de gedit. Ce qui est prévu dans un futur plus lointain est le support pour GtkEntry, qui est un autre widget de GTK+ pour l'édition d'une seule ligne de texte (pour écrire son message dans un client IRC par exemple, ou une zone de texte plus courte dans un formulaire).
# À quand une LFS basée sur OSTree ?
Posté par swilmet . En réponse à la dépêche Linux From Scratch 7.8 : nouvelle version de la distro dont vous êtes le dictateur !. Évalué à 3.
Fedora/RHEL se lancent dans le monde des conteneurs (Docker, xdg-app).
Le projet Atomic (encore un autre buzzword), est un OS fait pour installer uniquement des conteneurs, qui est basé sur rpm-ostree, qui est basé sur OSTree (un projet GNOME initialement). Avec rpm-ostree, c'est un tout autre modèle de déploiement, de mises à jours, les rollbacks sont possibles, etc.
Pour le desktop, une Fedora "Atomic" Workstation est en préparation aussi. Lire à ce sujet ce mail qui explique assez bien le contexte, et qu'un système sans état (stateless) était déjà un des objectifs il y a plus de 10 ans, ce qui a conduit aux LiveCD (un OS générique qui fonctionne partout, sans besoin de config/état, par exemple pas besoin de config d'X.org, tout le matériel est détecté au démarrage).
# gedit
Posté par swilmet . En réponse à la dépêche GNOME 3.18 Göteborg est disponible. Évalué à 5.
Dans la dépêche :
le lien devrait plutôt pointer vers la version 3.17.2 de gedit.
Pour le refactoring de code dans la correction orthographique, le but était de créer une nouvelle librairie, appelée gspell, ce qui est maintenant fait (la première version devrait sortir bientôt). Voir ce billet de mon blog. Normalement pour la version 3.20 de GNOME, gspell sera présent dans les notes de version (pour l'instant gspell ne fait pas encore partie de GNOME).
[^] # Re: Santé du projet, une idée ?
Posté par swilmet . En réponse à la dépêche GNOME 3.18 Göteborg est disponible. Évalué à 4.
s/le dépôt/les dépôts/
En gros, Red Hat fait la majeure partie du travail. En nombre de commits, lignes de code, et surtout mainteneurs. Dans GNOME les mainteneurs ont tout le « pouvoir » sur leurs modules, il n'y a pas de comité au-dessus en ce qui concerne les décisions techniques. (La GNOME Foundation s'occupe des trucs légaux, les finances, les conférences, etc, mais pas les décisions techniques).
Donc, comme Red Hat a beaucoup de mainteneurs dans GNOME, Red Hat a beaucoup de pouvoirs de décision sur la direction de GNOME. Ce qui n'arrange pas toujours d'autres entreprises, comme Canonical qui a préféré développer Unity.
Mais ce serait intéressant d'avoir des statistiques sur l'ensemble de GNOME, pas seulement GLib/GTK+.
[^] # Re: Roadmap AMDGPU
Posté par swilmet . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 5.
Les conférences du XDC 2015 ont été filmées, voir les liens sur :
http://www.x.org/wiki/Events/XDC2015/Program/
Ça a été très bien enregistré/encodé.
Comme conférence pas trop technique, il y a « Sustaining X development » de Keith Packard.
[^] # Re: Et sans compter les manipulateurs politique
Posté par swilmet . En réponse au journal Wikipédia, Anonymat et honnêteté : un gros réseau d'éditeurs Wikipédia payés demantelé. Évalué à 1.
Ce genre de problèmes ne peut pas être remonté aux admins ? Ou en tout cas à des gens qui ont plus de « pouvoirs » sur Wikipédia ?
# Avoir des mainteneurs de pages et revues des changements
Posté par swilmet . En réponse au journal Wikipédia, Anonymat et honnêteté : un gros réseau d'éditeurs Wikipédia payés demantelé. Évalué à 4.
Avec un wiki, n'importe qui peut modifier une page. La barrière d'entrée est donc assez basse, ce qui est un avantage pour qu'il y ait plus de contributions.
D'un autre côté les logiciels libres sont développés différemment. Il y a des mainteneurs et des revues de code. Quand un contributeur a fait pas mal de contributions (par exemple 200 commits), il peut devenir mainteneur (éventuellement que pour une partie du code, au début). Pour certains projets, les mainteneurs peuvent pusher leurs changements directement (pour les petits changements), et il y a des post-reviews si les autres mainteneurs ont du temps.
Le gros problème avec les reviews, c'est que ça peut prendre du temps pour avoir une réponse, ce qui freine énormément les contributions. Il faut des mainteneurs actifs.
Est-ce une solution pour Wikipédia ? Ça rendrait sans doute l'encyclopédie plus crédible, j'ai souvent entendu des remarques négatives à ce sujet (de gens qui ne connaissent pas bien le libre), puisque « n'importe qui peut éditer les pages, on peut tomber sur des articles de mauvaise qualité », ce qui n'est pas tout à fait faux. En pratique on peut se restreindre à lire les contenus de qualité, où quand il y a du vandalisme sur ces pages, c'est sans doute remarqué et corrigé rapidement.
[^] # Re: [X] Lennarx
Posté par swilmet . En réponse au sondage comment doit-on appeler les systèmes d'exploitation basés sur un noyau Linux ?. Évalué à 8.
Rien que GCC, qui fait bien entendu partie de GNU, fait plus que 83KLOC.
Tu oublies aussi que GNOME est un projet GNU.
Comment as-tu récupéré ces statistiques ? Ça me parait complètement faux.