[GNC-dev] GnuCash 3 on Linux

[Wm]

On 28/02/2019 00:04, David Cousens wrote:
> Wm
> 
> Diagrams are up https://wiki.gnucash.org/wiki/Configuration_Locations. The
> wkiki markup is crude but works. I will try later to implement a scroll box
> to better accommodate narrow width monitors and mobile devices. Geert
> pointed out a few corrections re what are merely labels for locations and
> what are actual definable environmental variables which are now
> incorporated.

DavidC I like what you are doing a lot.  Keep doing it.

> The original text on the wiki did not distinguish too clearly between what
> were labels for locations and what can be actually set as locations. It was
> there but obscure. In the diagrams these are distinguished as clearly as I
> am able to.

Your use of words is good, "as I am able to".  The point is we don't 
actually know where significant data is.  That isn't a good thing for an 
accounting prog to know or not know.

> On Linux at least those environment variables (not the ones which are merely
> labels) are not created on installation. They can be and then GnuCash should
> use the locations defined by them (I haven't verified this mainly because I
> don't have the need to use it). In principle at least you could define
> GNC_DATA_HOME and GNC_CONFIG_HOME to point to the book location or a
> subdirectories of the directory containing the book.

Yes, the problem is the movement of significant files wasn't forewarned. 
  I really don't know where some of my charity files are now!

>> The problem with the gnc code for transition is that it placed no value
>> on who accessed it first.
> 
> Why would it? GC is not designed as a multiuser program for a multiuser
> environment.

True.  I am not saying it should be.  My argument is about data 
integrity and cohesion.

> It has no user structure to define authorization levels and no
> code to restrict access to specific functionality.

I don't see why you are presenting this argument.

> While there is perhaps an
> ambition to move in this direction longer term, it is nowhere near there
> yet.

Rinse and repeat.

> Admittedly the release notes for V3 only obliquely mention the relocation of
> the user configuration location and that in hindsight should perhaps have
> been highlighted more.  But it came up pretty quickly in the forum
> http://gnucash.1415818.n4.nabble.com/GNC-Saved-Report-Configurations-Missing-After-Upgrade-to-v3-td4700786.html#a4700793
> along with the cure of renaming saved-reports-2.4 to saved-reports-2.8 in
> the new directory.

I'm still using 2.4 are you sure the 2.8 message got out?

It is possible I missed a message but a significant change in the 
reports should have caught my attention since I do have some knowledge 
about them.

>> The place was identifiable relative to the book. 3.x changed that.
> 
> To a place which is also identifiable relative to the book.

Nope.

> The changes going to V3 also make it possible (at least in principle) to
> co-locate the configuration with the book by defining  GNC_DATA_HOME and
> GNC_CONFIG_HOME which was not possible under V2.6.

In principle, yes.

> Again you missed the point that the Save and Save As options in the reports
> toolbar and menu don't or at least shouldn't save the report per se, but
> save only the configuration information for a report. What level of personal
> information gets saved in the configuration is not clear to me.

I am not sure why you are arguing here if you don't understand that 
saved reports contain very specific account information and because of 
that are not transferable from one book to another.

> I can conceive of a situation where a number of books use a stock standard
> account heirarchy and one configures a report to depend on that heirarchy
> but if account guids are incorporated this becomes of limited usefulness wrt
> the ability to transfer reports.

Yes!  The reports are useless if separated from the book!

The question is this: who thought it was a good idea to separate the 
reports from the book?

I think it was Geert but may be wrong.

> The report configuration should not contain the information directly and
> only have pointers to locate the information which is contained only in the
> book. Is that not the case?

Nope, the reports contain actual internal account references, my report 
won't work for you and vice versa because your accounts and my accounts 
have different internal references.

Do you see why the placement of relevant files further away from the 
data makes less sense or not?

Maybe someone is still on Geert's side?

-- 
Wm