En installant gnome-software et en utilisant gnome-shell (le desktop GNOME). Je ne sais pas si dans Unity il y a cette fonctionnalité. Mais les dernières versions d'Ubuntu utilisent gnome-software aussi (sous un autre nom).
Pour le contenu principal (en-dehors des commentaires), c'est utile de savoir combien de gens ont apprécié le contenu. Pour les commentaires, ça peut aussi être utile, mais ça l'est moins que pour le contenu principal. Connaitre en détail combien de fois on s'est fait moinssé, non merci. Certains sites n'ont absolument aucune note sur les commentaires, et ça se passe plutôt bien. Mais ça peut être utile, quand on est pressé, de ne lire que les commentaires les mieux notés. Pareil pour le contenu principal, ne lire que les contenus les mieux notés. Peut-être qu'il ne devrait y avoir qu'un +1, comme sur Google+.
Je prend un exemple que je connais bien, GNOME. Les dernières dépêches sur GNOME sont, je trouve, très longues. Et ce n'est pas très utile parce que GNOME, en amont, publie des notes de version détaillées, et traduites en français !
Donc, au lieu d'écrire des dépêches de plus en plus longues, une dépêche peut très bien être assez courte, avec un résumé et un lien vers les notes de version officielles. Ça ne sert à rien de se fatiguer à réinventer la roue.
Par contre, ce qui est plus utile, c'est de publier plus régulièrement des dépêches ou journaux quand un truc important se produit dans un des projets, même s'il n'y a pas de nouvelle version. GNOME sort une version tous les 6 mois, mais il peut y avoir des choses intéressantes à raconter à un autre moment.
Pareil pour Fedora.
Less is more. Quantité/qualité. Quantité : nombre de contenus, mais aussi longueur des contenus. Un contenu de qualité peut être assez court.
Totalement d'accord, voir en détail, pour chaque commentaire, le nombre de fois qu'il a été moinssé, c'est inhumain.
Il y a plusieurs années, j'écrivais régulièrement du contenu et des commentaires. Puis quand est apparu les notes détaillées des commentaires, j'ai trouvé ça horrible, et j'ai préféré ne plus venir sur LinuxFr (de toute façon le contenu est moins bien que sur LWN, par exemple).
Les user/group IDs dynamique, ça permet d'installer/lancer un service, et s'assurer que quand ce service est stoppé/désinstallé, le système soit redevenu comme avant, à part éventuellement les data et les logs.
Si pour lancer un service, ce service a besoin de créer un utilisateur ou un groupe, quand le service est stoppé il faut que l'utilisateur/groupe soit retiré. Pour avoir un système sans état (stateless). Les UID/GID fixes font partie de l'état.
Donc en gros l'idée c'est d'installer son OS, que l'image de cet OS soit read-only, qu'il y ait toujours moyen de revenir à cet état (factory reset), et que pour lancer des services, ces services créent (temporairement) l'état qu'ils ont besoin. Quand un "service portable" est stoppé/désinstallé, systemd s'assurera de faire un revert de tout l'état qu'a modifié ce service (en gardant les données à ne pas supprimer, bien entendu).
Et un "service portable" sera portable du fait que ça fonctionnera sur n'importe quelle distribution Linux (avec une version suffisamment récente du noyau et de systemd). C'est un container, mais mieux intégré au système (moins isolé). C'est une solution plus sécurisée, pour remplacer les super privileged containers.
Sur l'annonce officielle, il est écrit qu'une nouvelle version majeure de GTK+ aura lieu tous les 2-3 ans.
Si la période est plus longue, ça risque d'être plus difficile de porter du code à la nouvelle version. Si la période est plus courte, les mainteneurs de GTK+ ont plus de versions à maintenir. Donc 2-3 ans est un certain compromis. 2 ans est déjà appliqué dans d'autres projets : Debian (plus ou moins), Ubuntu LTS, …
De manière générale, quand quelque chose est pénible/difficile (ici porter son code à une nouvelle version de GTK+), il vaut mieux le faire plus souvent. Voir cet article de Martin Fowler.
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.
[^] # Re: Chocking
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 6.
Peux-tu expliquer en détail pourquoi ? Est-ce que tu t'y connais suffisamment techniquement pour avoir de bons arguments ?
Chez moi PulseAudio fonctionne très bien, je n'ai rien à lui reprocher.
[^] # Re: Chocking
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 8.
Red Hat fait effectivement énormément de choses pour le desktop. (Bien plus que Canonical).
Deux exemples récents :
libinput, voir cet article :
Un meilleur support des systèmes dual-GPU, voir cet article.
Mais Red Hat ne fait pas tout le boulot, d'autres entreprises et des particuliers contribuent aussi à un meilleur desktop sous Linux.
[^] # Re: Proposer des noms
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 0.
Zapus la fin.
(De l'alphabet bien entendu).
[^] # Re: Signification de Yakkety Yak
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 1.
Résultats plus pertinents dans un moteur de recherche ?
[^] # Re: Intégration app store
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 2.
En installant gnome-software et en utilisant gnome-shell (le desktop GNOME). Je ne sais pas si dans Unity il y a cette fonctionnalité. Mais les dernières versions d'Ubuntu utilisent gnome-software aussi (sous un autre nom).
[^] # Re: Moins de lynchage - plus de pédagogie
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à -1.
Repenser le système des votes pertinent/inutile.
Pour le contenu principal (en-dehors des commentaires), c'est utile de savoir combien de gens ont apprécié le contenu. Pour les commentaires, ça peut aussi être utile, mais ça l'est moins que pour le contenu principal. Connaitre en détail combien de fois on s'est fait moinssé, non merci. Certains sites n'ont absolument aucune note sur les commentaires, et ça se passe plutôt bien. Mais ça peut être utile, quand on est pressé, de ne lire que les commentaires les mieux notés. Pareil pour le contenu principal, ne lire que les contenus les mieux notés. Peut-être qu'il ne devrait y avoir qu'un +1, comme sur Google+.
[^] # (Trop) longues dépêches
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 7.
Je prend un exemple que je connais bien, GNOME. Les dernières dépêches sur GNOME sont, je trouve, très longues. Et ce n'est pas très utile parce que GNOME, en amont, publie des notes de version détaillées, et traduites en français !
Donc, au lieu d'écrire des dépêches de plus en plus longues, une dépêche peut très bien être assez courte, avec un résumé et un lien vers les notes de version officielles. Ça ne sert à rien de se fatiguer à réinventer la roue.
Par contre, ce qui est plus utile, c'est de publier plus régulièrement des dépêches ou journaux quand un truc important se produit dans un des projets, même s'il n'y a pas de nouvelle version. GNOME sort une version tous les 6 mois, mais il peut y avoir des choses intéressantes à raconter à un autre moment.
Pareil pour Fedora.
Less is more. Quantité/qualité. Quantité : nombre de contenus, mais aussi longueur des contenus. Un contenu de qualité peut être assez court.
[^] # Re: Moins de lynchage - plus de pédagogie
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à -4.
Totalement d'accord, voir en détail, pour chaque commentaire, le nombre de fois qu'il a été moinssé, c'est inhumain.
Il y a plusieurs années, j'écrivais régulièrement du contenu et des commentaires. Puis quand est apparu les notes détaillées des commentaires, j'ai trouvé ça horrible, et j'ai préféré ne plus venir sur LinuxFr (de toute façon le contenu est moins bien que sur LWN, par exemple).
[^] # Re: Vivement 'dredi
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Vidéos de la systemd.conf. Évalué à 5.
Les user/group IDs dynamique, ça permet d'installer/lancer un service, et s'assurer que quand ce service est stoppé/désinstallé, le système soit redevenu comme avant, à part éventuellement les data et les logs.
Si pour lancer un service, ce service a besoin de créer un utilisateur ou un groupe, quand le service est stoppé il faut que l'utilisateur/groupe soit retiré. Pour avoir un système sans état (stateless). Les UID/GID fixes font partie de l'état.
Donc en gros l'idée c'est d'installer son OS, que l'image de cet OS soit read-only, qu'il y ait toujours moyen de revenir à cet état (factory reset), et que pour lancer des services, ces services créent (temporairement) l'état qu'ils ont besoin. Quand un "service portable" est stoppé/désinstallé, systemd s'assurera de faire un revert de tout l'état qu'a modifié ce service (en gardant les données à ne pas supprimer, bien entendu).
Et un "service portable" sera portable du fait que ça fonctionnera sur n'importe quelle distribution Linux (avec une version suffisamment récente du noyau et de systemd). C'est un container, mais mieux intégré au système (moins isolé). C'est une solution plus sécurisée, pour remplacer les super privileged containers.
[^] # Re: Nixos...
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Vidéos de la systemd.conf. Évalué à 3.
Ton fichier de config tu peux le mettre dans Git. Pour un re-déployement c'est plus facile.
[^] # Re: GTK+4
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 3.
Sur l'annonce officielle, il est écrit qu'une nouvelle version majeure de GTK+ aura lieu tous les 2-3 ans.
Si la période est plus longue, ça risque d'être plus difficile de porter du code à la nouvelle version. Si la période est plus courte, les mainteneurs de GTK+ ont plus de versions à maintenir. Donc 2-3 ans est un certain compromis. 2 ans est déjà appliqué dans d'autres projets : Debian (plus ou moins), Ubuntu LTS, …
De manière générale, quand quelque chose est pénible/difficile (ici porter son code à une nouvelle version de GTK+), il vaut mieux le faire plus souvent. Voir cet article de Martin Fowler.
# Flatpak, Snappy, AppImage
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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.