Jérôme Flesch a écrit 379 commentaires

on va dire que tu pensais avec un ajout "à but non lucratif"

Oui, mea culpa.

l'association a des obligations de non lucrativité
ça ne garanti rien du tout sur la volonté des gens derrière

En fait si.

Dans une association française à but non-lucratif, le président de l'association est élu annuellement par les membres et n'a pas le droit d'être rémunéré. C'est à lui de s'assurer que l'association suit les buts qu'elle s'est fixée au départ. Si il n'arrive pas à maintenir le cap ou qu'il laisse des parasites trop se servir, il est sensé être remplacé par les membres l'année suivante.

À noter aussi que si ça merde franchement, l'autre risque est que l'association soit reclassée en association à but lucratif. C'est mauvais pour l'image de l'association, mais aussi pour sa fiscalité.

Bien entendu, ça suppose tout de même que l'association fonctionne de manière saine (genre plus que 5 membres-tous-copains notamment).

Pour le reste, je ne connais pas les règles exactes auxquelles sont soumises les associations américaines à but non-lucratifs. Je suppose qu'elles ont des règles similaires en place pour garantir leur intégrité.

J'ai précisé dans "l'économie numérique" !

Oui enfin après si tu tiens à faire dans les entreprises, on peut mentionner RedHat, qui finance directement Fedora et indirectement Gnome (sauf erreur de ma part). Ça leur permet d'améliorer leur distribution RedHat, mais je n'ai pourtant jamais eut l'impression d'être leur produit.

De plus, participer à une économie ne veut pas forcément dire faire des bénéfices. Ça peut aussi simplement être tirer les coups vers le bas et/ou casser un monopole en fournissant un logiciel gratuit/libre de qualité. Des logiciels libres développés par des associations à but non-lucratifs participent donc aussi à "l'économie numérique", juste de manière un peu plus indirecte. Sans compter que certaines arrivent à faire de l'argent en faisant du logiciel libre. Exemple bien connu, Firefox.

Le problème, c'est que les demandes de permissions sont trop vagues. Par exemple, combien d'applications demandent l'accès réseau juste pour afficher des pubs ?

"Si c'est gratuit, c'est vous le produit !"

Et juste après, tu donnes un parfait contre-exemple : F-Droid. Comme quoi le monde n'est pas juste en noir et blanc. J'invite d'ailleurs tout le monde à se méfier de cette phrase. Elle est trop simpliste. Après avoir dit ça, c'est tout de suite un peu plus compliqué de prêcher pour GNU/Linux :)

Quoiqu'il en soit, ici, le vrai problème, ce n'est pas gratuit VS payant. C'est que sur Google Play et l'Apple Store, il est grosso-modo impossible de distinguer les développeurs bien-intentionnés des mal-intentionnés. On est obligé de faire confiance à Google et Apple pour faire le tri. Visiblement, ils ne sont pas très au point (ils ne sont d'ailleurs pas très clean eux-mêmes sur ce point).

Les avantages avec F-Droid, c'est que:

• c'est une association. Ils ne sont donc pas motivés par un gain financier
• ils ont accès aux sources

Bref, c'est du logiciel libre comme on l'aime :)

v'ger a quitté le systeme solaire

De l'article même que tu as indiqué: "So, would the team say Voyager 1 has left the solar system? Not exactly - and that's part of the confusion. (…)".

Pour ceux que ça intéresse, les gars du laboratoire JPL de la NASA avaient fait un IAMA assez intéressant sur Reddit il n'y a pas longtemps: http://www.reddit.com/r/IAmA/comments/1m9wke/were_scientists_and_engineers_on_nasas_voyager/

Je viens de voir les autres journaux de l'auteur. Effectivement, c'était un peu trop subtil pour moi comme second degré.

Dans 24h, la terre va trembler de nouveau…

Wow. Il y a des fanboys qui ne doutent de rien quand il s'agit de leur marque favorite.
J'ai du mal à croire qu'un journal parlant de logiciels et d'équipements propriétaires, le tout avec un titre pareil, ait un score positif sur ce site.

Sérieusement, il y a encore des gens ici qui s'intéressent aux gadgets propriétaires d'Apple ? oO

balancez vos pulls requests ;-)

Wow. Pendant un instant j'ai cru lire "balancez vos comm's ;-)".

Faut bien justifier le nouveau numéro de version et l'augmentation du prix … :)

Comme quoi, les choses ne changent jamais vraiment (c'est un vieux texte que j'ai en stock qui doit dater de ~2000. Si quelqu'un a la source originale, je suis preneur)

J'oubliais un autre point : niveau ergonomie, les menus sont très peu pratiques. Ils augmentent le nombre de clics requis pour une action, et oblige l'utilisateur à faire preuve de précision à la souris ou à l'écran tactile. Ce n'est donc pas un bon endroit pour mettre les actions les plus courantes d'une application. Du coup, tu ne veux pas rendre les menus rapidement accessibles. Il y a des éléments bien plus importants dans une GUI à rendre accessibles bien avant eux.

La plupart du temps passé sur la machine se fait dans une application

Si tu n'en utilises qu'une, oui. Si tu en utilises plusieurs, non. Personnellement j'ai toujours un paquet d'applications lancées (sur ma tablette aussi bien que mon ordinateur). Ça implique de basculer souvent d'un bureau à autre et/ou d'une application à une autre. Du coup, dans Gnome, je fais très souvent des passages par le menu "Activité".
Ceci dit, ce n'est sûrement pas le cas le plus courant pour Mme Michu.

les menus des applications dans le bas

On parle desquels au juste ? Le lanceur d'applications Android en bas de l'écran ? Les barres d'actions Android ? ou les menus Android (deprecated : remplacé par un bouton en haut à droite de la GUI) ?
Parce-que coté Gnome 3 + app GNU/Linux, il n'y rien en bas de l'écran (enfin hormis la zone de notification dont le design change à chaque nouvelle version de Gnome 3.x). De plus, dans les applications Gnome, les menus classiques sont progressivement remplacés par des "AppMenu". Ces menus sont intégrés à la barre Gnome, du coup ils sont aussi en haut de l'écran.

(Ça va partir en troll mais tant pis …)

Je trouve dommage d'inclure Gnome 3 dans cette liste.
Gnome 3, d'un point vue clavier+souris, est très bien pensé.

Les icônes plus grands sont pertinents aussi bien à la souris que sur un écran tactile.

Ils utilisent aussi abondamment les coins et les bords de l'écran. C'est tout à fait pertinent dans le cadre d'un usage de la souris sur un poste mono-écran. Ce sont les zones les plus faciles à atteindre avec le curseur.
Ceci dit, ça n'a aucune utilité sur un écran tactile. L'utilisation fréquente du bord haut de l'écran sur un écran tactile me semble même être loin d'être optimal : à ma connaissance, lors du design d'une GUI sur écran tactile/mobile, on considère que les mains de l'utilisateur sont en bas de l'écran, pour le tenir. Résultat, accéder au menu "Activité" (action la plus courante dans Gnome 3) implique de déplacer complètement sa main au lieu de juste utiliser son pouce.

Au final, Gnome 3 me semble clairement être une interface plus axée PC que tablette.

le noyau est quasiment le même, et le portable Linux <=> Android est plus que facilité.

Ou pas. La plupart des applications Android sont écrites en Java en se basant sur le framework Android. Ce framework n'est pas disponible sous GNU/Linux.

Il y a un autre problème : même si le framework existait sur les 2 systèmes, une application mobile ne se porterait pas sur un desktop en claquant des doigts. Il y a des différences non-négligeables entre les deux. Essentiellement:

• différences de tailles et de résolutions entre les écrans (d'ailleurs, ils ont déjà le problème entre les téléphone et les tablettes)
• utilisation d'un écran tactile au lieu de clavier+souris

Ces différences impliquent des designs de GUI radicalement différents. Utiliser la même interface graphique sur ces 2 types de système est une très mauvaise idée. Il y a donc forcément un travail de portage à faire.

À mon avis, il y a un domaine où FreeBSD reste utile : l'embarqué proprio. La license BSD est beaucoup plus permissive que la GPLv2 et permet donc à ceux qui font du proprio de moins se prendre la tête. Le code de FreeBSD est très clean et se prête très bien au hacking (je n'ai pas eut encore l'occasion de jouer avec les sources de Linux donc je ne peux pas comparer). Ça me semble un choix tout à fait viable pour ça. C'est d'ailleurs ce que fait mon ancien employeur.

<troll> Par contre, effectivement, coté serveur ou desktop, c'est entre inutile et inutilisable … </troll>

Concernant les labels, je n'ai pas trouvé la possibilité de les créer autrement qu'une fois un document scanné ou importé… est-ce voulu ou c'est moi qui ai mal cherché ?

C'est une limitation technique. Les labels sont stockés dans un petit fichier texte 'labels' dans chaque document. Du coup il faut au moins un document ayant le label pour qu'il puisse exister.
C'est une limitation dont il faudra que je me débarrasse en centralisant les labels dans un seul fichier .. plus tard.

Concernant l'import de plusieurs fichiers d'un seul coup, j'aurai trouvé opportun de pouvoir choisir l'import individuel (chaque fichier représentant un document comme c'est le cas actuellement), ou bien un import groupé (tous les fichiers dans un seul document). Qu'en pensez-vous ?

Pourquoi faire 2 options quand une suffit ?

En fait certaines dépendances peuvent être installées automatiquement par le script setup.py, mais pas toutes, d'où le warning.

Ta distribution n'a pas été reconnue par le setup.py, du coup il n'a pas pu te fournir les noms des paquets exacts à installer. Les paquets Debian correspondant à ceux indiqué dans le warning sont les suivants : gir1.2-gladeui-2.0 gir1.2-poppler-0.18 tesseract-ocr tesseract-ocr-fra . Je ne connais pas les noms des paquets pour Elementary OS.

Lorsque je veux scanner en recto verso avec scanadf je lui donne le paramètre --source "Automatic Document Feeder(left aligned,Duplex)" J'ai l'impression qu'il te suffit de rajouter ",Duplex" et hop!

Je pense pouvoir régler ce problème facilement. Par contre la branche 'stable' est maintenant freezé. Ça sera donc pour la 0.2 (branche 'unstable').

Pourrais-tu créer un ticket sur le bug tracker, en anglais, en précisant la marque et le modèle te ton scanner, s'il-te-plaît ? Aussi, la sortie du script list_all.py de pyinsane pourrait aider :

$ git clone https://github.com/jflesch/pyinsane
$ cd pyinsane
# Allumage du scanner
$ ./list_all.py

La détection de l'orientation semble prendre beaucoup trop de temps. (…) Est-ce possible de désactiver cette détection dans les préférences de l'application?

C'est difficile de proposer cette option sans polluer la UI. Toutefois, une possibilité serait que je mette cette option de façon cachée dans le ~/.config/paperwork.conf.

En attendant, je peux te suggérer cette alternative:

• Désactiver l'OCR dans les préférences (c'est planqué en haut de la liste des langues)
• Faire tout tes scans
• Menu Documents -> Avancé -> Refaire l'OCR sur tout les documents

La détection automatique de l'orientation sera désactivée (dépendante de l'OCR). Tu risques donc de devoir l'ajuster manuellement après certains scans.

Est-ce que Paperwork supporte la fonction recto-verso?

Aucun de mes scanners ne supporte cette fonction, donc je vais répondre non. (si quelqu'un a un scanner recto-verso en rab', je suis preneur :D)

Ça serait aussi intéressant de ne pas avoir à lui indiquer le nombre de pages du document, Paperwork devrait scanner tout ce que je luis donne à manger sans poser de questions!

Tu n'es obligé de lui donner le nombre exact de page. Si tu ne veux pas t'embarrasser avec ça, dis lui de scanner 9999999 pages :)

Je pense que le support PDF existe, mais il doit me manquer une dépendance à installer. Une idée?

L'export en PDF utilise Cairo, qui est une dépendance de Gtk, donc tu as déjà les dépendances requises. Cette option n'est toutefois proposée que quand tu fais "exporter le document" et non "exporter la page".

Oui.

Pour info, les PDFs peuvent être importés en bloc dans Paperwork. Il suffit de :

• les mettre à plat dans un dossier
• dans Paperwork : Menu Document -> Importer un ou plusieurs fichier(s)
• sélectionner le dossier

il faut scripter.

Ok, bonne réponse :)
J'ai rajouté le ticket. Je tacherais de voir ce que je peux faire quand j'aurais le temps et la motivation.

Petite question toutefois, pourquoi l'importation de document est elle si longue ? J'imagine qu'il execute un OCR sur chaque document, peut on désactiver cette option ?

Ça dépend de quelle importation on parle:

• Pour les images, l'OCR est passée systématiquement
• Pour les PDF, l'OCR n'est passée que si il ne semble pas contenir de texte. Il est possible de forcer l'OCR en utilisation l'option Fichier->Avancé->Refaire l'OCR sur le document

Il est possible de désactiver l'OCR dans le dialogue de réglages (Fichiers->Préférences). L'option est cachée dans la liste des langues.

sudo pip uninstall paperwork
sudo pip uninstall pyocr
sudo pip uninstall pyinsane

C'est python-pip sur certains systèmes.

PyOCR et Pyinsane sont des librairies que j'ai écrites pour Paperwork, donc il est peu probable qu'elles soient utilisées par autre chose.

Par contre, je ne crois pas que pip sache supprimer les dépendances non-utilisées automatiquement.

De quelle manières les étiquettes (« labels ») sont-elles enregistrées ?

Un bête fichier texte dans chaque document/répertoire.

Ceci dit, ça peut causer potentiellement des problèmes de synchro dans le cas de coupures brutales de Paperwork lors de la modifications des labels. Donc, à terme, ça sera sûrement déplacé dans une bdd sqlite ou au moins un seul fichier central.

Quid de l'index et de l'OCR ?

L'index whoosh est stocké dans ~/.local/share/paperwork. À noter que les documents (~/papers/) sont la référence pour le contenu de l'index. Autrement dit, le contenu de l'index est toujours mis à jour à partir des documents.

Les fichiers contenant le résultat de l'OCR sont stockés dans les répertoires des documents (papers..words).

Une interface en ligne de commande est-elle prévue ? (pour lancer une recherche par exemple)

Je suis assez septique concernant l'utilité d'une telle fonctionnalité : il faut de toute façon consulter les pages avec un outil graphique au final (la sortie de l'OCR est de qualité variable).

J'ai déplacé ce genre d'infos dans le wiki GitHub du projet :
https://github.com/jflesch/paperwork/wiki#for-developers
https://github.com/jflesch/paperwork/wiki/Work-directory-organization