Jérôme Flesch a écrit 390 commentaires

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.

En fait, de mon point de vue, la question était un peu différente:

Dans un premier temps, j'ai fait ce début de jeu pour le fun. C'est quelque-chose qui me démangeait depuis longtemps et je l'ai fait pour moi.

Dans un deuxième temps, il s'agissait de savoir si cette idée de jeu pouvait intéresser des gens et si ça valait le coup pour moi que j'y investisse plus de temps. L'idée était de continuer à m'y investir proportionnellement à l'intérêt que ça peut avoir.
Il ne s'agissait donc pas vraiment d'obtenir des fonds pour. Atteindre les 4000 euros avait en soit peu d'intérêt. Ce que je voulais savoir, c'est si cette idée avait de la valeur au point que des gens seraient prêts à donner de l'argent pour.
Faire de la publicité pour cette campagne aurait donc été contre-productif. Ça aurait juste biaisé le résultat.

Et donc là la résultat fût net: Personne n'est prêt à mettre 5€ pour un jeu comme ça (les 10€, c'est ma petite amie :). Donc juste pas de raison de que je passe plus de temps dessus. Fondamentalement, même si le ton de mon journal peut avoir donné l'impression du contraire, je ne suis pas aigri ni frustré par ce résultat (bon OK, le 0 absolu … un petit peu quand même … ;).

Je l'ai fait avec Python 3.5. Ceci dit, je pensais que cette syntaxe existait déjà avec Python 3.4.

à moins biensûr que du travail n'ait été repris en dehors de git.

Nop, tout a été fait dans Git directement :-)

j'ai juste constaté que mon ordi soufflait pas mal

Je n'ai pas creusé beaucoup ce point, mais je crois que c'est un soucis lié à Pygame, au pilotes graphiques et au type même du jeu: Le jeu est assez agressif en terme de 2D (le circuit bouge relativement par rapport à la voiture --> rafraîchissement complet de l'écran à chaque frame). Or l'accéleration 2D sous Linux, en fonction du pilote de la carte graphique, semble être entre inexistante et pas-terrible. Faute d'accéleration GPU, je suppose que c'est le CPU qui fait toute.

Pour l'anecdote, j'avais de meilleures perfs sur mon portable avec une carte Intel (~50 à 100 FPS) que sur mon fixe avec une carte Radeon (~20 à 25 FPS).

pour ma part je verrais bien ce style de jeu dans un bundle avec plein d'autres

Il faudrait que quelqu'un prenne le temps de le finir par contre …

Ma source d'inspiration principale était Super Car II. Pour le coup, tu viens de m'apprendre que ce type de jeu avait un nom à lui :-)

5€ ne me semblait pas déraisonnable. Question de point de vue je suppose.