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