[grisbi-devel] Utilisation de Grisbi avec des tiers en grand nombre

[François Poulain]

Bonjour,

Je suis nouvellement inscrit. J'ai cru comprendre au survol des
archives que le français domine ici. Ça m'arrange. :) Rapidement, je
suis trésorier de l'April, et développeur très actif de GNU TeXmacs
jusque récemment.

À l'April, nous utilisons grisbi pour faire nos comptes, depuis
quelques lustres. Nous avons récemment migré Grisbi en version 1
(depuis une version 0.5.9 patchée par nos soins...) et tout s'est bien
passé. Et je dois dire qu'on est très content de Grisbi, même s'il ne
suffit pas vraiment à nos besoins.

Seul un petit soucis subsiste. Dans le formulaire d'édition des
transactions, la prédiction des tiers est très ralentie. (Nous avons
plus de 8000 tiers dans notre compta...).

J'ai regardé le soucis, et l'essentiel du problème est la lenteur de la
mise à jour du GtkTreeStore, dans le source src/gtk_combofix.c.
Apparemment c'est une maladie connue, il y a beaucoup de littérature
sur le web pour se plaindre de problèmes de performances de ces objets
lorsqu'il y a de nombreuses entrées. Je ne vois pas bien comment
résoudre ça en profondeur (j'ai fait plusieurs tests qui se sont soldés
par un échec : supprimer le tri, supprimer les notifications, utiliser
set_valuesv ...), mais je propose dans le patch joint de n'opérer les
modifications qu'en cas de stricte nécessité.

Le logiciel est beaucoup plus « répondant » après application du patch,
même si ce n'est pas encore la panacée.

Un problème subsiste en attendant : la prédiction est souvent trop à la
bourre par rapport à la frappe, et à cause d'un soucis de cohérence on
se retrouve souvent à l'usage avec une prédiction erronée du type
suivant :

Texte présent dans le gtk_entry (le pipe marque le curseur):
Franco|

Saisie "rapide" au clavier : "is"

Texte présent dans le gtk_entry:
Francois|s Poulain

=> Ce qui poutre la prédiction et rend l'entry pénible à l'usage.

J'ai fait quelques tests mais je n'ai pas réussi dans un temps
raisonnable à comprendre bien d'où ça vient. Par ailleurs je ne suis
pas expérimenté en GTK et il y a un peu de magie noire dans le code
de gtk_combofix_entry_changed (quel est le rôle de "force" ?).

Quelqu'un aurait une bonne intuition sur comment corriger la chose ?

Merci.
François

-- 
François Poulain <fpoulain at metrodore.fr>
-------------- section suivante --------------
Une pi�ce jointe autre que texte a �t� nettoy�e...
Nom: 0001-gtk_combofix_update_visible_rows-set-value-only-when.patch
Type: text/x-patch
Taille: 1785 octets
Desc: non disponible
URL: <http://listes.grisbi.org/pipermail/devel/attachments/20141204/1731d9c6/attachment.bin>