Jérôme Flesch a écrit 345 commentaires

Il y a le souci quand même de l'export/import des tickets.

Et le wiki (même si GitHub le stocke comme un dépôt Git).

Et, encore plus compliqué à migrer, la visibilité: J'ai un projet avec >2000 étoiles sur Github. Bien classé dans les résultats de recherche GitHub (et dans une moindre mesure dans les résultats Google&co). Si j'efface les dépôts de GitHub, je vais perdre cette visibilité.

Pourquoi migrer ? Je dirais pour ne pas attendre que Microsoft trouve un moyen de planter un couteau dans le dos à ses utilisateurs.

Le premier problème que je vois venir, c'est ce qui est arrivé à LinkedIn. Avant son rachat, LinkedIn était à-peu-près utilisable. Depuis, mon ressenti, c'est que l'interface est devenue nettement plus chargée. Il y a notamment nettement plus de publicités (encart en haut à droite, post d'actualité "promu", etc). Depuis le rachat, LinkedIn me propose aussi de suivre un seul et unique "influenceur": Bill Gates. Pour un anti-Microsoft primaire comme moi, je trouve ça très ironique.

Une fois racheté, il faut que ce soit le plus rentable possible, et donc le plus pourri possible. Je suis donc certain qu'ils trouveront d'autres moyens de pourrir la vie de leurs utilisateurs.

Donc une fois le rachat confirmé, le plan pour moi:
- Tout les dépôts OpenPaperwork seront migrés sur gitlab.gnome.org (changement prévu de longue dates de toute façon).
- Tout mes dépôts personnels seront migrés soit sur framagit.org soit sur un serveur perso.

Ça veut peut-être aussi dire ne plus vendre leurs produits aux États-Unis (téléphones, ordinateurs, etc).

Au fait, question bête: y a-t-il une mailing-list dédiée à Gnome-scan ?

Si tu es celui qui a essayé d'envoyer un rapport récemment, il manque (pour une raison que j'ignore) le nom de ton OS dans le rapport --> exception Python à la reception --> 500. C'est corrigé coté serveur. Je verrais à partir des traces pourquoi il manque l'OS.
Pour l'erreur 502, c'est un rapport trop volumineux (la limite de 20Mo est sensée être large déjà pourtant :/). En scannant en plus basse résolution, il y aura peut-être moins de traces.

Pyinsane lance un processus en arrière-plan pour faire effectivement toutes les manipulations. Le but est de faire en sorte que si le driver Sane crash, l'application ne crash pas. De même, si le driver Sane corrompt la mémoire, il ne va pas corrompre celle de l'application. Ici, on dirait que ce processus de Pyinsane a crashé. Mais il me faudrait les autres traces pour voir si je peux deviner ce qui s'est passé.

Est-ce que tu pourrais quand même envoyer le rapport s'il-te-plaît ? Il te faudra juste préciser manuellement le nom du fabriquant et le modèle.

Mon scanner est configuré pour que lorsque je scan depuis l'appareil en appuyant sur une touche, le pdf généré est transféré par ftp dans un dossier sur mon serveur (pas de nouveau fichier créer dedans par contre). Cela a-t-il pu interférer avec ironscanner qui n'a pu récupérer le scan ?

Aucune idée. C'est typiquement le genre de choses qui dépend entièrement du scanner et de son pilote .. :/
Si tu trouves la réponse un jour, je suis intéressé.

Utiliser GLib directement dans la lib bas niveau rend la lib dépendante de la GLib, ce qui peut être un soucis pour l'utiliser avec Qt.

Le plan est de faire la librairie en C pur, et de lui rajouter un chapeau GObject (dans le même style que Poppler).
Pour Qt: https://wiki.gnome.org/Projects/GObjectIntrospection/GObjectConsume .

Python avec cffi ?

Parce-qu'il n'y a pas que Python. Avec l'introspection GObject, la librairie pourrait bénéficier aussi aux programmes C++, C#, Java, etc. C'est là tout son intérêt.

Je suppose qu'idéalement ta lib serait réutilisée par Gnome Simple Scan et autres outils similaires.

Il y a quelques mois, j'avais eut une première discussion avec des devs Gnome pour l'inclusion de Paperwork sur gnome.org. C'est là qu'il m'avait été suggéré de refaire Pyinsane et Pyocr en C+GObject, justement pour que ça puisse être réutilisé dans les autres projets Gnome. Je trouve que c'est une très bonne idée pour Pyinsane. (pour Pyocr, mouais bof, c'est une librairie qui passe bien en Python, mais elle risque d'être très lourde à refaire en C).

j'espère que ça ira quand même

C'est parfait.

Si je stocke les scans, c'est pour répondre à quelques questions que je me posais:

• Est-ce que tout les scanners ont un ratio x/y correct ? ;
• Est-ce que tout les scanners renvoient bien des images de même taille pour les mêmes réglages (même résolution + page A4, etc) ;
• Si la page et/ou la zone de scan est plus petite que ce que le scanner prétend pouvoir scanner au maximum, est-ce qu'il rempli avec du blanc ou du noir ?

Ce que tu as scanné permet de répondre grosso-modo à ces questions pour ton scanner.

pyinsane2.sane.rawapi.SaneException: : Data is invalid (4)

Ah oui, cette erreur, je la vois parfois avec les scanners Brother (et quelques autres). Je ne sais pas quoi en penser pour le moment :/

Arf raté, wiasane fait l'inverse en fait. Il faut que j'apprenne à lire moi.

https://github.com/mback2k/wiasane
Comme ça on pourra cumuler les problèmes des deux APIs ;)

Plus sérieusement, j'y ai songé. Mais ce que j'ai constaté, c'est que ça a peu de chance de bien marcher. Pyinsane a une API similaire à Sane (historique). C'est un de mes plus gros problèmes de conception: l'API WIA rentre mal dedans. Je l'ai faite rentrer au chausse-pieds.

Le problème de base est le suivant:

• Pour un scanner, Sane propose une séries d'options (+ valeurs + contraintes + etc)
• Pour un scanner, WIA propose un arbre de périphérique: Le scanner a ses propres options, mais chaque source du scanner (Lit, bac d'alimentation, vaisseau spatial, etc) a les siennes aussi. Et elles ne correspondent pas forcément d'une source à l'autre sur un même scanner. Par exemple, tu peux avoir deux options "resolution" avec des contraintes différentes sur différentes sources du scanner.

Dans le cas spécifique de wiasane, j'ai cru voir qu'il passe par l'API d'automatisation WIA plutôt que l'API "bas-niveau". Elle marche généralement mieux, mais elle a une limitation qui m'embête beaucoup: Il est impossible de recevoir l'image numérisation au fur et à mesure de la numérisation (sauf erreur de ma part, comme toujours).

C'est pas du tout adapté pour créer de nouvelles ergonomies.
(…)
Donc note bien : les valeurs aussi ne sont pas cohérentes d'un pilote à l'autre

Ah ça j'ai vu. Pire que ça, certains pilotes traduisent les noms des options et les valeurs … ça promet des workarounds intéressants.
Simple-scan contient aussi un joli lot de workarounds. Je me rend compte que tout les logiciels de scan sous Linux (et je suppose Windows) ont eut affaire aux même problèmes. Du coup, une des idées en refaissant ma librairie est d'essayer de proposer une base commune saine pour tout les workarounds.

Tu ne pourrais jamais mettre tout le monde sur la table et fixer une fois pour toute ce truc, même pour les options de bases.

Ça ne va pas m'empêcher d'essayer ;-)
Plus sérieusement, mon objectif est de pouvoir de faire de simples numérisations (lit ou bac d'alimentation) avec au moins 90% des scanners sous Linux et Windows. Sous Linux, l'objectif semble atteint. Sous Windows, je suis parti pour en baver.

Je ne cherche pas à supporter les options coincoin (preview, photo, stockage de fichiers, etc). Si quelqu'un d'autre veut s'y casser les dents, il pourra, je n'ai aucun problème à accepter les patchs dans ce sens.

Bref bon courage.

Merci, je sens que je vais en avoir besoin :-)

Comment cela « scanners Windows », c'est du matériel, non  ?

Tu oublies les pilotes et les APIs elles-mêmes:

• Sane a une API bien faite et simple à utiliser. Il est difficile de se planter en implémentant un pilote ou un client .. bien que visiblement certains y arrivent.
• WIA2 est un gros tas de boue beaucoup trop complexe, avec une forte probabilité d'erreur dans les implémentations et d'énormes risques de différences de comportements entre les pilotes. Microsoft propose un système pour tester les pilotes. Mais il ne teste visiblement pas tout et ne corrige en rien les idioties de WIA2. C'est d'autant plus vrai si, comme moi, on passe par l'API WIA2 "bas-niveau" plutôt que l'API d'automatisation WIA2 (qui est plus limitée).

À l'heure actuelle, à vérifier, mais il me semble que Pyinsane supporte facilement > 90% des scanners sous Linux avec Sane. Mais il supporte peut-être tout juste ~25% des scanners sous Windows avec WIA.

capacités du scanner (est-ce un mopieur en plus, permettant d'imprimer par exemple)

C'est dans les options du scanner, dans chaque rapport ("réglages disponibles").

le résultat d'un lsusb (quand connecté en USB)

Sûrement une bonne idée de le rajouter, mais problématique à faire de façon portable (à moins que j'ai manqué une librairie qui le fasse ?). Personnellement, n'ayant pas l'intention d'écrire de pilote, ce n'est pas une information pertinente pour moi. À voir pour le rajouter plus tard.

les interfaces de connexion : wifi, ethernet, usb ou autre (bluetooth ?)

Sauf erreur de ma part, ni WIA ni Sane ne propose d'API pour déterminer ça. Ça peut se deviner aux IDs, tout au plus.

les formats pris en compte (PCL, PDF, autre…)

Valable uniquement dans le cas de WIA2 (option "format" et "preferred_format"). Sane C'est d'ailleurs une des principales idioties de cette API. Et c'est déjà dans les rapports (toujours dans "réglages disponibles").

les fonctions avancées : envoi par mail, dépose de fichier sur répertoire partagé

Non-couvert par Sane à ma connaissance. Partiellement couvert par WIA. L'information n'est pas formatée dans le rapport, mais elle peut se retrouver dans les traces. Personnellement, ce n'est pas une information qui m'intéresse pour mon développement. Peut-être à rajouter plus tard si j'ai le temps.

les interfaces physiques : clé usb, sdcard…

Non-couvert par Sane à ma connaissance. Probablement juste partiellement couvert par WIA, peut-être même pas du tout.

Merci à tout ceux qui ont déjà soumis un rapport. Comme beaucoup d'entre vous ont du le voir, mon travail est loin d'être fini.

Dans les semaines ou mois à venir, si vous recevez un mail écrit dans un anglais approximatif et venant d'un certain "Jérôme Flesch", ne le mettez pas tout de suite dans votre dossier "Spam" s'il-vous-plaît ;-)

Normalement, même si le test échoue, il y a moyen de d'envoyer le rapport complet automatiquement à OpenPaper.work. Dans ton commentaire Linuxfr, il manque plein d'informations, et ça sera trop facile pour moi d'oublier que ce problème existe.

Pourrais-tu refaire le test et envoyer le rapport cette fois-ci s'il-te-plaît ?

Au passage, j'ai pas compris la pop-up "résolution". Le mien est censé être 1200 dpi ou qqchose dans ce style, et je vois des chiffres comme 3267800 dans la sélection.

J'ai un problème similaire avec le backend de test de Sane. Je ne sais encore trop d'où il vient :/

Ah oui, je ne fais que les binaires que pour amd64. À ce stade, je suis honnêtement surpris que quelqu'un ait essayé en 32bits :)
Il reste l'installation manuelle depuis les sources ceci dit.

Arf oui, merci pour le retour :-)

Je suis un peu court niveau temps libre, donc j'ai fait simple:
Je suppose que Pyinstaller a dû zapper de mettre certains fichiers en rapport avec les types mimes dans le paquet. --> Pas le temps ni l'envie de chercher --> En grosse feignasse, j'ai juste désactivé le filtrage pour le moment. Le sélecteur laisse maintenant choisir n'importe-quel fichier.

https://madb.mageia.org/package/show/application/0/name/libxlib-gir2.0

^ Je pense que c'est ce paquet qu'il vous manque à tout les deux. Ceci dit, Pyinstaller aurait dû l'inclure dans l’exécutable :/. Il faudra que je regarde.

1) Personnel: Le C fait partie des quelques langages que je maitrise bien.

2) Technique: Portabilité, mais au sens large. J'aimerais faire une librairie qui puisse servir à autant de monde que possible. Donc je vais la faire cross-platform*, mais aussi cross-langages. Le plan, c'est d'utiliser la GLib et l'introspection GObject pour pouvoir générer des bindings pour un peu tout les langages facilement. On va voir ce que ça donne.

L'aspect performance sera juste la cerise sur le gâteau :-)

[*] Sauf les Mac, parce-que je suis trop pauvre.

Salut,

Désolé de te l'annoncer, mais tu n'as pas encore testé les pires.

Je m'auto-héberge aussi depuis environ 1 an. J'ai vite constaté que les mails que j'envoyais à des adresses @free.fr et @laposte.net étaient rejetés immédiatement par le SMTP. Le SMTP m'accusait de les spammer (ça ne finissait même pas dans le dossier Spam du destinataire). Initialement, il me manquait le SPF, ce j'ai donc rajouté. Pas de changement. Je contacte Laposte et Free pour leur signaler le problème. Ils mettent plusieurs jours à me répondre (heureusement que je ne faisais que tester et que je n'avais pas encore de mail important à envoyer). Ils me disent que c'est corrigé, sans me préciser ce qui est corrigé. Je reteste, ça ne l'est pas. Je relance Free, qui me dit grosso-modo "ah oui oups, ce coup-ci c'est la bonne". Toujours pas. Je n'ai même pas essayé de relancer laposte.

Au final, j'ai laissé tombé. J'ai modifié mon SPF pour pouvoir envoyer mes mails à partir du SMTP de Gandi. Là, ça passe avec tout le monde systématiquement, mais je redeviens partiellement dépendant d'un hébergeur … :(

En bon boulet, je viens de réaliser que "slicks'n'slide" n'est pas le nom du type de jeu, mais bien le nom d'un jeu … Sur ceux, je vais aller me cacher dans un trou …

J'ai regardé. En fait le problème n'était pas le super() mais l'ordre entre le **kwargs et has_engine_sound=True qui n'était pas bon. Visiblement Python >= 3.5 l'accepte, mais pas <= 3.4. C'est rectifié.

Tu as parfaitement raison, mais je ne me voyais pas trop cacher ces informations. Ça ne m'aurait pas semblé très honnête. Toi, tu aurais présenté ça comment ?

Je crois que c'est toi qui a mal lu mon dernier commentaire, donc je reprends:

Je me posais une question: est-ce que ça a assez d'intérêt pour que je poursuive le dev ?
J'ai utilisé Kickstarter comme un outil pour déterminer l'intérêt de la chose (et non pour lever des fonds). La réponse fût sans appel.

Quant à la publicité, je maintiens ce que je disais: Si mon but avait été de lever des fonds et faire plein de brouzoufs, ça aurait été pertinent. Mais là il s'agissait de jauger la valeur de l'idée. La simple présence dans le catalogue Kickstarter a fait que des gens l'ont vu. J'avais les stats KickStater & Google Analytics. Des centaines de personnes l'ont vu. Personne n'a jugé que ça valait 5€. Fin de l'histoire.

Au final, je ne blâme personne, et mon égo se porte très bien : J'ai atteint mes objectifs.
La seule chose qui commence un peu à m'irriter, ce sont les commentaires ici qui supposent que l'état de mon égo était dépendant du résultat du Kickstarter. Ceci dit, je comprends aussi très bien que normalement, un Kickstarter sert avant tout à lever des fonds, d'où cette supposition que plusieurs ont fait. En un sens, c'est ma faute, j'aurais dû penser à préciser directement l'objectif de mon Kickstarter dans le journal.