[GNC-dev] GnuCash 3 on Linux

Wm wm_o_o_o at yahoo.co.uk
Wed Feb 27 15:57:42 EST 2019

On 25/02/2019 06:52, David Cousens wrote:

> I admit freely I do not have a clear understanding of how the reports (and
> much else inside GnuCash) do work in detail and I doubt if I am alone in
> that apart from maybe the core development team.

You are expected to be the foil for those that do know, sir :)

> GnuCash for whatever historical reasons is only sparsely documented which
> increases the difficulty of those of us with some development experience,
> but not long term on GnuCash, to contribute effectively. There is a big
> learning curve anytime you dig into the code.

That is an understatement, the code is largely opaque comparative to the 
relatively simple transactions that occur.

> Having worked in development
> teams which had very limited resources in the past

[snip] I hear you, I am not that boss here

> GnuCash doesn't have the luxury of a systems analysis team and management
> structure with oversight either. There is just a minimal team of unpaid
> developers, often wearing multiple hats, doing their best. Despite that it
> is far more flexible and adaptable than many programs which do have
> extensive development teams - hence the escapees from MYOB and Quicken where
> cost becomes a very significant factor.

Hint: I am part of a systems analysis team and manage software.  I just 
don't get used much.

Since I know that I often find myself taking another view.

>> Does gnc know where it took stuff from and placed it when 3.x was run
>> for the first time?
> Looking at the code which did this, should answer this question. Not easily
> though, as the code generates scripts which perform the gconf->gsettings
> ,dconf migration (forced by the deprecation of g conf) as well as the
> changes in the settings location.

some stuff got lost there, continue

> My brief excursion into it indicates that
> it is as described on the wiki Configuration Locations page. What was
> migrated is defined in /usr/local/share/gnucash/migratable-prefs.xml and
> processed by /usr/local/share/gnucash/make-prefs-migration-script.xsl to
> produce the gsettings from the original gconf settings.

Wow!  I admire your faith!

problem is:

the variables are just that, variable

I don't think anyone knows where some of the details went

> My experience with the transition from 2.6.19 in my case to v3.0 was that I
> lost all of the training for the import matcher - no great problem, a couple
> of imports and it was largely back and that solved some historical import
> problems  which were throwing up accounts which were no longer appropriate.
> There is some value in occasionally retraining the import matcher in any
> case.

Your report is occasional not substantive. You will hopefully get a 
better report.  The importer farts when I throw new stuff at it.  Expected.

> I get by with the basic reports when i need them so i personally had
> no problems with reports, but I do appreciate that others may/did/do. I kept
> the 2.6 .gnucash preferences folder from 2.6.19 for some time after i
> migrated to 3.0in case I went back but unfortunately I decided around 3.3.
> that for my purposes things had become stable enough that i no longer needed
> to keep it.

Uh oh

> If I remember correctly from looking at it at the time I had problems with
> the importer, what was in
> /home/<username>/.gnucash
>   was moved to
>   /home/<username>/.local/share/gnucash
> on Linux systems as described in the Wiki page on configuration locations. I
> am presuming this is also he case for Windows systems  but I don't really
> use Windows so can't be sure.

The problem with the gnc code for transition is that it placed no value 
on who accessed it first.

This is slightly specious but if the cleaning lady accessed the file 
first she'd have all the reports in her private space on her phone 
forever!  It is that weird.

>> It is a lot more complicated than you think.
> Wm,
> 2.6 didn't store the saved reports with the book file either, it just stored
> them in a different location, so that is clearly not the problem.

The place was identifiable relative to the book. 3.x changed that.

> What are the other changes that were introduced going from 2.6 to 3.x which
> are causing you problems now in backing up your files that didn't exist with
> 2.6? You are going to have to be specific if anyone is to diagnose and fix
> it.

Other technical people already know.  I'll bore you by saying some 
reports should be part of or very close to a "book". For the simple 
reason that (in the case of my charities for example) only the trustees 
are allowed to report on the accounts.

> I also agree completely that if a report configuration is tied to a specific
> book/set of accounts, i.e. it has been customised or otherwise been modified
> to be specific to that book, then its storage location should be with the
> data file. What defines this level of customisation for you and for me and
> any other user? Could GnuCash  this on the basis of the configuration file
> contents perhaps decide where a particular report configuartion file should
> be located?

Yes, easily.

> Just saving a custom version of a standard report does not appear to
> introduce any ties to a specific book, i.e. if I save the standard Balance
> Sheet as MyBalanceSheet without introducing any references to the account
> structure of that set of books, the guids in it only reference the guid of
> the new report and its parent.

Which doesn't make any sense.

You have just saved a really personal report which is (from a world 
view) risible.  You've saved details that are intensely personal to you, 
not transferable to anyone else and can never be transferred.

Yay, you should be pleased :)

> The other  sections in the report
> configuration General/Accounts/Dsiplay and Commodities, if populated, may
> obviously change this situation. It may be possible to determine at least a
> default choice between storage at the book/user/application level based on
> content, but giving the user the option to override. 

My break

> There is perennial
> balance between simplicity for a new user through sensible defaults and
> flexibility for a more experienced or demanding user.

Hmmn, David, I think with a statement like the above you become a man in 
this forum.

> Some users may also want to customise reports to be very specific to their
> personal individual needs and perhaps apply them to any books they maintain.
> I.e. they would want to store them with what are other user specific
> preferences. Are ther changes in the saved-reports configuration file which
> indicate this?

the current fuckwitted rule is what we were discussing!

> I can also see a situation where reports might be customized for a
> particular jusisdiction for example and may otherwise be close to the
> generic reports and be otherwise useful to other users in that jurisdiction
> i.e. their storage perhaps needs to be at an application level.

I don't have a problem with that, I do point out the gnc model doesn't 
allow such reports to exist

> On the other hand there are the basic standard template reports built in to
> GnuCash which possibly need to be stored at an application level storage
> location.
> I am sure there are possible use cases I haven't thought of as well.
> Perhaps we need to identify:
>      which of these needs Gnucash currently meets;
>      which it should meet at some future point; and
>      how we might get there.

I like this approach.

> The forum is not really a good way to explore this unassisted because we all
> have our own ideas and perspectives floating in our heads and as is fairly
> obvious we are not all talking about the same problem from the same point of
> view.

Sure.  Keep on giving.

> Perhaps we need to map out on a wiki page we can all contibute to the report
> storage structure as it currently is and what we can agree to about what it
> should or could ultimately be and perhaps even arrive at a plan of how to
> get there. The wiki pages have discussion pages attached to them to
> facilitate.

Don't think that will be required unless you want to tease the seniors.

> I can perhaps augment the current wiki Configurations Locations pages with a
> heirarchical diagram which makes the relationships between the environment
> variables and locations defined there a bit clearer. I can really only
> confirm it out for Linux Mint/Ubuntu and Windows.

We'd like that a lot.  If it is a good diagram or chart it will help.

All you need to decide is who looks at it first.

I'd be pissed if it was a good pic and it was refused!

DavidC, my instinct is that you should place it on the wiki, give a link 
here and see what happens.

> Wm,
> Even if we can arrive at some sort of plan, it is only a longer term target.
> Someone has to implement it. GnuCash is not going to get there overnight,
> but at least then we have some agreed general direction to move towards. But
> for the moment we are going to have to live with some sort of workaround.

Yes, thing is, DavidC there is a long term plan and it is mainly 
technical, are you going to say you aren't aware of the long term plan? 
The normal response is rude when I mention it :)


More information about the gnucash-devel mailing list