[GNC-dev] Ideas for account type-ahead modification

Adrien Monteleone adrien.monteleone at lusfiber.net
Tue Mar 10 12:23:31 EDT 2020


Can account number entry be part of the solution? (or is that a separate ball of wax?) I know I’ve seen that asked for as well. (and would use it myself if it existed) The current work around is to include the account number in the account name (though it has its own field) and even then it requires too many key presses to use properly.

Regards,
Adrien

> On Mar 10, 2020 w11d70, at 10:20 AM, Jean Laroche <ripngo at gmail.com> wrote:
> 
> Thanks for pointing me to this bug report! I don't know how I missed it. I looks like a patch was created a long time ago, commented upon, but then nothing was done about it, which is really too bad.
> 
>> It might be useful for small private acoount herarchies.
>> But on major business templats with over 1000 accounts it would be
>> annoying in several aspects:
>> 1. slow down on building the  list,
>> 2. exposing irrelevant parts, example:
>> Assets:Tax paid:{x %|y %|z %}
>> Liabilities:Tax collected:{x %|y %|z %}
>> Expense:Purchases at:{x %|y %|z %}
>> Income:Sells at:{x %|y %|z %}
>> which currently is straight forward.
> 
> About the slow down, I'm not too sure. Searching through 1000 or 2000 strings is pretty much instantaneous on current machines, but building the drop down list may be far slower.
> 
>> I would divide the business users in 2 groups:
>> learned accountants would enter the account code and are not affected,
>> but oters with some economic knowledge would prefer to enter e.g.
>> "I:S:x<Tab>". Will that still be possible?
> 
> I concur. A change like that could not be enforced to users who don't want/need it. There should be a preference that selects the type of completion the user wants, for sure.
> I'll take a look at the attached patch and see if it can be improved...
> But the fact that there was the beginning of a solution, and that this was abandoned is a bit discouraging: the reviewers asked for improvements, but in the end instead of a better solution, we got no solution at all. That's definitely not ideal.
> Jean



More information about the gnucash-devel mailing list