John, 

Thanks for the suggestions. 

Knowing how challenging it is to compile on Windows, I'm not sure I'll succeed 
in following that path, but I'll see what transpires. I do have access to a 
Fedora box; I think I'll try the same experiment there and see what happens. If 
it fails the same way, maybe I can compile there and get debug data. 

I did at one point succeed in compiling 5.13 on that box, so I believe I 
probably could again. If I get to that point, I'm sure I'll be asking for 
guidance on setting the necessary compile flag. 

I did look at the original gcm file and compared EOL characters in my modified 
version, but I didn't see any differences. Both had Windows CRLF EOL 
characters. 

I will note that when I examined the original gcm file, the register 
information was placed ahead of the metadata for opened tabs (tagged as Page 
n), and that for my modified gcm, I put all the register settings at the end of 
the file, to simplify the scripting. I figured that GnuCash would process the 
entire gcm at startup and the ordering wouldn't matter. I will try modifying 
the output to restore the original sequence and see whether that changes 
anything. 

Thanks, 
David T. 


On February 1, 2026 1:58:52 AM GMT+05:30, John Ralls <[email protected]> wrote:
>David,
>
>I don’t see any obvious reason that it would fail as long as you’re sure that 
>you spelled everything correctly. The function that sets the column widths is 
>gnucash_register_configure at 
>https://github.com/Gnucash/gnucash/blob/e0d9d336baee2292b6ddad7ecbc44957baaf4fc6/gnucash/register/register-gnome/gnucash-register.c#L455.
> GNC_PREF_SAVE_GEOMETRY is set with Preferences>Windows>Window>Save Window 
>Size and Shape. It also controls saving so you must have it enabled or you 
>wouldn’t have found those entries in the first place.
>
>The first thing I’d do would be to try it in the debugger, but it requires 
>full debug symbols and that means building GnuCash yourself with 
>CMAKE_BUILD_TYPE=Debug.
>
>A less onerous approach would be to turn on debug logging for gnc.register. 
>There isn’t a lot of logging in there so it might not help; unfortunately 
>there isn’t any at all in the state file loading code.
>
>Assuming that you’ve carefully compared the two gcm files to ensure that all 
>of the sections and keys are exactly the same, it occurs to me that there may 
>be a line ending difference that would be invisible but might trip up the Glib 
>keyfile loading code and result in the section or keys not being found.
>
>Regards,
>John Ralls
>
>> On Jan 31, 2026, at 00:41, David T. via gnucash-user 
>> <[email protected]> wrote:
>> 
>> Hello,
>> 
>> I am a longtime GnuCash user (19 years) with GC 5.14 (2025-12-10 build) on 
>> Windows 11.
>> 
>> I was reading a thread recently regarding register column widths, and I 
>> decided to try to work out a mechanism to set column widths for every 
>> account in my book, by account type. Specifically, I wanted to ensure that 
>> any account of type STOCK or MUTUAL had rational column widths for balance, 
>> debit, credit, price, and shares.
>> 
>> I started by opening an existing gcm file and noting the column width 
>> variables. Every register that has had its columns set has a section in the 
>> gcm file with values for all columns, identified by the account GUID:
>> 
>> [Register XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]
>> date_width=133
>> num_width=44
>> reconcile_width=33
>> balance_width=130
>> transfer_width=600
>> debit_width=125
>> credit_width=125
>> 
>> Accounts of type STOCK or MUTUAL have additional lines:
>> shares_width=100
>> price_width=133
>> 
>> I figure that I should be able to write out a gcm file with column settings 
>> for every account in the book, and this *should* make it so that any account 
>> I open gets my preferred column settings--regardless of whether I have 
>> actually set the columns on that register.
>> 
>> I created a simple python script that takes a csv list of all accounts in my 
>> book (derived from an SQL copy of my data file, and the SQL query "SELECT 
>> guid, account_type FROM accounts;") and writes my preferred column settings 
>> into a new gcm file.
>> 
>> For full disclosure, I started with a copy of the existing gcm file, 
>> stripped out all register-related data, and then pushed new register 
>> settings combined with this base gcm data into a new text file.
>> 
>> In theory now, if I put this new gcm file into the proper location (in my 
>> case, c:\users\sunfi\AppData\Roaming\Gnucash\books\myfile.gcm) and fire up 
>> GnuCash, I would expect every account to open with the new preferred column 
>> settings.
>> 
>> Unfortunately, that doesn't seem to happen. Once GnuCash opens, it seems to 
>> rewrite every single entry in the gcm file to some preset values based on 
>> some sort of unspecified criteria, undoing the changes I inserted. So, for 
>> example, if I set debit_width in every case to be 125 (as above), once I 
>> open GnuCash, the debit_width *in every single entry* gets reset to 88.
>> 
>> Do any devs have insight into what is going on here? Why doesn't GnuCash 
>> respect its own gcm file settings? Why rewrite this file in this way? Is it 
>> even possible for me to set column widths in the gcm file and have them 
>> persist?
>> 
>> I would really like to have my register settings a certain way, and going 
>> through a thousand registers one by one to reset the columns is not viable.
>> 
>> -- 
>> David T.
>> 
>> _______________________________________________
>> gnucash-user mailing list
>> [email protected]
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Reply via email to