Wm,
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.
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. Having worked in development
teams which had very limited resources in the past (I once worked for a boss
who thought 3 years of coding to implement a software system to be used by
non-physicists for an accelerator based analytical system could be done over
the weekend by two people. He still insisted this, after the three year
coding effort was completed and both of us had RSI as a result.)
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.
>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. 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.
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. 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.
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.
>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.
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.
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?
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. 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. There is perennial
balance between simplicity for a new user through sensible defaults and
flexibility for a more experienced or demanding user.
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?
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.
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.
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.
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.
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.
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.
David Cousens
-----
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
