[GNC-dev] Feedback on GnuCash 3.903

[Robert Fewell]

David,
Thanks for trying and the feedback, will try and answer your points...
1) The program default widths have not changed and are based on example
strings in code. So for the account / transfer column it is based on
"Expenses:Automobile:Gasoline" plus some space for the button. I added
those accounts to my test book and it fitted exactly.
2) Same thing here but it is based on a number, "999,999.000". I did fix
the double clicking on the header but you need the highlighted line to be
on the transaction as opposed to the splits. Not sure I understand the
second point.
3) Do not know why that is, you should be able to adjust the column widths
and they will be remembered as before, this aspect has not been touched.
The scheduled transactions template
 is based on the REG_TYPE_GROUP_JOURNAL group so go to 'Tools->General
Journal' and setup the desired widths from there. Will see if I can add the
menu options to the template window.


On Sun, 7 Jun 2020 at 00:29, David H <hellvee at gmail.com> wrote:

> Hi Robert/Geert,
>
> Thanks for that.  I only use Gnucash for my personal expenses so it looks
> like I'm only using the first register group.  I've installed 3.903 and am
> happy that my use case apart from scheduled transactions is generally
> unaffected so will leave installed and continue using and if anything pops
> out of the woodwork I'll post something here if that's the way to go.
>
> For your info my setup is Win 10 Pro and I'm running gnucash on a 27"
> monitor at 1920 x 1080 res and I always run it full screen.  Dual monitor
> with laptop screen as secondary display.
>
> A few minor things I did notice are as follows :-
>
> 1. Reverting to default on a register seems to shrink the Transfer column
> down a lot further than I expected and really truncates the column.
> 2. When I review scheduled Created Transactions and revert to default it
> also cuts off the left side of the "Tot Funds In" and "Tot Funds Out"
> columns (see pic attached).  Also if I close without saving after reverting
> to default when Gnucash restarts and recreates the txn's it doesn't pick up
> the new default it seems to remain on the reverted view with the truncated
> columns.  This is also after I go to another account register with good
> columns and click on use as default for this group so it's like it's become
> orphaned from the defaults.
> 3. My list of scheduled txns seems to have shrunk the Name column.  Also
> in all of the template transactions the account column has shrunk right
> down and the Windows menu when you're in the template editor doesn't
> include the new register default entries which leads me to thinks this is
> possibly an unintended consequence and since I've got a lot of these I'm
> probably have to go and re-adjust each one :-(
> 4. If I go in and change the widths of some columns and then scroll up a
> couple of pages of txns and decide "meh this isn't looking so good" I just
> close the register and re-open it to get the defaults back so that's good.
>
> Thanks David.
>
>
>
>
> On Sat, 6 Jun 2020 at 18:34, Robert Fewell <14ubobit at gmail.com> wrote:
>
>> 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
>>>
>>