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

Geert Janssens geert.gnucash at kobaltwit.be
Thu Mar 26 05:22:06 EDT 2020

Op vrijdag 13 maart 2020 01:30:23 CET schreef Jean Laroche:
> Well it's finally working. I cleaned everything and rebuilt everything,
> and things are OK now. I should have started with that. :(
> Thanks for the help though!
Glad you got it working.

I'm the one to usually bring this up, so I'll do so again:
Before adding options always think very hard for ways to avoid that.

I understand you don't want to replace the old behavior with your new behavior unconditionally. 
I agree.

However I also think they are not necessarily mutually exclusive. If you start from the existing 
situation and adapt it slightly, I think both use cases can be served in one single search method.

Current search behavior will always start searching from the first character of the top level 
account. Change this to fully search each (sub-)account's name instead and I think we have 
both behaviors combined. Typing the account separator can still auto-complete the current 
selection up until the end of the matched account part and subsequent typing continues 
searching in child account names of the account selected so far.

An example may help:

Imagine we have the following account tree:


Typing 'et' will filter the list of accounts to show to

Subsequently typing ":" will autocomplete 'et' to 'ets:' and reduce the list to

(Expenses:Bets itself is a final match while we ask for subaccounts with the ":" so it's now 

>From here we can consider two possible behaviors for further matching:
- old style from-left-to-right
- new style full text match on subaccount

For old style the user now has to continue typing "Ba" or "Bl" to further filter on either Bank or 
Continuing to type "Ba" will further reduce the list to 
Whereas typing "Bl" would reduce it to

I would though instead try to implement full text match on subaccount allowing the user to do 
as in the old style but also
Type "u" to reduce the list to 
("Bank" has no 'u' in it)

I think the internal logic for this is not that much more complicated than our current search 
implementation. The challenge though is likely how to represent this in the text field the user is 
typing in. That is how to visually represent which bits of text were actually typed by the user 
and which bits are autofilled.



More information about the gnucash-devel mailing list