Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Maintien de SearchMonkey

kevlar

Bonjour.
1er point
Peut-être ai-je mal compris ; ta "trappe" se produit-elle avec la version 0.8.2 ou 0.8.3 ?
Je voudrais avoir une copie d'écran juste avant la trappe, car souvent, çà permet d'entrer dans la "peau" de l'utilisateur avec un regard extérieur. Maintenant que tu m'as rassuré sur le contenant, je suis de plus en plus sûr que c'est le fameux problème des caractères accentués (en fait c'est lié à l'Utf8) ; normalement, j'ai corrigé cela sous la 0.8.3, mais on n'est jamais au bout de surprises. J'attends donc avec impatience et gourmandise ton fichier, soit via googledrive en accès public, soit via MP.

2e point
Pour installer une version plus récente, au début de ta session git, dan ton terminal, tu tapes (à faire systématiquement) :

git pull

Tu récupéreras ainsi le dernier état produit par le développeur Gtk ;-)

DRbuntu91

Puis j'ai je choisi un encodage en "Unicode (UTF-16)" la recherche ne trouve pas le contenu
En conclusion seul un encodage avec la locale UTF-8 marche.

kevlar

DRbuntu91 a écritEn fait le fichier texte était encodé en "Occidental (ISO-8859-15)". Je l'ai sauvegarde avec l'option UTF-8 et ça marche

Très intéressant ! Hier, en repensant à nos échanges, j'avais envie de demander aux forumeurs de très anciens fichiers des années 1990 pour voir comment çà se passait, et tu viens de me confirmer que c'est une bonne question, car il s'agit d'un codage de Windows qui date de cette époque !
Un grand merci !

kevlar

DRbuntu91 a écritPuis j'ai je choisi un encodage en "Unicode (UTF-16)" la recherche ne trouve pas le contenu
En conclusion seul un encodage avec la locale UTF-8 marche.

Que dire de plus sinon un autre merci, tu fais un travail essentiel !
Je vais donc faire ce qu'il faut : mais nous parlons bien de fichiers "texte" pur, du style toto.txt ?

DRbuntu91

Oui - je les ouvre avec GEDIT (l’éditeur par défaut de Ubuntu-Unity). S'était un fichier que j'ai reçu de quelqu'un (s'est un fichier que je transfère dans mon TomTom - ceci explique peut-être cela)

Puis un autre petit souci: quand je fait une recherche avec le champ "Contenu", la taille des fichiers trouvés n'est pas leur taille réelle. Au début ça m'a induit en erreur en voulant faire des test combinés de contenu ET taille. C'est normal?

DRbuntu91

Puis dans ton tuto j'arrive a la section "Suppléments". Dans mon "test bed" j'ai mis plusieurs type de fichiers (Audio, Images, Bash, C, MarkDown, Excel&Calc, Word&Writer, PPT&Impress, PDF, Text, Vidéos, XML et ZIP)
Pour chaque type de fichier j'ai une application par défaut qui s'ouvre quand j'utilise Nautilus. Mais dans searchmonkey il n'y a que 3 options et si je suis ton tuto je dois définir xdg-open comme application. Ça marche comment?

EDIT: Quand je sélectionne un fichier dans la liste et je fais click-droit puis "Editer ce fichier" j'ai cette erreur

xdg-open: unexpected argument 'fichiers'
Try 'xdg-open --help' for more information.

kevlar

DRbuntu91 a écritOui - je les ouvre avec GEDIT (l’éditeur par défaut de Ubuntu-Unity). S'était un fichier que j'ai reçu de quelqu'un (s'est un fichier que je transfère dans mon TomTom - ceci explique peut-être cela)

Puis un autre petit souci: quand je fait une recherche avec le champ "Contenu", la taille des fichiers trouvés n'est pas leur taille réelle. Au début ça m'a induit en erreur en voulant faire des test combinés de contenu ET taille. C'est normal?

Bonsoir.
Cela dépend si l'on compte 1 k = 1024 octets ou 1k = 1000 octets, cette dernière acception s'étant malheureusement répandue

kevlar

DRbuntu91 a écritPuis dans ton tuto j'arrive a la section "Suppléments". Dans mon "test bed" j'ai mis plusieurs type de fichiers (Audio, Images, Bash, C, MarkDown, Excel&Calc, Word&Writer, PPT&Impress, PDF, Text, Vidéos, XML et ZIP)
Pour chaque type de fichier j'ai une application par défaut qui s'ouvre quand j'utilise Nautilus. Mais dans searchmonkey il n'y a que 3 options et si je suis ton tuto je dois définir xdg-open comme application. Ça marche comment?

EDIT: Quand je sélectionne un fichier dans la liste et je fais click-droit puis "Editer ce fichier" j'ai cette erreur
xdg-open: unexpected argument 'fichiers'
Try 'xdg-open --help' for more information.

çà c'est facile.
L'association de fichiers se fait, dans ton cas, avec Nautilus, Searchmonkey ne fait rien lui-même.
Sous Nautilus : choisir un fichier d'un type donné, faire clic droit, et là il doit y avoir un choix du type "ouvrir avec" ; il faut en faire le choix par défaut. Dès lors, xdg-open respectera ce choix et par conséquent Searchmonkey appellera, en faisant confiance à xdg-open, l'éditeur par défaut que tu auras associé via Nautilus.
La phrase est lourde, mais c'est très simple.
L'appel xdg correct c'est çà :
/usr/bin/xdg-open avec comme paramètre %f

kevlar

Les problèmes des fichiers ISO et UTF16
C'est une véritable jungle, je viens d'y passer l'après-midi. Rien que pour l'UTF16, 2 formats différents, et une dizaine de déclinaisons de l'ISO. Gasp !
J'ai donc résolu le problème ainsi :
1- priorité, empêcher les plantages.
2- comment ? En faisant un choix drastique : Searchmonkey ne traitera pour le moment QUE l'UTF8 ET l'ISO ISO-8859-1, ce dernier correspondant aux langues les plus répandues utilisant l'alphabet latin. Bien évidemment, il faudra améiiorer tout cela, mais, vraiment, c'est un sacré problème que ces encodages, allez faire un tour sur le net, vous aller rire.
3- j'ai donc mis un patch sur GitHub.
4- Et j'espère que çà va ; chez moi, les mélanges de fichiers UTF8 et ISO-8859-1 passent sans problème. Je suis preneur de retours.

kevlar

C'est fait, la détection des fichiers codés en UTF 16 et UTF32 est implémentée.
J'ai testé le codage UTF16, çà marche.
Quant à de l'UTF32, qui utilise çà ? En tout cas le programme est supposé pouvoir le gérer.
A+

DRbuntu91

Je viens de faire un test avec la dernière version (j'ai fait un "git pull") puis le pb. de ISO ISO-8859-1 est résolu. Bravo!

Je n'arrive pas a faire marcher l'ouverture des fichiers malgré avoir définie "/usr/bin/xdg-open avec comme paramètre %f". Il doit y avoir une différence de mon environnement système par ce que dans config.ini j'ai bien ceci:

configTextEditor=/usr/bin/xdg-open
configTextEditorAttributes=%f
configFileExplorer=/usr/bin/nautilus
configFileExplorerAttributes=%d
configWebBrowser=/usr/bin/firefox
configWebBrowserAttributes=%f

Il y a une conf a faire pour xdg-open?
EDIT: dans un terminal la commande xdg-open monfichier.pdf l'ouvre bien!

Pour le pb. de taille de fichiers je le reproduit ainsi
- je sélectionne pdf dans fichiers. la taille de mon fichier est 2,6 Mo (la même dans Nautilus)
- Je rajoute un critère de contenu et maintenant la taille du fichier n'est plus que de 6,8 Ko!!!
Je dois re-tester avec d'autre fichiers type LO et texte par ce que j'ai l'impression que parfois ça marche.

PS: J'ai également fait qq. tests avec des fichiers avec du texte en portugais (il y a qq. caractères différents par rapport au français comme le tilda) et ça marche.

DRbuntu91

Je pense avoir trouvé.
La fonction xdg-open ne marche pas dès qu'il y a un blanc dans le nom du fichier OU dans ne nom du répertoire ou se trouve le fichier.

kevlar

Merci encore pour tous tes retours.
Je vais essayer de comprendre l'histoire de la taille des fichiers. Peux-tu avoir la gentillesse de me décrire étape par étape ce que tu fais avec ton PDF ? Par exemple, l'info fausse sur la taille du fichier (passant de 2,6 Mo à 6,8 Ko )est-elle affichée dans la liste des fichiers OU dans la prévisualisation ?)
Je te remercie par avance de ton retour, ton travail est vraiment précieux
Bien cordialement !

Pour les langues, je me suis amusé hier à tester d'autres alphabets, exemple en chinois (fichier UTF16)

J'ai vu également que Gtk s'adaptait tout seul à l'arabe : çà fait étrange de voir un mot, que je ne comprends pas, s'aligner tout seul à droite ;-)

kevlar

DRbuntu91 a écritJe pense avoir trouvé.
La fonction xdg-open ne marche pas dès qu'il y a un blanc dans le nom du fichier OU dans ne nom du répertoire ou se trouve le fichier.

Merci.
En termes système, ce n'est pas un bug : par exemple, tu as du remarquer qu'en console, on ne tape pas directement un espace mais ces deux caractères :
\ (barre suivie de espace, par exemple mon\ fichier\ a\des\ espaces
Mais ta remarque va être prise en compte, c'est une amélioration très simple à faire dans le code de SearchMonkey.
Merci à toi !

nam1962

Roschan a écritUn peu dommage que ce soit GTK 2 mais très intéressant projet, je testerai ça

[HS]
En GTK 3, voilà un projet qui mériterait maintien : https://github.com/wolfv/uberwriter
😉
[/HS]

DRbuntu91

@keviar
Voici le résultat d'une recherche sur le nom de fichiers mais sans "contenant":

Puis quand je fais une nouvelle recherche en rajoutant un critère de contenant, voici le résultat

Comme tu vois la taille du fichier a changé (la bonne taille était lors de la recherche sans contenant)

kevlar

DRbuntu91 a écritJe pense avoir trouvé.
La fonction xdg-open ne marche pas dès qu'il y a un blanc dans le nom du fichier OU dans ne nom du répertoire ou se trouve le fichier.

C'est corrigé, je viens de "pusher" le correctif sur GitHub.
Si tu veux bien vérifier que :
1- les fichiers dont les noms comprennent de espaces sont ouverts correctement. çà marche chez moi, mais je préfère être sûr.
2- qu'il n'y a pas de méchants plantages du style segfault() car je fais des réallocations de chaînes.

Merci d'avance.

kevlar

DRbuntu91 a écrit@keviar
Voici le résultat d'une recherche sur le nom de fichiers mais sans "contenant":
http://pix.toile-libre.org/upload/thumb/1518267436.png

Puis quand je fais une nouvelle recherche en rajoutant un critère de contenant, voici le résultat
http://pix.toile-libre.org/upload/thumb/1518267554.png

Comme tu vois la taille du fichier a changé (la bonne taille était lors de la recherche sans contenant)

Merci, je pense que j'ai compris, je t'explique (mais je vais faire une pause un petit moment, donc le correctif ne sera pas tout de suite) ;
1- pour faire une recherche en profondeur dans un PDF, je travaille sur un fichier texte caché, extrait du PDF
2- j'en déduis que ton gros PDF est plein d'images (que Searchmonkey ne voit pas) et contient juste un peu plus de 6000 caractères)

Conclusion : au boulot m'sieur Kevlar, tu confonds taille du "vrai" fichier et taille du texte dans le fichier ;-)
A+ je corrigerai çà d'ici à demain.

Je répète toujours la même chose, mais encore une fois merci pour tes tests !

En passant, ce soir, nous faisons une conférence de développeurs sur Skype, et Adam, le "patron" qui a créé le projet en 2007, a souhaité que nous ayons un stock de fichiers martyrs pour nos tests. Si certains de tes fichiers proviennent d'internet, je serais heureux d'avoir un lien pour les télécharger afin de les mettre dans cette liste à "torturer".
A+

DRbuntu91

Super - je comprend maintenant pourquoi ça marche parfois!

Je me suis fait un jeu de fichiers de test, mais se sont essentiellement des fichiers perso donc difficile a partager (je me suis fait aussi un cahier de tests me permettant de re-tester facilement et rapidement). Je retesterai dimanche quand les correction auront été faites.

PS: s'il y a intérêt (et pas trop de travail) je pourrai plus tard traduire l'interface en néerlandais voir éventuellement en portugais (j'ai PoiEdit sur mon ordi)

kevlar

Bonsoir !
J'ai pushé la version corrigée, normalement la taille des fichiers est maintenant cohérente, quel que soit le mode, merci de me dire si çà marche ;-)

DRbuntu91 a écrit Je me suis fait un jeu de fichiers de test, mais se sont essentiellement des fichiers perso donc difficile a partager (je me suis fait aussi un cahier de tests me permettant de re-tester facilement et rapidement). Je retesterai dimanche quand les correction auront été faites.

PS: s'il y a intérêt (et pas trop de travail) je pourrai plus tard traduire l'interface en néerlandais voir éventuellement en portugais (j'ai PoiEdit sur mon ordi)

Je comprends tout à fait pour les fichiers perso !
Et je saisis au vol ta proposition pour les langues : en effet, nous n'avons actuellement que 3 langues : anglais, français, russe.
Je suis à ta disposition pour les fichiers .po ; mais comme tu maîtrises, tu peux si tu les souhaites partir directement du fichier searchmonkey.pot disponible sur le dépôt GitHub.

Bien cordialement !

« Page précédente Page suivante »