Il est possible d'importer des images. Il n'y a toutefois pas de recadrage automatique. Paperwork permet juste une édition minimaliste des pages/images : rognage et rotation de 90/180/270 degrés.
Maintenant, je ne suis pas sûr qu'utiliser son téléphone pour scanner des documents soit une bonne idée. J'ai déjà entendu et lu plusieurs personnes se plaindre du temps que ça prend pour scanner les piles de papiers qu'ils avaient accumulées jusque là avec un scanner. Je ne peux qu'imaginer le temps que ça prendrait avec un téléphone (temps de transfert sur l'ordinateur et import dans Paperwork, photos partiellement floues à refaire, etc).
Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire
Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique. À ma connaissance, c'est toujours un package par librairie ou programme. Il me semble clair que pour eux, il est hors de question de faire un paquet contenant un programme et 10 librairies. Sinon l'intérêt des dépendances se perd, et on en arrive à ce que font les installateurs Windows ou PC-BSD.
Au final, que je package ou pas Paperwork avec ses dépendances n'aidera en rien les packageurs des distributions.
Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS
Nop. Mon poil dans la main est trop gros pour supporter des OS propriétaires. Si quelqu'un veut le faire, qu'il se fasse plaisir, mais je ne le ferais pas. Par contre, je veux bien faire du support pour cette personne si elle en a besoin et je ne suis pas contre l'inclusion de patchs ayant pour but la portabilité.
Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.
Sur ce point on est d'accord. C'est pour ça que j'essaye de maintenir une liste des dépendances aussi complète que possible. C'est aussi pour ça que j'essaye d'éviter les dépendances ésotériques et que je favorise autant que possible les librairies déjà disponibles dans Debian. (je n'aime pas plus qu'un autre avoir 25 librairies installées en dehors de mon gestionnaire de paquets)
Je n'ai jamais dit que je comptais en faire un logiciel dédié Debian. J'ai juste dit que Debian est la distribution que j'utilise et sur laquelle je le développe, et que c'est donc la seule dans laquelle ça m'importe vraiment de voir Paperwork packagé. Si d'autres le packagent aussi, tant mieux, sinon tant pis.
Pour info, je teste aussi de temps en temps Paperwork sur Fedora et Ubuntu.
Si tu veux des testeurs, il faut qu'ils puissent installer en dehors des repos officiels
Le fait est qu'un certain nombre de personnes ont déjà réussi à l'installer. Essentiellement des utilisateurs de Debian, Ubuntu et Fedora je présume. ArchLinux est plus problématique vu que la version par défaut de Python sur cette distribution est Python 3. C'est là encore un problème qui se résoudra de lui-même quand je ferais le passage à Python 3.
Le mieux que je puisse faire est de documenter la liste des dépendances, et pour les distributions les plus courantes, indiquer comment les installer. Je n'ai définitivement pas l'intention de me prendre la tête à faire un meta-package volumineux qui ne fonctionnera que sur une distribution sur deux. Je n'ai pas non plus l'intention de faire moi-même des paquets pour chaque distribution/architecture.
Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.
tu remarques que ce sont les premiers rapports de "bugs" de ton logiciel
Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.
Certaines des dépendances sont abandonnées en upstream
La seule que je connaisse qui semble abandonnée est PIL (corrigez-moi si je me trompe). J'ai l'intention de la remplacer par Pillow.
Si tu en as vu d'autres, ça m’intéresse.
« Je n'embarque pas les dépendances, car je ne veux pas ré-inventé la roue ».
Ta formulation est mauvaise,
En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.
Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.
Je comprends qu'actuellement toutes ces dépendances sont problématiques. Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.
Je suis toujours ouvert à la discussion. J'invite ceux qui ont des idées à venir en discuter sur la mailing-list (en anglais, please). Pour l'IHM, l'idéal serait d'en discuter mock-ups à l'appui. Glade, bien qu'un peu buggué, peut être assez pratique pour ça.
Pour les dépendances Python, disons juste que je préfère en avoir beaucoup plutôt que de réinventer la roue. Après, à terme, ça sera aux gestionnaires de paquets de résoudre ce problème.
Pour les 13 dépendances, c'est juste une question pour moi de ne pas réinventer la roue. Quant à la pérennisation de la base de données, pour l'heure, la question ne se pose pas : l'organisation du répertoire de travail est très simple et fait usage de bêtes fichiers JPG et hOCR (text/html) (cf la doc de hacking). C'est ce répertoire qui fait référence, et l'index est automatiquement mis à jour en conséquence au démarrage de Paperwork.
Pour les noms: L'objectif est "scan&forget", pas "scan&name&forget" :). Déjà devoir labeliser les documents est une étape de trop à mon goût (mais j'ai quelques idées pour arranger ça). Je ne souhaite pas encourager les utilisateurs à nommer systématiquement leurs documents. D'après mon expérience, les miniatures suffisent à reconnaitre un document bien plus vite qu'un nom.
Il est toutefois possible, au besoin, d'ajouter des mots clefs sur le document, mais pas de le nommer. Si tu y tiens vraiment, tu peux renommer le dossier contenant le document différemment de la nomenclature normalement adoptée. Dans ce cas, Paperwork utilisera le nom du dossier tel quel sans essayer de le parser. Ça va faire des misères pour ordonner ensuite les documents mais bon.
Pour les exports PDF, le texte n'est pas encore inclus dans le PDF généré. À noter aussi que lorsqu'on exporte en PDF un document qui était un PDF à l'origine, Paperwork se contente de faire une copie. (c'est vrai que je n'ai pas vraiment pensé au cas du PDF qui a l'origine ne contient pas de texte mais que une image)
Actuellement il est déjà possible d'importer des images et des PDFs dans Paperwork.
Par contre l'import d'un dossier d'images complet est plus compliqué, vu que chaque personne aura sa propre façon d'organiser le-dit dossier à importer. J'ai quelques idées sur comment importer ce qui sera vraisemblablement les organisations les plus courantes, mais ce n'est pas prévu pour la 0.1.
En attendant, pour ceux qui savent scripter, c'est un problème qui peut se résoudre à grand coup de scripts shell. J'ai inclus les informations nécessaire dans la doc de hacking pour ceux que ça intéresse. En fait il suffit d'arranger et nommer les fichiers dans le répertoire de travail de la même façon que Paperwork.
Je ne les sélectionne pas :)
En fait je passe le texte tel-quel à Whoosh. C'est lui qui se charge de l'indexation, de la recherche et des suggestions.
Pour Scribo, je ne connaissais pas. Je vais voir pour l'intégrer à PyOCR. Pour ce qui est de l'interaction, actuellement, c'est fait de façon relativement crade: Paperwork (via PyOCR) exécute tout simplement Tesseract comme commande shell. Je suppose que Scribo peut aussi être lancé depuis le shell, donc je ne devrais pas avoir de soucis pour l'intégrer.
En fait, Tesseract fournit aussi une librairie C++, mais du coup ce n'est pas simple à binder sur du Python (du moins sans rajouter une autre dépendance), et je n'ai trouvé aucune documentation expliquant comment l'utiliser. Donc j'ai juste laissé tombé (pour le moment)
Ah non désolé. Ça fait un moment que je n'ai plus de ArchLinux installée. Si je trouve la motivation et le temps, je vais essayer d'en installer une ce week-end dans une VM. Ça me permettra de compléter le README. (pas de garantie ceci dit)
Hm. J'ai pushé un fix temporaire sur Paperwork, mais il faudra que j'examine ça plus en détails dès que j'ai du temps. Il semblerait que j'ai cassé l'import d'image. Je ne vois juste pas comment j'ai pu rater ça, et il faudra que je vois comment faire un fix propre.
Tesseract et Cuneiform ont besoin de fichiers de data pour chaque langue avec lesquelles tu souhaite travailler.
Là l'exception indique qu'aucun fichier de data n'a été trouvé.
Si tu utilises Ubuntu ou Debian: sudo apt-get install tesseract-ocr-fra .
Je viens de voir que doc dans le README était tronquée sur ce point (une erreur de ma part dans le markdown). C'est corrigé.
Pour les pertes de dossiers, c'est plus que bizarre. J'ai du mal à voir ce qui pourrait causer ça dans Paperwork.
Quant à l'import, quand il continue à tourner indéfiniment, généralement, c'est qu'il y a eut une exception Python non-catchée. Es-tu sûr que tu n'as aucune exception dans le terminal ? (éventuellement un peu plus haut que les 2 messages que tu as cité)
Vu que ça me semble être une réponse potentiellement pertinente à ta question, j'en profite pour me faire un peu de pub.
Je travaille depuis un moment sur un programme appelé Paperwork. C'est un client lourd (Python/Gtk), et pour des questions de performances, je recommande d'avoir les documents en local. Ceci dit, rien n’empêche d'avoir les documents en local et de les rsync périodiquement sur ton NAS (mieux vaut avoir trop de copies de ses documents que pas assez).
J'ai moi-même eut des soucis avec Gnome 3 et le pilote Nvidia propriétaire. J'avais des performances catastrophiques sur une machine qui pourtant était, il n'y a pas si longtemps encore, une bête de courses. En fait le problème venait de la version du pilote Nvidia propriétaire fournit dans Debian testing. J'ai pris la version du pilote Nvidia de Debian unstable, et maintenant ça tourne.
(par contre, si c'est bien aussi ta situation, je suis désolé, mais je ne retrouve plus les instructions pour passer sur le pilote sid)
Juste à titre de remarque, certains des points que tu donnes peuvent se retrouver plus ou moins dans les Human Interface Guidelines de Gnome.
Notamment:
- Conserver la simplicité et rendre joli : "utilisez des révélations progressives et d'autres techniques pour limiter la quantité de choses que l'utilisateur voit à chaque instant."
- Sensibilité : "Il est souvent préférable de rendre un contrôle insensible plutôt que de le masquer complètement"
Si c'est le cas, j'espère qu'un jour certains finiront par comprendre que l'ironie et le second degré sont des intonations de voix qui passent mal par les câbles réseaux …
je n'ai jamais entendu d'admin sys qui se plaignait de la taille des icones
D'admin sys je ne sais pas, mais de programmeur, j'en connais un: Moi-même. Classiquement, dans la catégorie des trucs chiants à cliquer qui m'agacent fortement, il y a les sous-sous-menus. Même avec une bonne maîtrise de la souris, qui n'a jamais raté son coup et changé de sous-menu par accident ? Il se trouve que je met les menus "Applications", "Raccourcis" et "Système" de Gnome 2 dans ce panier. Tant et si bien que je ne m'en servais jamais et préférais utiliser les raccourcis claviers "Ouvrir un terminal" et "Lancer une commande" tout le temps.
Bah non, c'est peut-être mieux pour les handicapés, mais je ne suis pas handicapé, et je n'ai absolument pas de problème pour cliquer sur une icone de 32x32 pixels.
Les menus Gnome 2, sauf erreur de ma part, c'est du 24x24 (ce n'est pas si négligeable comme différence). Je ne suis pas handicapé, et pourtant il m'est déjà arrivé de lancer la mauvaise application via les menus Gnome 2 (la fatigue du Vendredi soir dira-t-on). Je n'ai encore jamais eut ce problème avec Gnome 3. Sans compter que la taille des icônes et de noms de catégories de Gnome 3 permet de naviguer dans les menus d'applications à la souris beaucoup plus vite qu'avec Gnome 2 (à ce sujet, je maintiens que l'excuse des traversées d'écran est une mauvaise excuse).
J'ai vaguement l'impression qu'à force de privilégier les nullos, on finisse par perdre de la productivité.
Personnellement, j'ai vaguement l'impression qu'à force de privilégier les nullos, on obtient une interface qui se concentre sur la productivité plutôt que des possibilités de personnalisations à l'utilité discutable.
je ne pense pas qu'il soit souhaitable de cacher les détails aux utilisateurs
Pourtant, entre démocratiser Linux ou faire des interfaces compliquées, il faudra choisir.
il existe une différence réelle entre un programme fermé et un programme minimisé. Les interfaces modernes ont tendance à confondre les deux concepts
Gnome 3 a éjecté le bouton "réduire" de la barre de titre des fenêtres par défaut. Ça évite justement cette confusion.
Pour l'anecdote, je n'ai jamais vu d'utilisateur non-informaticien minimiser une fenêtre volontairement. Jamais. Les informaticiens Linuxiens que je connais utilisent les bureaux virtuels, donc ils minimisent peu voir pas. Et au final, personnellement, je pense que la fonction "exposée" rend vraiment complètement inutile la fonction "minimiser". Je ne comprends même pas que les devs Gnome 3 aient gardé l'option.
on cache une subtilité essentielle qui pourrait s'avérer critique en cas de problème
Il ne devrait pas y avoir de problème dans un premier temps. De toute façon, si il y a un problème, quel qu'il soit, tu peux être sûr d'une chose: L'utilisateur lambda sera perdu et frustré. Lui il veut juste "que ça marche". Pour lui, tout le reste n'est qu'excuses pour justifier l'inaptitude de l'informatique et des informaticiens à résoudre son problème. Si ça ne marche pas vite et bien, il retournera au programme qu'il utilisait avant (Windows par exemple), et c'est tout.
[^] # Re: purge
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2.
Pour la catégorie de document, un label devrait faire l'affaire, non ?
[^] # Re: Import de photos
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 4.
Il est possible d'importer des images. Il n'y a toutefois pas de recadrage automatique. Paperwork permet juste une édition minimaliste des pages/images : rognage et rotation de 90/180/270 degrés.
Maintenant, je ne suis pas sûr qu'utiliser son téléphone pour scanner des documents soit une bonne idée. J'ai déjà entendu et lu plusieurs personnes se plaindre du temps que ça prend pour scanner les piles de papiers qu'ils avaient accumulées jusque là avec un scanner. Je ne peux qu'imaginer le temps que ça prendrait avec un téléphone (temps de transfert sur l'ordinateur et import dans Paperwork, photos partiellement floues à refaire, etc).
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2. Dernière modification le 06 mai 2013 à 13:56.
Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique. À ma connaissance, c'est toujours un package par librairie ou programme. Il me semble clair que pour eux, il est hors de question de faire un paquet contenant un programme et 10 librairies. Sinon l'intérêt des dépendances se perd, et on en arrive à ce que font les installateurs Windows ou PC-BSD.
Au final, que je package ou pas Paperwork avec ses dépendances n'aidera en rien les packageurs des distributions.
Nop. Mon poil dans la main est trop gros pour supporter des OS propriétaires. Si quelqu'un veut le faire, qu'il se fasse plaisir, mais je ne le ferais pas. Par contre, je veux bien faire du support pour cette personne si elle en a besoin et je ne suis pas contre l'inclusion de patchs ayant pour but la portabilité.
Sur ce point on est d'accord. C'est pour ça que j'essaye de maintenir une liste des dépendances aussi complète que possible. C'est aussi pour ça que j'essaye d'éviter les dépendances ésotériques et que je favorise autant que possible les librairies déjà disponibles dans Debian. (je n'aime pas plus qu'un autre avoir 25 librairies installées en dehors de mon gestionnaire de paquets)
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 5.
Je n'ai jamais dit que je comptais en faire un logiciel dédié Debian. J'ai juste dit que Debian est la distribution que j'utilise et sur laquelle je le développe, et que c'est donc la seule dans laquelle ça m'importe vraiment de voir Paperwork packagé. Si d'autres le packagent aussi, tant mieux, sinon tant pis.
Pour info, je teste aussi de temps en temps Paperwork sur Fedora et Ubuntu.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2.
Le fait est qu'un certain nombre de personnes ont déjà réussi à l'installer. Essentiellement des utilisateurs de Debian, Ubuntu et Fedora je présume. ArchLinux est plus problématique vu que la version par défaut de Python sur cette distribution est Python 3. C'est là encore un problème qui se résoudra de lui-même quand je ferais le passage à Python 3.
Le mieux que je puisse faire est de documenter la liste des dépendances, et pour les distributions les plus courantes, indiquer comment les installer. Je n'ai définitivement pas l'intention de me prendre la tête à faire un meta-package volumineux qui ne fonctionnera que sur une distribution sur deux. Je n'ai pas non plus l'intention de faire moi-même des paquets pour chaque distribution/architecture.
Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.
Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 3.
La seule que je connaisse qui semble abandonnée est PIL (corrigez-moi si je me trompe). J'ai l'intention de la remplacer par Pillow.
Si tu en as vu d'autres, ça m’intéresse.
En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.
Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.
Je comprends qu'actuellement toutes ces dépendances sont problématiques. Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.
[^] # Re: Forces et Faiblesses
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 4. Dernière modification le 06 mai 2013 à 10:34.
Je suis toujours ouvert à la discussion. J'invite ceux qui ont des idées à venir en discuter sur la mailing-list (en anglais, please). Pour l'IHM, l'idéal serait d'en discuter mock-ups à l'appui. Glade, bien qu'un peu buggué, peut être assez pratique pour ça.
Pour les dépendances Python, disons juste que je préfère en avoir beaucoup plutôt que de réinventer la roue. Après, à terme, ça sera aux gestionnaires de paquets de résoudre ce problème.
[^] # Re: petits retours rapides
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 5.
Pour les 13 dépendances, c'est juste une question pour moi de ne pas réinventer la roue. Quant à la pérennisation de la base de données, pour l'heure, la question ne se pose pas : l'organisation du répertoire de travail est très simple et fait usage de bêtes fichiers JPG et hOCR (text/html) (cf la doc de hacking). C'est ce répertoire qui fait référence, et l'index est automatiquement mis à jour en conséquence au démarrage de Paperwork.
Pour les noms: L'objectif est "scan&forget", pas "scan&name&forget" :). Déjà devoir labeliser les documents est une étape de trop à mon goût (mais j'ai quelques idées pour arranger ça). Je ne souhaite pas encourager les utilisateurs à nommer systématiquement leurs documents. D'après mon expérience, les miniatures suffisent à reconnaitre un document bien plus vite qu'un nom.
Il est toutefois possible, au besoin, d'ajouter des mots clefs sur le document, mais pas de le nommer. Si tu y tiens vraiment, tu peux renommer le dossier contenant le document différemment de la nomenclature normalement adoptée. Dans ce cas, Paperwork utilisera le nom du dossier tel quel sans essayer de le parser. Ça va faire des misères pour ordonner ensuite les documents mais bon.
Pour les exports PDF, le texte n'est pas encore inclus dans le PDF généré. À noter aussi que lorsqu'on exporte en PDF un document qui était un PDF à l'origine, Paperwork se contente de faire une copie. (c'est vrai que je n'ai pas vraiment pensé au cas du PDF qui a l'origine ne contient pas de texte mais que une image)
[^] # Re: Et sans scan connecté ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Tout à fait :)
[^] # Re: Et sans scan connecté ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Actuellement il est déjà possible d'importer des images et des PDFs dans Paperwork.
Par contre l'import d'un dossier d'images complet est plus compliqué, vu que chaque personne aura sa propre façon d'organiser le-dit dossier à importer. J'ai quelques idées sur comment importer ce qui sera vraisemblablement les organisations les plus courantes, mais ce n'est pas prévu pour la 0.1.
En attendant, pour ceux qui savent scripter, c'est un problème qui peut se résoudre à grand coup de scripts shell. J'ai inclus les informations nécessaire dans la doc de hacking pour ceux que ça intéresse. En fait il suffit d'arranger et nommer les fichiers dans le répertoire de travail de la même façon que Paperwork.
[^] # Re: Comment ca marche ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Je ne les sélectionne pas :)
En fait je passe le texte tel-quel à Whoosh. C'est lui qui se charge de l'indexation, de la recherche et des suggestions.
Pour Scribo, je ne connaissais pas. Je vais voir pour l'intégrer à PyOCR. Pour ce qui est de l'interaction, actuellement, c'est fait de façon relativement crade: Paperwork (via PyOCR) exécute tout simplement Tesseract comme commande shell. Je suppose que Scribo peut aussi être lancé depuis le shell, donc je ne devrais pas avoir de soucis pour l'intégrer.
En fait, Tesseract fournit aussi une librairie C++, mais du coup ce n'est pas simple à binder sur du Python (du moins sans rajouter une autre dépendance), et je n'ai trouvé aucune documentation expliquant comment l'utiliser. Donc j'ai juste laissé tombé (pour le moment)
[^] # Re: A tester
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 1.
En l’occurrence l'adresse en question est obsolète. Mais tu as raison, mieux vaut être trop prudent que pas assez. C'est rectifié.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Oui, un passage à Python 3 est prévu. Ce sera fait dès que toutes les dépendances de Paperwork seront disponibles pour Python 3.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 1.
Ah non désolé. Ça fait un moment que je n'ai plus de ArchLinux installée. Si je trouve la motivation et le temps, je vais essayer d'en installer une ce week-end dans une VM. Ça me permettra de compléter le README. (pas de garantie ceci dit)
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Désolé, je crois que j'ai mal lu la stacktrace et l'exception la 1ère fois. En fait, il s'agirait plutôt du cas où il n'a pas trouvé d'OCR du tout.
Pour info, pour savoir si Tesseract est disponible, Pyocr cherche simplement la commande "tesseract" dans le PATH.
À tout hasard, quelle distribution Linux utilises-tu ?
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Hm. J'ai pushé un fix temporaire sur Paperwork, mais il faudra que j'examine ça plus en détails dès que j'ai du temps. Il semblerait que j'ai cassé l'import d'image. Je ne vois juste pas comment j'ai pu rater ça, et il faudra que je vois comment faire un fix propre.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 1.
Tesseract et Cuneiform ont besoin de fichiers de data pour chaque langue avec lesquelles tu souhaite travailler.
Là l'exception indique qu'aucun fichier de data n'a été trouvé.
Si tu utilises Ubuntu ou Debian: sudo apt-get install tesseract-ocr-fra .
Je viens de voir que doc dans le README était tronquée sur ce point (une erreur de ma part dans le markdown). C'est corrigé.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 2.
Il me faudrait aussi la stacktrace qui devait être juste en-dessous de l'exception s'il-te-plait.
[^] # Re: Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 1.
Pour les pertes de dossiers, c'est plus que bizarre. J'ai du mal à voir ce qui pourrait causer ça dans Paperwork.
Quant à l'import, quand il continue à tourner indéfiniment, généralement, c'est qu'il y a eut une exception Python non-catchée. Es-tu sûr que tu n'as aucune exception dans le terminal ? (éventuellement un peu plus haut que les 2 messages que tu as cité)
# Paperwork ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperless.... Évalué à 10. Dernière modification le 19 avril 2013 à 19:03.
Vu que ça me semble être une réponse potentiellement pertinente à ta question, j'en profite pour me faire un peu de pub.
Je travaille depuis un moment sur un programme appelé Paperwork. C'est un client lourd (Python/Gtk), et pour des questions de performances, je recommande d'avoir les documents en local. Ceci dit, rien n’empêche d'avoir les documents en local et de les rsync périodiquement sur ton NAS (mieux vaut avoir trop de copies de ses documents que pas assez).
[^] # Re: Comment dire...
Posté par Jérôme Flesch (site web personnel) . En réponse au journal L'ergonomie de GNOME 3. Évalué à 3.
Des fois que ça aide:
J'ai moi-même eut des soucis avec Gnome 3 et le pilote Nvidia propriétaire. J'avais des performances catastrophiques sur une machine qui pourtant était, il n'y a pas si longtemps encore, une bête de courses. En fait le problème venait de la version du pilote Nvidia propriétaire fournit dans Debian testing. J'ai pris la version du pilote Nvidia de Debian unstable, et maintenant ça tourne.
(par contre, si c'est bien aussi ta situation, je suis désolé, mais je ne retrouve plus les instructions pour passer sur le pilote sid)
[^] # Re: Dans quel monde parallèle je vis ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal L'ergonomie de GNOME 3. Évalué à 1.
Juste à titre de remarque, certains des points que tu donnes peuvent se retrouver plus ou moins dans les Human Interface Guidelines de Gnome.
Notamment:
- Conserver la simplicité et rendre joli : "utilisez des révélations progressives et d'autres techniques pour limiter la quantité de choses que l'utilisateur voit à chaque instant."
- Sensibilité : "Il est souvent préférable de rendre un contrôle insensible plutôt que de le masquer complètement"
[^] # Re: frustration palpable à des kilomètres
Posté par Jérôme Flesch (site web personnel) . En réponse au journal la fin de msn ?. Évalué à 5.
Si c'est le cas, j'espère qu'un jour certains finiront par comprendre que l'ironie et le second degré sont des intonations de voix qui passent mal par les câbles réseaux …
[^] # Re: Difficilement contestable
Posté par Jérôme Flesch (site web personnel) . En réponse au journal L'ergonomie de GNOME 3. Évalué à 5. Dernière modification le 26 novembre 2012 à 18:00.
D'admin sys je ne sais pas, mais de programmeur, j'en connais un: Moi-même. Classiquement, dans la catégorie des trucs chiants à cliquer qui m'agacent fortement, il y a les sous-sous-menus. Même avec une bonne maîtrise de la souris, qui n'a jamais raté son coup et changé de sous-menu par accident ? Il se trouve que je met les menus "Applications", "Raccourcis" et "Système" de Gnome 2 dans ce panier. Tant et si bien que je ne m'en servais jamais et préférais utiliser les raccourcis claviers "Ouvrir un terminal" et "Lancer une commande" tout le temps.
Les menus Gnome 2, sauf erreur de ma part, c'est du 24x24 (ce n'est pas si négligeable comme différence). Je ne suis pas handicapé, et pourtant il m'est déjà arrivé de lancer la mauvaise application via les menus Gnome 2 (la fatigue du Vendredi soir dira-t-on). Je n'ai encore jamais eut ce problème avec Gnome 3. Sans compter que la taille des icônes et de noms de catégories de Gnome 3 permet de naviguer dans les menus d'applications à la souris beaucoup plus vite qu'avec Gnome 2 (à ce sujet, je maintiens que l'excuse des traversées d'écran est une mauvaise excuse).
Personnellement, j'ai vaguement l'impression qu'à force de privilégier les nullos, on obtient une interface qui se concentre sur la productivité plutôt que des possibilités de personnalisations à l'utilité discutable.
Pourtant, entre démocratiser Linux ou faire des interfaces compliquées, il faudra choisir.
Gnome 3 a éjecté le bouton "réduire" de la barre de titre des fenêtres par défaut. Ça évite justement cette confusion.
Pour l'anecdote, je n'ai jamais vu d'utilisateur non-informaticien minimiser une fenêtre volontairement. Jamais. Les informaticiens Linuxiens que je connais utilisent les bureaux virtuels, donc ils minimisent peu voir pas. Et au final, personnellement, je pense que la fonction "exposée" rend vraiment complètement inutile la fonction "minimiser". Je ne comprends même pas que les devs Gnome 3 aient gardé l'option.
Il ne devrait pas y avoir de problème dans un premier temps. De toute façon, si il y a un problème, quel qu'il soit, tu peux être sûr d'une chose: L'utilisateur lambda sera perdu et frustré. Lui il veut juste "que ça marche". Pour lui, tout le reste n'est qu'excuses pour justifier l'inaptitude de l'informatique et des informaticiens à résoudre son problème. Si ça ne marche pas vite et bien, il retournera au programme qu'il utilisait avant (Windows par exemple), et c'est tout.
[^] # Re: Difficilement contestable
Posté par Jérôme Flesch (site web personnel) . En réponse au journal L'ergonomie de GNOME 3. Évalué à -2.
Une interface destinée aux handicapés et une interface qui peut aussi être utilisée par des handicapées sont deux choses différentes.