[GNC-dev] Feedback on GnuCash 3.903

[David H]

Geert,

Thanks for your explanation but I still don't understand what the 6
different register types you refer to are - can you point me to where these
are described?

My reason for having different column widths is as previously posted ...

"... I have 2 savings accounts and 4 credit card accounts that I have open
all the time and over the years I've gone to the trouble of setting these
up just the way I like them.  Of course flicking through the register tabs
the columns aren't all in the same places as I'm using accounts with
different nesting levels in each so the Transfer column widths vary even
within each account type.  Are you saying that these would be treated as 2
register types and you are going to blow away all my good work and just
randomly choose one of the open settings as the default when you remove old
configurations?  "

Why do I like things just the way they are ?  Well it generally depends on
the level of nesting in my EXPENSES category - some of them are nested to 6
levels deep so the TRANSFER column is wider in a couple of these registers
and the DESCRIPTION column narrower than others.

It's like re-opening Gnucash and having the same tabs open I guess, if I
close a register tab and re-open it, it looks exactly the same as when I
left it :-)

I must confess that I did see this unfolding a little while ago on this
mailing list but it didn't sink in that you would be blowing all my
existing settings away altogether. I thought that this was only to set up a
default for a register that hadn't yet been opened/didn't already have
settings...  My understanding of DEFAULT is that it's only a starting point
and I assumed that my existing settings would remain unchanged even if they
were different within the same register type.

However I appreciate that you can't please everyone and that things have to
move on so I'm going to download this version, backup my existing settings,
install on one of my Windows pc's and see what it messes with and if it
really is going to upset my apple cart :-)

Happy to provide feedback as to whether I see it as an issue after I see it
in practice...

It might also be beneficial to explain what's happening on the wider user
list before it goes live, I don't think I've seen any mention of this
change there.  I know you said you are responding to complaints re setting
register column widths but you know what they say "the noisy wheel gets the
most oil" and it appears the silent majority are content with things as is.

Getting rid of that hidden automatic expansion on the description column
will probably also alleviate some of the complaints.

Thanks David H.



On Sat, 6 Jun 2020 at 06:46, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>