[grisbi-devel] Utilisation de Grisbi avec des tiers en grand nombre
Duflot Jean-Luc
jld78 at sfr.fr
Thu Dec 4 17:10:50 CET 2014
Bonjour,
Très heureux que vous utilisiez Grisbi. Effectivement, c'est un logiciel
développé par des français, d'où le forum en français, mais il y a
d'autres langues aussi.
Je ne suis pas développeur, mais je suis en charge du manuel. Juste pour
vous informer, ou vous rappeler, que le manuel de la version 1.0 est ici :
http://sourceforge.net/projects/grisbi/files/Documentation/manual_1.0/
Cela ne vous aidera pas pour votre souci sur les tiers, mais Grisbi est
suffisamment élaboré pour en avoir besoin de temps en temps ; par
exemple, la fonction de tiers virtuel qui permet de saisir de nombreuses
cotisations identiques en une seule opération : voir tiers virtuel das
l'index.
Pour la prédiction des tiers, je pense qu'un développpeur va vous
répondre rapidement.
Jean-Luc Duflot
Le 04/12/2014 12:17, François Poulain a écrit :
> 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
>
>
More information about the devel
mailing list