FLOZz a écrit 134 commentaires

C'est pas vraiment déléguable, et les principales difficultés sont humaines et non techniques (Gitlab dispose d'un système de migration de projet depuis Github, même si on perd généralement l'attribution des issue et des PR).

Le développement GameBoy il faut que je trouve du temps pour m'y remettre, j'ai encore tellement d'aspects à explorer ! Et puis j'aimerais bien sortir un véritable jeu GameBoy sur cartouche un de ces jours... :)

Pourquoi ne pas utiliser la forge officielle du projet Gnome ? C'est sous Gitlab CE : https://gitlab.gnome.org/

La raison est extrêmement simple : à l'époque où ce projet a été créé ainsi qu'à l'époque où il a été migré sur Github, GNOME ne disposait pas encore d'une instance Gitlab.

Migrer un projet d'une forge à une autre demande du temps et du travail ; je n'ai pas le temps ni la motivation de me lancer là-dedans pour le moment.

Pour de nouveaux projets liés à l’environnement GNOME, je considérerais bien sûr la possibilité de les hébergés sur l'instance Gitlab de GNOME, pour peu que les prérequis soient remplis1.

du traçage des contributeurs et des visiteurs, aucune garantie ne peut être apportée quant à ce qu'il est fait des données collectées (exploitation, revente, transmission aux agences gouvernementales américaines, Patriot Act. Cloud Act., Prism...),

La GNOME Foundation est une association basée aux États-Unis. Je leur fais confiance pour ce qui est de ne pas tracer les contributeurs et de ne pas revendre leurs données. Par contre pour ce qui est des lois américaines, je pense qu'ils y sont soumis et que si le gouvernement leur demande des informations sur une personne ils n'auront pas d'autres choix que de coopérer (je peux me tromper sur ce point, je veux bien des liens vers des sources d'informations complémentaires si quelqu'un en a :)).

de l'exclusion : toute personne vivant dans un pays boycotté par le gouvernement américain, est empêchée de proposer ses contributions ; participation impossible des libristes ayant une éthique...

Il est vrai que contribuer sans avoir accès à Github est plus compliqué mais pas impossible. Je reste joignable par e-mail et un miroir du dépôt Git est disponible sur Launchpad :

https://code.launchpad.net/~flozz/nautilus-terminal/+git/nautilus-terminal/+ref/master

---

1 En pratique je m'inquiète surtout de la disponibilité et des capacités des shared runners pour la CI, notamment dans le cas où un runner Windows serait nécessaire pour la construction de version Windows de l'application (mais en pratique il devrait être possible d'exploiter la CI de Github pour une partie des tâches via un dépôt miroir (oui j'ai déjà pas mal réfléchi à la question^^)).

N'hésites pas à reposter lorsque ton logiciel évoluera, j'ai particulièrement apprécié la série sur Pétrolette :)

La série sur Pétrolette est effectivement assez intéressante :)

J'essayerais de refaire un article lors du passage à GTK 4... si j'y survis... ^^'

Il est disponible en paquet pour Manjaro (et donc pour Arch) en version 3.5.0

Oui j'ai vu que le paquet Arch avait été marqué out-of-date, il va sûrement être mis à jour prochainement :)

Merci ! Ça reste l'un de mes articles préféré sur mon blog avec celui sur VIM :)

Effectivement, j'avais vu passé le fork pour Nemo ! :D

Par contre je ne sais pas à quel point il est maintenu / à jour par rapport à Nautilus Terminal :)

Salut,

Non effectivement il n'y a pas de touche pour passer le focus de Nautilus au terminal et inversement. Je note la suggestion pour plus tard :)

Pour ce qui est de GNOME 40 (oui ils ont changés de système de numérotation ^^'), Nautilus n'a pas encore été porté sur GTK 4, il n'y aura donc pas de souci avec Nautilus 40 :)

ça serait pas mal d'avoir une valeur max pour la taille du terminal

Je ne sais pas si c'est possible, il faut que je regarde les propriétés du Widget GTK pour voir

peut-être de retenir la dernière taille choisie par l'utilisateur comme taille par défaut du terminal

Je me note ça dans un coin, merci pour la suggestion :)

Pour les souris Logitech, il y a libratbag / Piper :

• https://github.com/libratbag/piper/

:)

Piper est l'interface graphique du projet libratbag. Il supporte de nombreuses souris Logitech et effectivement 7 souris SteelSeries. Il suffit de regarder les fichiers présents dans le dépôt pour en avoir la liste :

• https://github.com/libratbag/libratbag/tree/master/data/devices

Cependant, libratbag/Piper ne supporte pas toutes les fonctionnalités disponibles sur certains des modèles SteelSeries (en regardant le code source, le mapping des boutons me semble limité par exemple).

Ah oui ! Ça m'a pris un moment à capter ! :D

Bah [...] ça permet de faire plus de ventes à pas cher

Je ne suis pas tout à fait d'accord pour le coup, la formulation de votre message laisse sous-entendre une volonté de tromperie, je ne pense pas que ce soit le cas pour ma part. La plupart des modèles techniquement identiques sont parfaitement identifiables.

Il s'agit le plus souvent d'édition spéciale d'un modèle existant. Par exemple la Sensei TEN et la Sensei TEN CS:GO Neon Rider Editon. Elles sont identiques techniquement, mais la seconde a un imprimé différent. Ici je pense que le lien de parenté est assez clair pour tout consommateur, et je ne vois pas où est le problème de proposer des couleurs ou des motifs différents.

---

Pour ce qui est de Rivalcfg, la seule difficulté avec ces éditions spéciales était d'obtenir le productID de tous les modèles (étant donné qu'il est différent pour chaque édition spéciale). Ce problème est heureusement résolu grâce à la base de donnée qui a été constituée.

Suite à ma discussion avec SteelSeries, j'ai mis à jour l'article sur mon blog avec quelques détails supplémentaires :

https://blog.flozz.fr/2020/08/24/rivalcfg-comment-jai-cree-un-peu-par-hasard-cet-outil-de-configuration-pour-les-souris-steelseries/#quelques-nouvelles-suite-a-une-discussion-avec-steelseries

:)

Ca fait quelques temps que j'utilise ton outil d'abord pour ma Sensei CoD Black Ops II Edition puis ma Sensei 310 aujourd'hui.

Ca tourne au poil. L'existence de ton soft a été décisif dans mon choix de racheter du matériel SteelSeries. Tu peux aller leur demander une pièce !

Merci pour ce retour !

Ça tombe bien, je viens justement de recevoir une Sensei 310, je vais pouvoir m'assurer que tout fonctionne bien, et implémenter le mapping des boutons pour ce modèle ! :D

C'est encourageant une réaction aussi positive de l'entreprise.

Oui, carrément !

Je ne peux pas réparer ton bouton, mais au moins, grâce au mode breath elle peut à présent être recyclée en guirlande de Noël ! ;)

Y a 20 ans quasiment tous les appareils électroniques avait un manuel, avec les schémas complets. La TV de mes parents avait un A1 replié 4 ou 5 fois au fond du manuel avec tous les schémas.

Ah ça... le monde à bien changé depuis... :(

Ahah, merci ! :D

J'ai l'impression que les techs seraient pour ouvrir les specs, mais c'est tout en haut de la hiérarchie que ça refuse. Il n'y a rien de particulier à comprendre je pense, c'est juste politique. Qui sait, peut être que ça changera un jour :)

Je sais qu'il existe des outils comme GPaste qui permettent de gérer un historique des éléments copiés dans le presse papier.

Je pense qu'avec une souris capable d'envoyer des appuies de touche de clavier (comme c'est le cas sur des modèles comme les Rival 3, 300, 310, 500, 600, 650, 700, 710, les Sensei RAW, TEN? et 310) ça doit être faisable de mapper un bouton sur un raccourci clavier permettant de coller un élément particulier de cet historique :)

La dépêche était déjà en modération quand j'ai pu discuter avec eux, c'est pour ça que je n'en parle pas :)

N'étant pas un "gamer" je ne saisis pas pourquoi les souris standard ne conviennent pas. Qu'est-ce que ces souris ont de plus ?

J'apprécie le fait de pouvoir régler la sensibilité de ma souris, c'est l'un des principaux intérêts pour moi. Après je ne crache pas sur les LED de couleurs qui permettent une touche de personnalisation (même si c'est clairement inutile ;)).

Certains des modèles de chez SteelSeries permettent de mapper (matériellement) des boutons de la souris sur des touches de claviers. C'est une fonctionnalité qui m'intéresse de plus en plus : j'aimerais bien pouvoir configurer des raccourcis sur certains boutons pour accélérer mon travail quand je suis sur des logiciels comme Inkscape ou Gimp (pouvoir changer d'outil en utilisant les boutons de la souris).

Vu que SteelSeries est une société danoise, est-ce qu'il ne serait pas bon de les contacter pour leur proposer Rivalcfg ?

Enfin, étant un défenseur de l'interopérabilité, je pense qu'il serait bon d'exiger que les spécifications d'interface soient disponibles. À quand une loi européenne à ce sujet ?

C'est effectivement une société danoise à l'origine. Ils ont racheté Ideazone (une société américaine) il y a quelques années, et je pense que leur équipe technique est essentiellement aux US aujourd'hui.

Quoi qu'il en soit, j'ai posté lundi un message sur leur Reddit, et ils m'ont répondu (j'avais auparavant essayé de les contacter via Twitter sans grand succès). J'ai donc pu discuter avec eux, ils m'ont fournit quelques infos qui m'ont déjà permis d'ajouter une nouvelle souris (la Rival 300S, qui sera du coup dispo dans la v4.1 d'ici quelques temps).

Ils ne peuvent pas libérer les specs de leur matériel pour des raisons politiques interne (visiblement c'est un sujet qui revient sur le tapis régulièrement, et souvent à cause de Rivalcfg :D), mais par contre ils ne voient aucun problème à ce que je fasse le reverse engineering de leur matériel. Ils vont donc m'envoyer des souris pour que je puisse en améliorer le support (j'ai même déjà reçu le tracking du colis, ils ont fait super vite !).

J'avoue que de savoir que SteelSeries n'est pas hostile, ni indifférent au projet me redonne un bon coup de motivation. Et puis avoir un coup de main du fabricant va énormément aider ! :D

Je suis content que Rivalcfg te soit utile ! Ça fait plaisir d'avoir d'autres retours que des rapports de bug des fois :D

Il ne faut pas oublier également que Gitlab (tout comme Github d'ailleurs), propose des API, et je ne pense pas qu'elles cassent tous les 4 matins.

Il est donc également possible d'utiliser ces API pour importer des projets dans une autre forge (tout comme Gitlab le fait pour importer des projets depuis Github, Bitbucket ou Gitea).

Personnellement si je développais une forge, je m’appuierais sur les API pour les imports de projets plutôt que sur l'export ZIP... Ça sera mieux documenté et plus stable dans le temps. :)

Dans le zip exporté, les infos du projet, ses issues, MR, etc. sont exportées dans un JSON qui semble bien structuré. Le dépôt Git et le wiki (qui est aussi un dépôt Git), sont exportés sous forme de bundle Git. Donc il me semble assez facile d'exploiter ces données si on devait les traiter nous-même (import dans une forge exotique ou autre).

La compatibilité des exports entre les versions de Gitlab est également bien documentée.

J'ai utilisé cette fonctionnalité cette semaine encore pour transférer un projet entre deux Gitlab, et ça s'est très bien passé : il a bien réattribué les contributions/issues/merge requests aux bons utilisateurs (qui étaient présents des deux côtés).

J'ai mi à jour le README avec plus d'informations sur le fonctionnement du logiciel. Merci encore de m'avoir fait remarquer à quel point ça manquait.

• https://github.com/flozz/cover-thumbnailer/blob/master/README.md