[GNC-dev] Feedback on GnuCash 3.903

Robert Fewell 14ubobit at gmail.com
Sat Jun 6 04:34:31 EDT 2020


David,
There are 6 different layouts that all registers are based on as described
below...

REG_TYPE_GROUP_CURRENCY;
BANK_REGISTER:
CASH_REGISTER:
ASSET_REGISTER:
CREDIT_REGISTER:
LIABILITY_REGISTER:
INCOME_REGISTER:
EXPENSE_REGISTER:
EQUITY_REGISTER:
TRADING_REGISTER:

REG_TYPE_GROUP_APAR;
PAYABLE_REGISTER:
RECEIVABLE_REGISTER:

REG_TYPE_GROUP_JOURNAL;
INCOME_LEDGER:
GENERAL_JOURNAL:
SEARCH_LEDGER:

REG_TYPE_GROUP_STOCK;
STOCK_REGISTER:
CURRENCY_REGISTER:

REG_TYPE_GROUP_PORTFOLIO;
PORTFOLIO_LEDGER:

Opening sub accounts uses the Portfolio layout.

On Sat, 6 Jun 2020 at 00:31, David H <hellvee at gmail.com> wrote:

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


More information about the gnucash-devel mailing list