Hi Rob, FYI - I've just installed 3.904 in case it makes a difference...
1) Well that's the issue I guess - accounts grow to fill the available space :-) Gnucash has given me plenty of space/nesting ability over the years so some of my account names are quite long eg "Assets:Fixed Assets:Superannuation:Super - David:Super:Super Income Account" and "Expenses:Mobile Phone:David:xxxxxxx:9999 999 999:Month to Month Plan". So when I revert to defaults (in transaction journal view) because there's nothing in the split description and the transaction description is only about 25 characters it looks a bit ridiculous to have the description column so large and the account name truncated so severely. I'm not sure that "Expenses:Automobile:Gasoline" is a sufficiently good example to be using to base the default column width on - even my auto expenses are broken down by vehicle so end up looking more like "Expenses:Auto:Nissan XTrail:Repairs and Maintenance". 2) Perhaps it would be better to base it on the "Tot Funds Out" header length which is 2 characters longer instead as that's what is being truncated. Yes I worked out that depending on which line was highlighted the column headers/double clicking changed. Second point seems to have resolved itself - not sure if it was connected to the Tools-->General default setting (point 3) that I used moments ago but the "Created Transactions" tab now appears to be using the column widths I expected. 3) Ah my bad - to my knowledge I have never used any Journals in Gnucash in my life so didn't realise this would affect the scheduled txn layout - all good now. Also thanks to you and the other devs for all your hard work on gnucash, it is much appreciated. As a former C# developer I know just how hard it can be to keep everyone happy :-) Cheers David H. On Sun, 7 Jun 2020 at 23:06, Robert Fewell <14ubo...@gmail.com> wrote: > 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 <hell...@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 <14ubo...@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 <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
