[GNC-dev] Feedback on GnuCash 3.903

[Geert Janssens]

Op vrijdag 5 juni 2020 20:45:07 CEST schreef D via gnucash-devel:
> Michael,
> 
> The idea of default column widths makes sense, but the idea that a user's
> previously set preferences will no longer apply seems a little backward.
> 
Note default columns widths are not set automatically. GnuCash can't know if you just tweaked 
a column temporarily for whatever reason or you want this to be the default for a given register 
type. So to set defaults the user has to select the appropriate command in the Windows menu.

As there are no account level presets any more, how can GnuCash know which preferences to 
apply if you have different preferences for different accounts in the same register type group ? 
At best we can read them once and convert them to preferences for an open tab (which is not 
the same as preferences for a given account). Once you close the tab the tab preferences are 
gone with it.

As for motivations to drop account level presets, read on.

> I am curious to know more about the thought process that arrived at this
> solution. I'd have thought that storing per account column settings
> wouldn't cause too much storage problem, and I would imagine the register
> opening process could look, in order, for an account-specific column record
> by guid, and, upon failure, the default for that account type in question.
> I wouldn't imagine that such a process would be onerous even for the
> largest of gnucash books. But, I am no programmer.
> 
> David
> 

Here are a few situations that we have been evaluating when working with a three level column 
width settings schema (auto calculated/per register type/per account:

1. User opens account A, tweaks the date column say because gnucash poorly calculates it. This 
will be saved for that particular account. Rince and repeat for account B, account C,... In the end 
the user has a number of accounts which all have a custom width for date that is always slightly 
different because it was set manually each time.
=> This is a very good use case for a register type level default. Actually even for a user-set 
system level default, but that would add even an additional level. Three gets complicated 
enough so lets stick to register-level default.
2. So user learns one can also set a register level default. User opens one of the plenty of 
tweaked accounts and sets it as default. This will now work happily for all accounts that didn't 
have any default set. But the ones that were tweaked won't change, because for those accounts 
the account level user selection takes precedence.
3. Imagine the user was not too careful and had widened some date fields way too much while 
still manually setting those. So for these the user would now want a way to also set the default. 
But which default ? In this particular use case probably the one set for the register type. 
However in another use case the user would rather reset to auto calculated default (for example 
because the bug that wrongly calculated the default is now fixed). So that already needs two 
methods to reset to default and the user has to make a decision which one is correct for his/her 
particular use case. Which means the user has to learn the difference and understand how the 
levels interact. That distracts from the actual job at hand - accounting. (And yes, I do 
understand that messing up your carefully set column widths during an upgrade also distracts 
from that. The hope here is that it only happens once though to fix a wider set of problems).

It gets worse. The example above was to deal with a poorly calculated default width. Imagine 
that after step 1. and before step 2 the user had also tweaked another column (say the balance 
column) in a few accounts and not in others where you also changed the date column.

And *then* the user remembers one can set register level defaults. So the user opens say 
account A in which the date column was changed and the balance column wasn't and marks 
that layout as default with the intention to correct that stupid date column once and for all.
Now the net result is pretty confusing:
- All unchanged registers will use the new default
- All registers in which the user manually fixed the date column will not change, but it's not 
obvious because the new date column width still resembles the width that was set as default.
- All registers with unchanged date column but changed balance column will still have an 
unchanged date column and a changed balance column. (Huh, why did setting default not work 
!?)

Next the user also remembers the new balance width is more useful and would like to set it as 
default. So the user opens a register for which s/he remembers the balance column was set as 
desired. However the date column is not. So the user again has to make a decision here: if s/he 
chooses to set this register layout as default, the change to the date column is lost:
- Opening unchanged account registers now have a proper balance column but the date column 
has been reset to the old undesired default
- Registers for which the date column was already tweaked (and the user after the previous step 
might mistakenly believe were using the new default because it's close to what the default is) 
do not update to the new balance column.
The user could also decide to first change the date column as well and then set the default. 
Results are similar and very confusing.

Now let time pass by and let the user tweak a column here or there in some accounts. 
Eventually the register-type level defaults become more or less meaningless because each 
manual change to a single account will cause the register-type level default to be ignored for 
that account. The larger the book, the bigger this problem gets.

And that will eventually bring us back to the original user complaint that triggered us to rework 
the column width logic: after some time the only way to change columns is to do it for each 
account individually (because that mode is greedy). And from the complaints it looks like that's 
exactly what most users don't want.

That's just a few of the scenarios I remember.

Many of these issues can no doubt be solved by throwing more code at it though I honestly 
doubt if such a complex starting point can really lead to a good user experience. Given the 
complexity this would bring plenty of confusion and distraction for most users.
And then the available developer time enters the mix. As we know that is limited and in this 
case I believe the added complexity doesn't bring enough benefit to be worth the extra effort.

Having said all that, I acknowledge it disrupts your workflow. There are two parts to this I can 
see:
1. the column layouts you have set seem not to be taken into account. I can't tell exactly what 
happens from the information you have given so far. Perhaps we can recover more of your 
existing column settings with a smarter migration path, perhaps not.
2. you seem to value dedicated column layouts per account. What is your specific use case to 
want different column widths for *every* register you open ?

Regards,

Geert