Jérôme Flesch a écrit 379 commentaires

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.

Je serais plus que content d'utiliser le format DjVu pour les scans au lieu de ma bouillabaisse à base de JPEG+hOCR.
Le problème, c'est qu'à l'heure actuelle, à ma connaissance, il n'y aucune libraire C ou Python libre pour générer des fichiers DjVu.

La dernière fois que j'ai regardé, DjvuLibre ne proposait qu'une librairie pour la lecture de fichiers DjVu, et des outils en ligne de commande pour leur génération. Je dois déjà faire des fork()+exec() pour Tesseract, et ça m'embête déjà bien. Je refuse de faire des fork()+exec() pour générer les fichiers DjVu.

Ayant moi-même une Brother MFC (pour tester Paperwork principalement), pour ma part, j'aurais plutôt tendance à les déconseiller. Même si ça semble être du très bon matériel, logiciellement ça pêche :

• En fonction de la distribution, l'installateur et les pilotes Brother marchent plus ou moins bien: Pas de problème avec Ubuntu Gnome 16.10, mais je n'ai pas réussi à les faire marcher sur Debian sid.
• Sauf erreur de ma part, les drivers Brother sont entièrement propriétaires. Pour l'instant ils fonctionnent, mais le jour où Brother en aura marre de les maintenir, ça va devenir de plus en plus compliqué de les utiliser avec une distribution à jour. Jusqu'au moment où ce ne sera plus possible, et la seule option sera de racheter une imprimante …

Pour info, le nom du paquet manquant ici, dans Debian/Ubuntu, c'est gir1.2-poppler-0.18.
Gnome a introduit les GIR (GObject Introspection Repositories) pour pouvoir générer automatiquement les bindings pour chaque langage à la volée, rendant les paquets comme python-poppler obsolètes.

Si un utilisateur de Mageia aurait le temps de compléter paperwork-shell avec les listes de paquets Mageia, ça serait cool :
https://github.com/jflesch/paperwork-backend/blob/unstable/src/paperwork/backend/shell_cmd.py#L22
https://github.com/jflesch/paperwork-backend/blob/unstable/src/paperwork/backend/deps.py
https://github.com/jflesch/paperwork/blob/unstable/src/paperwork/deps.py

Personnellement, j'ai une préférence pour les scanners/imprimantes HP. Matériellement ils sont moyens. Les drivers sont acceptables mais sans plus. Mais HP fournit des pilotes Linux open-source, donc tu branches en USB et ça marche.
Il y a juste parfois un apt install hplip à faire. Au pire, si le matériel est trop récent, il faut faire une installation manuelle pas-hyper-compliquée des pilotes HP.

À ma connaissance ils font systématiquement des pilotes Linux open-source, mais je ne suis pas 100% certain.

Paperwork considère que 1 PDF = 1 document. Et paperwork a pour principe de ne jamais modifier les PDFs qu'on lui donne.

Sinon, il est possible d'importer des images (1 image = 1 page). Mais dans ce cas, Paperwork ne permet d'importer qu'une seule image à la fois pour le moment.

Actuellement, ce n'est donc malheureusement pas possible tel quel. Dans ton cas, je pense que le plus simple serait de scripter la fusion des pages recto avec les pages verso en utilisant des outils en ligne de commande. Bon ok, pour l'aspect intuitif et user-friendly, on repassera …

Les contributeurs et moi-même avons essayé de faire un logiciel aussi intuitif que possible. Pour moi, l'interface est très claire et explicite (sinon je ne l'aurais pas fait comme ça ;). Du coup je ne suis pas trop sûr de ce qui devrait être documenté ("tout" diraient certains, mais je manque de temps, et maintenir une doc détaillée à jour est un poids en plus non négligeable).

Je te propose de prendre le problème dans l'autre sens : Qu'est-ce qui ne te semble pas clair ? / Qu'est-ce que tu essayes de faire avec ?

Ton outil deviendrait indispensable pour lire les documents.

Il me semble que sqlite3 peut être utilisé avec des scripts shell sans problème. Je ne suis donc pas convaincu que ce soit un problème.

Ce qui me gêne déjà un peu plus, c'est la synchro avec des outils comme SparkleShare ou OwnCloud .. Je présents qu'ils vont re-uploader toute la BDD sqlite à chaque modification. Sur ma connexion ADSL moisie à 200ko/s / 75ko/s max, ça va piquer :/

Je n’ai pas tenté d’importer ainsi des PDF en même temps que Paperwork fonctionne. Je pense que Paperwork n’apprécierait pas…

En fait, il ne le verra juste pas jusqu'à son prochain démarrage. Quand il redémarrera, il le verra au moment où il parcours le répertoire de travail pour trouver les changements.
Je pense que le seul risque, c'est une collision de nom quand Paperwork tente d'ajouter un document. Mais vu qu'il y a les secondes dans les noms de fichiers, ça me semble très improbable.

Du temps de Paperwork 0.2, plusieurs s'y sont essayés et ont abandonné. Au final, seul PyOCR a été packagé, mais la version dans Debian est maintenant complètement obsolète :(

Le problème vient surtout des dépendances. Même si ça été simplifié depuis la 0.2, il faudrait quand même packager:

• Paperwork-backend
• Pyinsane 2
• Pyocr à jour
• libpillowfight

Ce sont des modules Python tout ce qu'il y a de classique, donc je suppose qu'une fois le premier fait, les autres sont faciles à faire.

J'ai failli oublier:

• on ne peut importer qu'un fichier a la fois ?

Une image (JPG, PNG, etc) à la fois oui. Sinon c'est compliqué de deviner où la placer.

Par contre, pour les PDFs, c'est déjà possible. Il suffit d'indiquer à Paperwork un dossier contenant plusieurs PDFs. Il va le parcourir (récursivement si ma mémoire est bonne), et importer chaque PDF comme un document distinct.

• open directory plnate le docker: sh: 1: xdg-open: not found

Euh, xdg-open fait partie des normes freedesktop à ma connaissance. Il faudrait l'inclure dans l'image Docker en fait.
Quoiqu'il en soit, ce sera résolu dans la version 1.0.3. Au lieu de xdg-open, cette version utilisera Gtk.show_uri() qui semble bien plus fiable.

• quand tu fais une recherche par mot-cle, comment faire pour voir l'endroit du document qui contient ce mot-cle ?

Tu cliques sur le document .. :-)
Plus sérieusement:
- quand les pages sont affichées en grille, celles qui contiennent un des mots clés sont entourées en vert.
- quand elles sont affichées en liste (en grand), les mots clés eux-mêmes sont entourés en vert.

Par contre, ça met quelques secondes à s'afficher.
(et en terme de clarté d'affichage, j'ai encore du travail ..)

L'organisation du répertoire de travail est documentée ici:
https://github.com/jflesch/paperwork/wiki/Work-directory-organization

L'organisation des fichiers est effectivement spécifique à Paperwork. Mais les formats des fichiers sont tous standards (JPEG, hOCR, CSV et PDF), et je pense pouvoir dire que cette organisation se prête bien au scripting shell.

Ceci dit, pour bien plus tard, il y a quelques évolutions possibles envisagées pour les documents scannés :

• Zipper les fichiers d'un même document ensemble. Je me dis que ça pourrais économiser un peu les inodes et les blocs disques partiellement utilisées. À voir si ça serait vraiment utile.
• Utiliser le format DjVu. Là le problème, c'est qu'il y a djvulibre pour lire les fichiers DjVu, mais il n'y a aucune librarie C/C++/Python pour en créer (attention, je ne parle pas de wrapper autour des commandes de DjvuLibre ; ça il y en a plein, mais c'est saleeuuuu).
• Stocker les labels dans une base sqlite. Parce-que le problème actuellement, c'est que les opérations sur les labels ne sont pas atomiques du tout. Si tu changes le nom d'un label mais qu'une coupure de courant zigouille Paperwork pendant l'opération vous allez avoir une moitié de labels modifiés et pas l'autre.