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

[Rémi Cardona]

Le 04/12/2014 12:17, François Poulain a écrit :
> 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.

Bienvenue!

> À 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.

Ça fait toujours plaisir de "rencontrer" ses utilisateurs :)

> 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...).

Ça commence à faire! De manière générale, Grisbi a du mal avec les
listes longues : tiers et opérations (essaye d'afficher les transactions
rapprochées…)

Surtout avec Gtk2 (plus précisément avec son module d'accessibilité qui
pénalise énormément les perfs). Vu que tu dis être sur Grisbi 1.0, je
suppose donc que tu es sous Linux. Tu peux donc essayer de lancer grisbi
avec la variable d'environnement NO_GAIL=1 qui désactive ledit module.

Si tu es plus téméraire, tu peux tenter de compiler Grisbi depuis la
branche master de git qui a été convertie à Gtk3 et qui est bien plus
rapide (surtout les Tree{View,Store}) même avec l'accessibilité
d'activé. Pour la liste des transactions, le gain de perf est considérable.

> 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.

Merci pour le patch, je vais y jeter un coup d'œil.

> 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 :

Je trouve également l'auto-complétion un peu pénible, plus pour des
histoires d'IHM que de perfs. Elle nécessite beaucoup d'amour!

> 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 ?

gtk_combofix est un grand mystère que j'aimerais remplacer un jour par
un GtkEntryCompletion. Ça ne résoudrait sans doute pas les problèmes de
perfs, mais ça ne peut qu'aider.

En attendant, je n'ai pas de pistes à te suggérer. N'hésite pas à passer
sur #grisbi sur FreeNode si tu n'as pas peur d'IRC, j'y suis connecté en
permanence.

En espérant de nouveaux patches de ta part ;)

Rémi