subject:"\[GNC\-dev\] GnuCash 3 on Linux"

On 28/02/2019 00:04, David Cousens wrote:

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

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 17:29, Geert Janssens wrote:

Op zondag 24 februari 2019 16:23:24 CET schreef Wm via gnucash-devel:

On 24/02/2019 01:06, David Carlson wrote:

No, it is the name calling and digression from real subject matter.


I had to do the name calling because no-one was paying attention.


The more name calling you do the less I'm inclined to read though. I think I
have read at most half of what you have written the last few days because I
found the signal to noise ratio too low. Just so you know the effectiveness of
your strategy...


There are limited ways of approaching things if the other party won't 
listen.


One can try the thoughtful approach.

One can try being rude.

If none of these work, what do you suggest?

You're the person that is refusing to discuss what you have done wrong.

What is a person meant to do?

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 26/02/2019 08:28, David Cousens wrote:

Wm and other interested parties

To help alleviate the confusion over where user configuration information is
located in V3.x cf v 2.6.x I have started adding some diagrams to illustrate
the changes in locations that occurred which are hopefully a bit easier to
understand than all that text.

Currently I only have a Linux page up and running but I can build the others
easily witha little cut and paste.


I think this is a useful exercise and I'll contribute.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 26/02/2019 08:28, David Cousens wrote:

Wm and other interested parties

To help alleviate the confusion over where user configuration information is
located in V3.x cf v 2.6.x I have started adding some diagrams to illustrate
the changes in locations that occurred which are hopefully a bit easier to
understand than all that text.

Currently I only have a Linux page up and running but I can build the others
easily witha little cut and paste.


The Windows version is, I think, uncertain.

Geert says he knows but doesn't.

Some stuff is, quite simply, lost.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-16 Thread Wm via gnucash-devel


On 16/03/2019 08:18, Colin Law wrote:


I am taking from your lack of response as an indication of the fact
that, having looked back at my posts, you have determined that I did
not say anything that backs up your assertion.  I now consider this
matter closed.


No, you should take my lack of response as me being bored with being 
blocked.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-16 Thread Colin Law

On Tue, 12 Mar 2019 at 09:14, Colin Law  wrote:
>
> On Tue, 12 Mar 2019 at 04:19, Wm via gnucash-devel
>  wrote:
> >
> > On 24/02/2019 15:40, Colin Law wrote:
> > > On Sun, 24 Feb 2019 at 15:21, Wm via gnucash-devel
> > >  wrote:
> > >>
> > >> That is the point, dear, you may not have said a swearword but what you
> > >> are supporting is shameful.
> > >
> > > Please don't call me dear.  That is almost as bad as labelling me a
> > > Trump supporter.
> > > I don't understand what it is you think I am supporting, all I am
> > > supporting here is gnucash and civility.
> >
> > If arguments were heard I'd agree.
> >
> > No-one likes repeating themself.
>
> Just please quote the bit of whichever of my posts upset you so much,
> if you have already done that then apologies for asking you to repeat
> yourself.  You said "what you are supporting is shameful" but I don't
> know where in my posts I am supporting something that is shameful.

I am taking from your lack of response as an indication of the fact
that, having looked back at my posts, you have determined that I did
not say anything that backs up your assertion.  I now consider this
matter closed.

Colin
>
>
> Colin
>
> >
> > --
> > Wm
> >
> >
> >
> >
> > ___
> > 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

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 15:40, Colin Law wrote:

On Sun, 24 Feb 2019 at 15:21, Wm via gnucash-devel
 wrote:


That is the point, dear, you may not have said a swearword but what you
are supporting is shameful.


Please don't call me dear.  That is almost as bad as labelling me a
Trump supporter.
I don't understand what it is you think I am supporting, all I am
supporting here is gnucash and civility.


If arguments were heard I'd agree.

No-one likes repeating themself.

--
Wm




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 07/03/2019 23:42, David Cousens wrote:


I backup all user data including hidden directories on my hard disk to an
NAS so no matter where it is I have it copied. I do full backups monthly
with daily incrementals and usually retain them for 3 months these days.  I
off load the backups onto USB for offsite storage as well now that they are
big enough. I'm retired so the data flow is very much reduced these days. I
also do selective backups to offsite cloud locations of critical data
including GnuCash. For those I backup all the data in the locations given
for v3+ in the wiki Configuration Locations for GnuCash. I don't bother with
the aplication config in /usr/local/etc/gnucash as I don't edit anything in
it.  My desktop is also synced with my laptop and my wife's laptop- not
really secure as a backup as any saved changes get propagated including
those that might take the system down but it has helped with some simple
problems. My NAS is NFS4 based so my Linux boxes communicate pretty easliy
with it (it is mounted when switched on on all computers and Samba takes
care of the one Windows machine. Took a while to setup but the NAS initiates
backups to itself on a schedule. Also backs up our mobile phones.

When I was operating a business and in a past side job as a systems manager,
I used a Towers of Hanoi (annual/quarterly/monthly/weekly/incremental)
backup plan.

The locations I would backup as a matter of course would be the ones
labelled GNC_DATA_HOME and GNC_CONFIG_HOME ( and all files and
subdirectories in those locations) in the diagrams. I haven't bothered
customising the gtk-3 setup for GnuCash so I wouldn't bother with the GTK
locations.


Devil's advocate:

If (I am not wishing this on you, David, or anyone else, but it is not 
an unreasonable thing to think about if you are in Oz) flood or fire 
destroyed your home and your computer systems would you know what to 
restore?


I think you don't or can't know what to restore wrt gnc at the moment.

Making a backup plan is good but purposeless if there isn't a restore 
plan to match.


re GNC_DATA_HOME and GNC_CINFIG_HOME you don't seem to have grasped that 
these are not consistent!


At the risk of re-using stuff take a look at
https://en.wikipedia.org/wiki/Fitch%27s_paradox_of_knowability

In plain terms you may have a good back up strategy but have you tried 
putting it all back together?  I think not, if only because the gnc bits 
will be all over the place.  Will you have the latest version of all the 
files?  Probably.  Will you be able to put it together as it last was? 
Unlikely.


--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 08/03/2019 14:49, Derek Atkins wrote:

Adrien Monteleone  writes:


Separating preferences for reports is, I suspect, more useful to a
multi-user environment, which GnuCash does not support, but can be
useful for a single user who keeps books for multiple entities that
are all in the same jurisdiction and might well even use the same
CPA. (and certainly have to file the same tax forms) They might even
all follow a July-June fiscal year, for example.


The whole options subsystem needs to be re-evaluated.  I feel there are
multiple categories:

* Per-User
* Per-User Per-Book
* Per-Book


I agree.  Further, we are able to do this and have done it before, those 
with long memories may recall some things were moved (in a user sense) from

  Edit / Preferences (where they didn't belong)
to
  File / Properties (where they sat more naturally)

It might be useful for people to consider
  what belongs to the file?
  what belongs to me?
  is gnc an extension of me as a person?
  or is it a record of fact?

I've said this before but gnc has a screwed up view of ownership when 
the prices.db (which is by definition impersonal) is included in the 
book but reports (which are intrinsic to the book, as in they contain 
actual id's that don't make sense anywhere else) are left all over the 
place.



This includes things like the display features that you mentioned (which
I snipped off).  You're right, I feel that the column settings, and even
whether to display placeholder and/or zero-balance accounts is probably
a Per-User setting.


Column settings I think of as per user.

Placeholder ticks should be per book as gnc "does things wrong" if you 
enter tx at the placeholder level by accident and the account structure 
includes a mixture of commodities, currencies or anything else not the 
same.  If all of the accounts below the placeholder are the same as the 
the placeholder account it works OK in my experience, but only in that case.


I think of zero balance account display as a report setting.


I think it would behoove us to go through every option, every
preference, and every report option and decide which bucket they belong
to.  Indeed, many of the report options may need to be split into
different categories, but I'm not exactly sure how to do that properly.


I would be prepared to help with this as I would like to contribute and 
it seems like it will be years before my database and reporting skills 
will be utilised.



I'm not convinced it's all about multi-user -- although part of it is.
And for the record, GnuCash DOES support multiple sequential users.  It
just does not support multiple simultaneous users.


Agreed. I think the multi-user argument is a red herring.  The current 
structure is failing on all of


  same-user same-computer different-login
  same-user same-login different-computer
  same-book same-user different-login
  same-book same-user different-computer

I could go on about all the combinations the 3.x structure simply does 
 not support, hopefully those are enough for ordinary people to 
understand that what we have is fucked.


multi-user isn't the problem to be solved, people understand if you say 
to them "gnc is like a spreadsheet, it doesn't work well if more than 
one person is changing it at once", it is damn hard to explain to them 
you don't know where their reports are!  saying "gnc did it" doesn't 
work in my world view.



I started a project to map out report preferences as part of a revamp
of the tab content and I didn’t finish it. Perhaps completing that
project will offer more insight. (and very likely allow me to discover
that the present situation is optimal)


I think this would still be a useful project, to map out all the various
preferences and settings throughout the application.


+1

I think we might need some people to change their ideas about what 
belongs to what before we can really progress.  There isn't any point in 
defining stuff if it isn't going to be listened to or understood.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 07/03/2019 20:03, Adrien Monteleone wrote:

Derek,

I don’t disagree with your assessments of what certainly *can* (and maybe even, 
more often than not) be specific to a book rather than a user. I was thinking 
more along the lines of what someone *might* most likely want to carry over 
across multiple books. For example, I keep books for a few entities. Everything 
is in USD. (except for my personal book which has a smattering of left over 
currency from travels and some bullion I track as currency) I have no need for 
other currencies, and likely never will. At the least, I’d want to start books 
for a new entity, should one arise, with that same default currency in my 
reports. (simple enough since the default book currency is also the default 
report currency)

But I might also like to never show zero balance amounts or the corresponding 
accounts, and I might like to always roll up the sub account totals into the 
parent (since I set all parents as placeholders) and *not* show any duplicative 
’total’ lines.

These were the types of settings I was thinking of that someone might want to 
carry over across all books and maybe even all reports. (where applicable) The 
same might very well applied to financial periods.

Separating preferences for reports is, I suspect, more useful to a multi-user 
environment, which GnuCash does not support, but can be useful for a single 
user who keeps books for multiple entities that are all in the same 
jurisdiction and might well even use the same CPA. (and certainly have to file 
the same tax forms) They might even all follow a July-June fiscal year, for 
example.

It might be that this is too small of a use case, and the user’s setup work so 
light that the development burden is simply not worth the effort. (and I’m by 
no means advocating for more work for the team already, I’m just chiming in 
with my own user story to consider.)

I started a project to map out report preferences as part of a revamp of the 
tab content and I didn’t finish it. Perhaps completing that project will offer 
more insight. (and very likely allow me to discover that the present situation 
is optimal)


If you're doing accounting for yourself and never plan to use a 
different computer or operating system, know how to make backups and are 
infallible (think about that list) the 3.x model is fine.


OK, the infallibility is extreme but the 3.x file structure is just 
putting stuff all over the place without apparent thought.


There are really simple answers to this, they presume
===
don't do what Microsoft told you to do
===
especially since they don't do it themselves in their own products.
===


No one in their right mind puts reports that depend on exact information 
in another file in personal file space *AND* expects things to work when 
any of so many things change.


Another e.g. someone sets up a report, their PC has got a bit cluttered, 
they run a popular disk cleaner, result?  Report is AWOL.


--
Wm




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-08 Thread Derek Atkins

Adrien Monteleone  writes:

> Separating preferences for reports is, I suspect, more useful to a
> multi-user environment, which GnuCash does not support, but can be
> useful for a single user who keeps books for multiple entities that
> are all in the same jurisdiction and might well even use the same
> CPA. (and certainly have to file the same tax forms) They might even
> all follow a July-June fiscal year, for example.

The whole options subsystem needs to be re-evaluated.  I feel there are
multiple categories:

* Per-User
* Per-User Per-Book
* Per-Book

This includes things like the display features that you mentioned (which
I snipped off).  You're right, I feel that the column settings, and even
whether to display placeholder and/or zero-balance accounts is probably
a Per-User setting.

I think it would behoove us to go through every option, every
preference, and every report option and decide which bucket they belong
to.  Indeed, many of the report options may need to be split into
different categories, but I'm not exactly sure how to do that properly.

I'm not convinced it's all about multi-user -- although part of it is.
And for the record, GnuCash DOES support multiple sequential users.  It
just does not support multiple simultaneous users.

> I started a project to map out report preferences as part of a revamp
> of the tab content and I didn’t finish it. Perhaps completing that
> project will offer more insight. (and very likely allow me to discover
> that the present situation is optimal)

I think this would still be a useful project, to map out all the various
preferences and settings throughout the application.

> Regards,
> Adrien

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-07 Thread David Cousens

Wm,

I backup all user data including hidden directories on my hard disk to an
NAS so no matter where it is I have it copied. I do full backups monthly
with daily incrementals and usually retain them for 3 months these days.  I
off load the backups onto USB for offsite storage as well now that they are
big enough. I'm retired so the data flow is very much reduced these days. I
also do selective backups to offsite cloud locations of critical data
including GnuCash. For those I backup all the data in the locations given
for v3+ in the wiki Configuration Locations for GnuCash. I don't bother with
the aplication config in /usr/local/etc/gnucash as I don't edit anything in
it.  My desktop is also synced with my laptop and my wife's laptop- not
really secure as a backup as any saved changes get propagated including
those that might take the system down but it has helped with some simple
problems. My NAS is NFS4 based so my Linux boxes communicate pretty easliy
with it (it is mounted when switched on on all computers and Samba takes
care of the one Windows machine. Took a while to setup but the NAS initiates
backups to itself on a schedule. Also backs up our mobile phones. 

When I was operating a business and in a past side job as a systems manager, 
I used a Towers of Hanoi (annual/quarterly/monthly/weekly/incremental)
backup plan. 

The locations I would backup as a matter of course would be the ones
labelled GNC_DATA_HOME and GNC_CONFIG_HOME ( and all files and
subdirectories in those locations) in the diagrams. I haven't bothered
customising the gtk-3 setup for GnuCash so I wouldn't bother with the GTK
locations. 

David



-
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

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-07 Thread Adrien Monteleone

Derek,

I don’t disagree with your assessments of what certainly *can* (and maybe even, 
more often than not) be specific to a book rather than a user. I was thinking 
more along the lines of what someone *might* most likely want to carry over 
across multiple books. For example, I keep books for a few entities. Everything 
is in USD. (except for my personal book which has a smattering of left over 
currency from travels and some bullion I track as currency) I have no need for 
other currencies, and likely never will. At the least, I’d want to start books 
for a new entity, should one arise, with that same default currency in my 
reports. (simple enough since the default book currency is also the default 
report currency)

But I might also like to never show zero balance amounts or the corresponding 
accounts, and I might like to always roll up the sub account totals into the 
parent (since I set all parents as placeholders) and *not* show any duplicative 
’total’ lines.

These were the types of settings I was thinking of that someone might want to 
carry over across all books and maybe even all reports. (where applicable) The 
same might very well applied to financial periods.

Separating preferences for reports is, I suspect, more useful to a multi-user 
environment, which GnuCash does not support, but can be useful for a single 
user who keeps books for multiple entities that are all in the same 
jurisdiction and might well even use the same CPA. (and certainly have to file 
the same tax forms) They might even all follow a July-June fiscal year, for 
example.

It might be that this is too small of a use case, and the user’s setup work so 
light that the development burden is simply not worth the effort. (and I’m by 
no means advocating for more work for the team already, I’m just chiming in 
with my own user story to consider.)

I started a project to map out report preferences as part of a revamp of the 
tab content and I didn’t finish it. Perhaps completing that project will offer 
more insight. (and very likely allow me to discover that the present situation 
is optimal)

Regards,
Adrien

> On Mar 7, 2019, at 10:14 AM, Derek Atkins  wrote:
> 
> hi,
> 
> Adrien Monteleone  writes:
> 
>> I’ll hazard a quick guess that everything not in the accounts tab is
>> non-book specific.
> 
> I'm not sure I completely agree with this statement.
> 
>> At the very least, the display and general tabs are not.
> 
> Maybe..
> 
>> How you want figures to be displayed, which sets of figures, which periods...
> 
> Different companies might have different periods; therefore, the period
> is tied to the book, not the person.
> 
>> Content settings may be tied to the book, but formatting settings are
>> likely to be the most likely to be used cross-book. I can certainly
>> see someone wanting all of their reports looking the same.
> 
> I mostly agree with this statement, but I think it depends greatly on
> the definitions of "content settings" and "formatting settings".  Sure,
> window sizes, tabs v windows, color schemes -- those are clearly
> formatting setting and should be per-user.  But "default currency",
> "periods", and certain parts of report configurations (e.g. accounts to
> include) are definitely content settings and belong with the book data.
> 
>> Regards,
>> Adrien
> 
> -derek

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-07 Thread Derek Atkins

hi,

Adrien Monteleone  writes:

> I’ll hazard a quick guess that everything not in the accounts tab is
> non-book specific.

I'm not sure I completely agree with this statement.

> At the very least, the display and general tabs are not.

Maybe..

> How you want figures to be displayed, which sets of figures, which periods...

Different companies might have different periods; therefore, the period
is tied to the book, not the person.

> Content settings may be tied to the book, but formatting settings are
> likely to be the most likely to be used cross-book. I can certainly
> see someone wanting all of their reports looking the same.

I mostly agree with this statement, but I think it depends greatly on
the definitions of "content settings" and "formatting settings".  Sure,
window sizes, tabs v windows, color schemes -- those are clearly
formatting setting and should be per-user.  But "default currency",
"periods", and certain parts of report configurations (e.g. accounts to
include) are definitely content settings and belong with the book data.

> Regards,
> Adrien

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-06 Thread Frank H. Ellenberger

Adrien,

I do not agree. While you are free in your choice for a private book,
which is not used for tax preparation, all other cases are limited by
governmental rules.

If you then as a border crosser have books for different countries
already the date and number formats differ for the same language.

An agricultural business on the northern hemisphere might use a year
starting with 1. October, your other branches will use the "normal" year...

~Frank

Am 06.03.19 um 19:22 schrieb Adrien Monteleone:
> I’ll hazard a quick guess that everything not in the accounts tab is non-book 
> specific.
> 
> At the very least, the display and general tabs are not.
> 
> How you want figures to be displayed, which sets of figures, which periods...
> 
> Content settings may be tied to the book, but formatting settings are likely 
> to be the most likely to be used cross-book. I can certainly see someone 
> wanting all of their reports looking the same.
> 
> 
> Regards,
> Adrien

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-06 Thread Adrien Monteleone

I’ll hazard a quick guess that everything not in the accounts tab is non-book 
specific.

At the very least, the display and general tabs are not.

How you want figures to be displayed, which sets of figures, which periods...

Content settings may be tied to the book, but formatting settings are likely to 
be the most likely to be used cross-book. I can certainly see someone wanting 
all of their reports looking the same.


Regards,
Adrien

> On Mar 6, 2019, at 9:18 AM, Derek Atkins  wrote:
> 
> Hi,
> 
> Coming at this late...
> 
> Geert Janssens  writes:
> 
>> For starters the user preference is an all or nothing thing, either all 
>> reports are in a book or in a common location. That's not very fine-grained. 
>> Perhaps you consider some reports common and some reports book-specific. 
>> This 
>> could be solved by making it a per report option of course.
> 
> I can picture very few cases where a configured report is not tied to
> the book.  If it contains references to *ANY* accounts, then it is, by
> definition, book-specific and should live with the data.  This is, IMHO,
> most reports.
> 
>> And yet another issue: reports are only suitable for multiple books if these 
>> books have the exact same base as required per report. An example to clarify 
> 
> EXACTLY!
> 
> The only time all saved-reports are useful across books is if the books
> are derived from the same base.  I.e., you copy, or save-as.
> 
> If the reports are stored in the book data itself then you get this for
> free.
> 
> [snip]
>> So my conclusion is that report configurations are essentially book specific 
>> and should be treated as such to avoid unexpected accounting mistakes.
> 
> Agreed.
> 
>> On the other hand I understand it takes time to carefully configure
>> reports to your preference and there's a wish to reuse this effort
>> across books.
> 
> Perhaps we need an "export report configuration" that can extract the
> non-book-specific settings?
> 
> -derek
> 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-03-06 Thread Derek Atkins

Hi,

Coming at this late...

Geert Janssens  writes:

> For starters the user preference is an all or nothing thing, either all 
> reports are in a book or in a common location. That's not very fine-grained. 
> Perhaps you consider some reports common and some reports book-specific. This 
> could be solved by making it a per report option of course.

I can picture very few cases where a configured report is not tied to
the book.  If it contains references to *ANY* accounts, then it is, by
definition, book-specific and should live with the data.  This is, IMHO,
most reports.

> And yet another issue: reports are only suitable for multiple books if these 
> books have the exact same base as required per report. An example to clarify 

EXACTLY!

The only time all saved-reports are useful across books is if the books
are derived from the same base.  I.e., you copy, or save-as.

If the reports are stored in the book data itself then you get this for
free.

[snip]
> So my conclusion is that report configurations are essentially book specific 
> and should be treated as such to avoid unexpected accounting mistakes.

Agreed.

> On the other hand I understand it takes time to carefully configure
> reports to your preference and there's a wish to reuse this effort
> across books.

Perhaps we need an "export report configuration" that can extract the
non-book-specific settings?

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-27 Thread David Cousens

>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. It has no user structure to define authorization levels and no
code to restrict access to specific functionality. While there is perhaps an
ambition to move in this direction longer term, it is nowhere near there
yet.

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

To a place which is also identifiable relative to the book.

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.

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?

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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-27 Thread Geert Janssens

Op woensdag 27 februari 2019 20:36:57 CET schreef Wm via gnucash-devel:
> On 24/02/2019 17:18, Geert Janssens wrote:
> > Op zondag 24 februari 2019 17:19:09 CET schreef Wm via gnucash-devel:
> > 
> > Looks like you are now lying in public... (using your own conversation
> > style here).
> > 
> > Nothing gets deleted by the migration so there can't be data loss.
> 
> We are talking well on the bug list, Geert.  What you say is untrue,
> don't spoil the illusion until you know the details and truth of what
> can be lost.
> 
You know what Wm ?

I care about a constructive conversation, but this isn't one in my book and it 
saddens me we didn't manage to make it one. I've run tired of this dancing 
around and so I'll end it right here.

I have repeatedly asked about specific and objective details about your issue 
in an effort to help you solve it. All I get is "you're wrong, I'm right, 
you'll see" and vague allusions to design flaws. I don't care about right or 
wrong, but about solving problems.

You on the other hand seem to enjoy grand talk more than having your problem 
solved. So I have nothing more to contribute here. I feel I have wasted enough 
time on this.

In short: you don't pay me enough to be entitled to insult or belittle me and 
at the same time expect me to continue to help you.

Enjoy your life and goodbye,

Geert

PS I will ignore your mails future mails until I find you have learned how to 
respectfully and constructively communicate with other people.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-27 Thread Wm via gnucash-devel


On 24/02/2019 01:50, Chris Good wrote:


Chris,

If I save reports from GnuCash 3.4 on Linux Mint Tara (Ubuntu 18.04), the
reports are saved in
/home//.local/share/gnucash/saved-reports-2.8 and I have verified this
contains the report config which I saved.


yay


This is where I expected to find them based on the description in
https://wiki.gnucash.org/wiki/Configuration_Locations.


yay


I am not sure what the 2.4 in your case and 2.8 in my case actually refer
to. The wiki says  they are related to GnuCash versions but not obviously
the version which is running.


2.8 and 2.4 make no difference, wastrel :)


Hi David,

Geert answered this 6/6/2018:

2.8, not 2.4. If not 2.8 file is found, gnucash 3 and up will search for a
saved-reports-2.4, but it will only save to saved-reports-2.8.


this is a spit mouth reply as it doesn't say *where* the report file 
will be saved.


I expected more of you, ChrisG


I haven't updated the wiki as it was recently changed to say:
saved-reports-x.y
presumably to ensure it doesn't quickly become outdated.

Personally, I would prefer if it was more specific.


I'm hoping I'll prevail or you or someone with some sense.


I am finally about to release my BackupGnuCash java app 1.3.0, now updated
for GnuCash 3.


Scary stuff, brave you.


As it is difficult to tell if a configuration file location has been
overridden by an environment variable somewhere, I've taken the tack of only
looking for configuration files to backup in the default locations.



Regards,
Chris Good


May I have a look at your script?

Love, Wm



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-27 Thread Wm via gnucash-devel


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//.gnucash

  was moved to

  /home//.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,

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-27 Thread Wm via gnucash-devel


On 24/02/2019 17:18, Geert Janssens wrote:

Op zondag 24 februari 2019 17:19:09 CET schreef Wm via gnucash-devel:



Looks like you are now lying in public... (using your own conversation style
here).

Nothing gets deleted by the migration so there can't be data loss.


We are talking well on the bug list, Geert.  What you say is untrue, 
don't spoil the illusion until you know the details and truth of what 
can be lost.



If the
migration was actually triggered all files from DOT_GNUCASH_DIR have been
*copied* to either GNC_DATA_HOME or GNC_CONFIG_HOME. You can look up the exact
locations per platform on https://wiki.gnucash.org/wiki/
Configuration_Locations. The original files are still in DOT_GNUCASH_DIR.


The problem is all of those VARIABLES were different for each person so 
we don't know where the bits and pieces of gnc have gone for everyone.


I think this is an irrevocable error.

If anyone is interested Geert and I are talking about this on the bug 
list in detail.


This will, I think, turn out to be a mistake.
--
Wm



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-26 Thread Geert Janssens

Op dinsdag 26 februari 2019 14:18:42 CET schreef David Cousens:
> Hi Geert
> 
> Thanks for the corrections. I'll make those that are labels and not
> environment variables black to indicate that.  I've now indicated what are
> environment Variables but I'm hoping that doesn't imply they should
> necessarily be editable. I've put do not edit notes against the HOME
> variables.  I haven't mentioned XDG_DATA_HOME and XDG_CONFIG_HOME in the
> diagrams. I am intending readers to go to the text explanations for more
> detail where required.
> 
> David

Very good. I agree XDG_* is for advanced use.

Thanks!

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-26 Thread David Cousens

Hi Geert

Thanks for the corrections. I'll make those that are labels and not
environment variables black to indicate that.  I've now indicated what are
environment Variables but I'm hoping that doesn't imply they should
necessarily be editable. I've put do not edit notes against the HOME
variables.  I haven't mentioned XDG_DATA_HOME and XDG_CONFIG_HOME in the
diagrams. I am intending readers to go to the text explanations for more
detail where required.

David



-
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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-26 Thread Geert Janssens via gnucash-devel

Op dinsdag 26 februari 2019 09:28:41 CET schreef David Cousens:
> Wm and other interested parties
> 
> To help alleviate the confusion over where user configuration information is
> located in V3.x cf v 2.6.x I have started adding some diagrams to
> illustrate the changes in locations that occurred which are hopefully a bit
> easier to understand than all that text.
> 
> Currently I only have a Linux page up and running but I can build the others
> easily witha little cut and paste.
> 
> David Cousens

David,

Thanks for this work. The diagrams are much easier to get an overview quickly.

It also is not completely accurate in what is marked as "environment 
variables" (in green). Not all of these symbolic names are actually variables 
that influence gnucash/gtk in any way. I only used these symbolic names to 
create a logical structure.

Of the ones you have marked as environment variables DOT_GNUCASH_DIR (for 
gnucash 2.6 and older), GNC_DATA_HOME (for gnucash 3.x and (as of gnucash 3.4) 
GNC_CONFIG_HOME will indeed be honored by gnucash.

But USER_DATA_HOME and USER_CONFIG_HOME are not interepreted in any way. And 
as far as I know GTK_DATA_HOME and GTK_CONFIG_HOME aren't either. On linux and 
MacOS you can manipulate the locations GTK uses by setting XDG_DATA_HOME and 
XDG_CONFIG_HOME. Gtk will access XDG_DATA_HOME/gtk- and 
XDG_CONFIG_HOME/gtk- respectively. 

XDG_DATA_HOME and XDG_CONFIG_HOME also affect gnucash in the same way though 
GNC_DATA_HOME and GNC_CONFIG_HOME take precedence if set.

HOME is indeed an environment variable, though I'd avoid changing this as it 
has a broad impact.

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-26 Thread David Cousens

Wm and other interested parties

To help alleviate the confusion over where user configuration information is
located in V3.x cf v 2.6.x I have started adding some diagrams to illustrate
the changes in locations that occurred which are hopefully a bit easier to
understand than all that text. 

Currently I only have a Linux page up and running but I can build the others
easily witha little cut and paste.

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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-24 Thread David Cousens

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//.gnucash

 was moved to

 /home//.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

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 16:51, Geert Janssens wrote:

Op zondag 24 februari 2019 12:54:35 CET schreef Wm via gnucash-devel:

On 24/02/2019 02:25, David Cousens wrote:

Wm,


David, I appreciate your efforts as peacemaker, don't give up on all of
us yet, most of us are trying to be good, promise :)


If you draw a diagram from the information in the wiki page
https://wiki.gnucash.org/wiki/Configuration_Locations
where the  meta data and report data is stored becomes fairly obvious and
is fairly simple.


I disagree, the user doesn't always know where their stuff is and
therefore can't make a sensible backup.  We (gnc) have a theory about
where stuff should be but in practice it could be just about anywhere.

My argument is that we should put important stuff near or approximate to
the data it relates to rather than further away from it.


There was considerable discussion in the forums at the time the changes
were being made from 2.6 to 3.0.


Not all views were heard.  Taking a poll and not listening to the views
that disagree with you is ordinary.

This has ended up with me saying Geert (a person I respect enormously)
may be a liar :(


Sigh...

Let it be clear the current thread is mixing up several discussions.

1. I agree (and always have) that certain data (like saved reports) is stored
in the wrong place, namely in the metadata directory instead of in the gnucash
data file.


Near the data file is fine, it doesn't have to be inside it.  the stored 
reports mechanism is imperfect but OK so long as we can keep a close 
association with the data the reports are reporting on.


I'm not the only person that has noticed that stored reports are 
essentially useless when not associated with the data to which they belong.


Are you unusually stupid in this regard?


This has been historically so and hasn't changed between gnucash
2.6 and 3. 


Not true, there was a structural change between 2.x and 3.x


The same data is still stored in locations reserved for application
internal housekeeping (metadata).


I'm listening to you trying to work out what you did wrong.


2. In the preparations to line up to gnucash 3 I decided to do some lower
level housekeeping, namely to move everything that was *already stored* in the
historical metadata/config directory ($HOME/.gnucash on linux) into present
day recommended locations per platform ($HOME/.config/gnucash and
$HOME/.local/share/gnucash on linux).


I think that was unwise, let's continue.


On MacOS this was already the case so
nothing changed there. On windows the move was from $HOME/.gnucash to
%APPDATA%\GnuCash, the default location on Windows *and* a request by several
users that didn't like the .gnucash in their $HOME.


Hmmmn, OK, you can make it my fault for not being strong enough in 
objecting.  Is that what you want me to say?  I honestly didn't believe 
gnc would do such a stupid thing.



It was never my aim at
that point to do the bigger cleanup of sorting out which stuff that was in
separate metadata files should really be moved into the gnucash data file.


But that is what happened and, I think, can't be undone now.

https://bugs.gnucash.org/show_bug.cgi?id=797117


That's a completely different work that should still happen somewhere further
down in the current big refactoring.


I think it is too late.


In further discussions, let's try to be clear please about what aspect is
being discussed.


I'd like you to address the bug, remember this all started with someone 
asking what to back up and no senior person from gnc having an answer.


*you* put the metadata somewhere and *you* don't know where it is.

shame on you.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 19:36:37 CET schreef Wm via gnucash-devel:
> On 24/02/2019 17:08, Geert Janssens wrote:
> > You do like misinterpreting other peoples words to your benefit...
> 
> Only if necessary.  I have never seen you like this before.
> 
> > I never said it was a requirement to get gnc implemented on Windows. I
> > said
> > gnucash chose to better integrate with each platform.
> 
> mixed words, no argument from me.  The 2.x to 3.x changes affected all
> platforms I am aware of, see the start of the thread.
> 
> > And please re-read my other message. We're talking in different contexts.
> > You continue to discuss on the level of what should be considered
> > metadata and what should be part of the gnucash data itself.
> 
> Are you saying my understanding of metadata is wrong?  If so we can
> certainly discuss that in another thread.
> 
> > I'm only talking default
> > metadata locations itself
> 
> I've seen this before, you are narrowing the available space you might
> be responsible for.
> 
> Doesn't work for me, Geert.
> 
> >as that's the only aspect in this context that has
> >
> > changed in gnucash 3.x. That some data should not be considered metadata
> > is
> > not under debate. We agree on that.
> 
> Oh...kay
> 
> help me to understand what you think is and isn't gnc's responsibility.
> 
> You don't give a donder about reports, right?  They're just occasional drek.
> 
> It doesn't matter to you that someone took months getting a budget
> together and producing a report on that budget to satisfy their
> Trustees.  You thought it was a good idea to just move a whole bunch of
> stuff to someone else's computer leaving no trace of the work behind.
> 
> The thing that pisses me off is that you appear to be defending this
> harmful decision rather than apologizing.
> 
> I have never in all my years of work with gnc seen you behave like this
> before, Geert, it seems to me you are running backwards faster than your
> legs will work.

Huh? What you're writing here just doesn't make sense to me.

If you want me to work with you you'll have to provide me with the exact 
problem you are 
facing instead of vague generalisms and suggestions.

You may have done so before but given the low signal to noise ratio of much of 
the conversation 
about this I may have missed it.

Then I can work out what's wrong if anything and look for a solution.

Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 17:08, Geert Janssens wrote:


You do like misinterpreting other peoples words to your benefit...


Only if necessary.  I have never seen you like this before.


I never said it was a requirement to get gnc implemented on Windows. I said
gnucash chose to better integrate with each platform.


mixed words, no argument from me.  The 2.x to 3.x changes affected all 
platforms I am aware of, see the start of the thread.



And please re-read my other message. We're talking in different contexts. You
continue to discuss on the level of what should be considered metadata and
what should be part of the gnucash data itself.


Are you saying my understanding of metadata is wrong?  If so we can 
certainly discuss that in another thread.



I'm only talking default
metadata locations itself 


I've seen this before, you are narrowing the available space you might 
be responsible for.


Doesn't work for me, Geert.


as that's the only aspect in this context that has
changed in gnucash 3.x. That some data should not be considered metadata is
not under debate. We agree on that.


Oh...kay

help me to understand what you think is and isn't gnc's responsibility.

You don't give a donder about reports, right?  They're just occasional drek.

It doesn't matter to you that someone took months getting a budget 
together and producing a report on that budget to satisfy their 
Trustees.  You thought it was a good idea to just move a whole bunch of 
stuff to someone else's computer leaving no trace of the work behind.


The thing that pisses me off is that you appear to be defending this 
harmful decision rather than apologizing.


I have never in all my years of work with gnc seen you behave like this 
before, Geert, it seems to me you are running backwards faster than your 
legs will work.


--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 16:23:24 CET schreef Wm via gnucash-devel:
> On 24/02/2019 01:06, David Carlson wrote:
> > No, it is the name calling and digression from real subject matter.
> 
> I had to do the name calling because no-one was paying attention.

The more name calling you do the less I'm inclined to read though. I think I 
have read at most half of what you have written the last few days because I 
found the signal to noise ratio too low. Just so you know the effectiveness of 
your strategy...

Regards,

Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 17:19:09 CET schreef Wm via gnucash-devel:
> On 24/02/2019 03:12, David Cousens wrote:
> > Wm
> > 
> > You could have a startup script which copied a common user config file for
> > GnuCash from a backup or other central location to each users home
> > directory and then copied it back on exit.
> > 
> > On Linux the files would be those in the directories:
> > 
> > /home//.local/share/gnucash  (all user data)
> > /home//.config/gnucash  (gnucash config data)
> > /home//.local/share/gtk-3.0(gtk data)
> > /home//.config/gtk-3.0   (gtk config)
> > 
> > On Windows they should be in
> > 
> > c:\Users\\AppData\Local\GnuCash or
> > c:\Users\\AppData\Local\gtk-3.0
> > 
> > OR
> > 
> > c:\Users\\AppData\Roaming\GnuCash
> > c:\Users\\AppData\Roaming\gtk-3.0
> > 
> > Don't know enough about Windoze anymore to know which set is most likely
> > to
> > be used but this link has an explanation
> > https://www.makeuseof.com/tag/appdata-roaming-vs-local/
> > 
> > If you only wanted to back up the reports not just all user data, you
> > could
> > just backup the
> > saved-reports-. from the requisite directories and just restore that
> > file from a backup or other central copy stored with the main book file.
> 
> It is a lot more complicated than you think.
> 
> Let me open this part of the discussion by saying:
> 
> Does gnc know where it took stuff from and placed it when 3.x was run
> for the first time?
> 
> We know this was a one way change but were the from and to locations
> known about and recorded?
> 
> I think they weren't all known about and recorded and gnc has
> contributed to actual data loss. <-- not something I ever wanted to say
> as this was warned about and avoidable.  The warnings were ignored.

Looks like you are now lying in public... (using your own conversation style 
here).

Nothing gets deleted by the migration so there can't be data loss. If the 
migration was actually triggered all files from DOT_GNUCASH_DIR have been 
*copied* to either GNC_DATA_HOME or GNC_CONFIG_HOME. You can look up the exact 
locations per platform on https://wiki.gnucash.org/wiki/
Configuration_Locations. The original files are still in DOT_GNUCASH_DIR.

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 14:50:27 CET schreef Wm via gnucash-devel:
> On 24/02/2019 08:44, Geert Janssens wrote:
> > Completely agree in today's context. There have been reasons in the past
> > it
> > was done as it is. If someone has spare time and epxerience I gladly
> > accept
> > patches to fix this technical debt.
> 
> There was nothing to fix in this regard in gnc 2.x
> 
> gnc 3.x changed things, do *not* try and escape this, Geert!
> 
> gnc 3.x made things worse not better in this regard.  Understand?
> 
You are entitled to your opinion of course. But I disagree.


> >> The fact that we even need a wiki page dedicated to file and
> >> configuration
> >> locations-- let alone one as long and convoluted as the one we have (and
> >> which needs additional diagramming)-- only underscores this problem.
> > 
> > No, it underscores the dev team's willingness to be as open as possible
> > about the complexities of a mature cross-platform application. Many
> > applications store (meta)data is locations defined by the context.
> 
> I know what you are saying, Geert, you are also wrong.  The
> implementation of those concepts in gnc 3.x is a disaster for some, e.g
> I have charities that cannot use gnc 3.x
> 
> I must ask again, because I do not want to shoot the messenger, who
> thought this change from 2.x to 3.x was a good idea?  Who proposed it?

What changes exactly are you referring to ? What changes prevent charities 
from using gnc 3.x ?

> Did the person that proposed it understand what they were suggesting
> meant for all people or just for themselves?
> 
> This change is fundamentally wrong to what I understand the gnc ethos to
> be.  People should have access to their own data, people should control
> their own data, people's data should be where they expect it to be.
> 
> Geert, the way you are talking it sounds like you voted for Facebook.
> 
If you want me to continue this conversation with you, I'd suggest you stick 
to the topic.

> > Go search for
> > libreoffice's metadata for example, or firefox'. If you would want to
> > document their metadata structures, you'd see something similar or even
> > more complex.
> I know both those programs and know where they store stuff.  You may
> recall I mentioned portableapps.com a while ago so don't be surprised
> /someone else knows about where other apps put stuff.
> 
> In short, documenting metdata structures about gnc is mainly done.  So
> shut up and do something useful, please.
> 
> > Part of the complexity comes from the multi-platform nature of gnucash.
> > Each platform defines their own default locations for various kinds of
> > data. And gnucash tries to apply these per platform.
> 
> Geert: I think you just made another lie in pubic.
> 
> The question is: should it?  It is a lie that where to put files was an
> issue in getting gnc implemented on Windows.
> 
You do like misinterpreting other peoples words to your benefit...

I never said it was a requirement to get gnc implemented on Windows. I said 
gnucash chose to better integrate with each platform.

And please re-read my other message. We're talking in different contexts. You 
continue to discuss on the level of what should be considered metadata and 
what should be part of the gnucash data itself. I'm only talking default 
metadata locations itself as that's the only aspect in this context that has 
changed in gnucash 3.x. That some data should not be considered metadata is 
not under debate. We agree on that.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 12:54:35 CET schreef Wm via gnucash-devel:
> On 24/02/2019 02:25, David Cousens wrote:
> > Wm,
> 
> David, I appreciate your efforts as peacemaker, don't give up on all of
> us yet, most of us are trying to be good, promise :)
> 
> > If you draw a diagram from the information in the wiki page
> > https://wiki.gnucash.org/wiki/Configuration_Locations
> > where the  meta data and report data is stored becomes fairly obvious and
> > is fairly simple.
> 
> I disagree, the user doesn't always know where their stuff is and
> therefore can't make a sensible backup.  We (gnc) have a theory about
> where stuff should be but in practice it could be just about anywhere.
> 
> My argument is that we should put important stuff near or approximate to
> the data it relates to rather than further away from it.
> 
> > There was considerable discussion in the forums at the time the changes
> > were being made from 2.6 to 3.0.
> 
> Not all views were heard.  Taking a poll and not listening to the views
> that disagree with you is ordinary.
> 
> This has ended up with me saying Geert (a person I respect enormously)
> may be a liar :(
> 
Sigh...

Let it be clear the current thread is mixing up several discussions.

1. I agree (and always have) that certain data (like saved reports) is stored 
in the wrong place, namely in the metadata directory instead of in the gnucash 
data file. This has been historically so and hasn't changed between gnucash 
2.6 and 3. The same data is still stored in locations reserved for application 
internal housekeeping (metadata).

2. In the preparations to line up to gnucash 3 I decided to do some lower 
level housekeeping, namely to move everything that was *already stored* in the 
historical metadata/config directory ($HOME/.gnucash on linux) into present 
day recommended locations per platform ($HOME/.config/gnucash and 
$HOME/.local/share/gnucash on linux). On MacOS this was already the case so 
nothing changed there. On windows the move was from $HOME/.gnucash to 
%APPDATA%\GnuCash, the default location on Windows *and* a request by several 
users that didn't like the .gnucash in their $HOME. It was never my aim at 
that point to do the bigger cleanup of sorting out which stuff that was in 
separate metadata files should really be moved into the gnucash data file. 
That's a completely different work that should still happen somewhere further 
down in the current big refactoring.

In further discussions, let's try to be clear please about what aspect is 
being discussed.

Regards,

Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 03:12, David Cousens wrote:

Wm

You could have a startup script which copied a common user config file for
GnuCash from a backup or other central location to each users home directory
and then copied it back on exit.

On Linux the files would be those in the directories:

/home//.local/share/gnucash  (all user data)
/home//.config/gnucash  (gnucash config data)
/home//.local/share/gtk-3.0(gtk data)
/home//.config/gtk-3.0   (gtk config)

On Windows they should be in

c:\Users\\AppData\Local\GnuCash or
c:\Users\\AppData\Local\gtk-3.0

OR

c:\Users\\AppData\Roaming\GnuCash
c:\Users\\AppData\Roaming\gtk-3.0

Don't know enough about Windoze anymore to know which set is most likely to
be used but this link has an explanation
https://www.makeuseof.com/tag/appdata-roaming-vs-local/

If you only wanted to back up the reports not just all user data, you could
just backup the
saved-reports-. from the requisite directories and just restore that
file from a backup or other central copy stored with the main book file.


It is a lot more complicated than you think.

Let me open this part of the discussion by saying:

Does gnc know where it took stuff from and placed it when 3.x was run 
for the first time?


We know this was a one way change but were the from and to locations 
known about and recorded?


I think they weren't all known about and recorded and gnc has 
contributed to actual data loss. <-- not something I ever wanted to say 
as this was warned about and avoidable.  The warnings were ignored.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-24 Thread Colin Law

On Sun, 24 Feb 2019 at 15:21, Wm via gnucash-devel
 wrote:
>
> That is the point, dear, you may not have said a swearword but what you
> are supporting is shameful.

Please don't call me dear.  That is almost as bad as labelling me a
Trump supporter.
I don't understand what it is you think I am supporting, all I am
supporting here is gnucash and civility.

Colin
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 01:06, David Carlson wrote:

No, it is the name calling and digression from real subject matter.


I had to do the name calling because no-one was paying attention.


I'd prefer it if I was listened to the first time, promise.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 09:19, Colin Law wrote:

On Sat, 23 Feb 2019 at 23:28, Wm via gnucash-devel
 wrote:

...
You, Colin Law, seem to be the sort of person that votes for Trump
because you aren't bothered if a black women gets shot.


I fail to see what I have done to be so vilely abused as to be accused
of being a Trump supporter or being a racist.


If you are neither you have nothing to be afraid of.


Also I fail to see what I said that so angered you.  I merely
expressed surprise that you use Gnucash when you have such a low
opinion of the developers.  How you can trust their work to look after
your financial data when you consider them so incompetent I don't
know.


I have a good understanding of the tx gnc works on top of.


As for my desire not to post words that may offend others then that is
why I do it, so as not to offend.  I have grandchildren and if they
should happen to google my name and come up with my posts I would not
want to be ashamed of what I have written.  Some obviously are not
worried about offending others.


That is the point, dear, you may not have said a swearword but what you 
are supporting is shameful.  I, unlike you, will have the pride of going 
to my grave honest and expressive.



There aren't that many people like you out there, Colin Law, and you
should let this community know which side you are on.


Which side of what?


Good accounting for people.

--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 08:44, Geert Janssens wrote:


Yes, unfortunately this isn't very user friendly. I'm sure it can be improved.
Again it requires someone with time available and coding experience to
implement it.


Not really, 2. was better than 3. in this regard; let's just go back is 
my suggestion.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 08:44, Geert Janssens wrote:


Completely agree in today's context. There have been reasons in the past it
was done as it is. If someone has spare time and epxerience I gladly accept
patches to fix this technical debt.


There was nothing to fix in this regard in gnc 2.x

gnc 3.x changed things, do *not* try and escape this, Geert!

gnc 3.x made things worse not better in this regard.  Understand?


The fact that we even need a wiki page dedicated to file and configuration
locations-- let alone one as long and convoluted as the one we have (and
which needs additional diagramming)-- only underscores this problem.


No, it underscores the dev team's willingness to be as open as possible about
the complexities of a mature cross-platform application. Many applications
store (meta)data is locations defined by the context. 


I know what you are saying, Geert, you are also wrong.  The 
implementation of those concepts in gnc 3.x is a disaster for some, e.g 
I have charities that cannot use gnc 3.x


I must ask again, because I do not want to shoot the messenger, who 
thought this change from 2.x to 3.x was a good idea?  Who proposed it? 
Did the person that proposed it understand what they were suggesting 
meant for all people or just for themselves?


This change is fundamentally wrong to what I understand the gnc ethos to 
be.  People should have access to their own data, people should control 
their own data, people's data should be where they expect it to be.


Geert, the way you are talking it sounds like you voted for Facebook.


Go search for
libreoffice's metadata for example, or firefox'. If you would want to document
their metadata structures, you'd see something similar or even more complex.


I know both those programs and know where they store stuff.  You may 
recall I mentioned portableapps.com a while ago so don't be surprised 
/someone else knows about where other apps put stuff.


In short, documenting metdata structures about gnc is mainly done.  So 
shut up and do something useful, please.



Part of the complexity comes from the multi-platform nature of gnucash. Each
platform defines their own default locations for various kinds of data. And
gnucash tries to apply these per platform.


Geert: I think you just made another lie in pubic.

The question is: should it?  It is a lie that where to put files was an 
issue in getting gnc implemented on Windows.


gnucash should be thinking for itself.

if you go for the "each platform says where things should go" I will 
have access to your file and you will have access to mine in one years time.


Try using your fucking brain for independent thought once!


I want to be clear that I am truly grateful that Chris has decided to work
on reports, and I have great respect for his ability to work with Scheme.
I've yet to succeed in either editing an existing report or getting a third
party report installed on my Mac. 13 years of futility on that front!


Yes, unfortunately this isn't very user friendly. I'm sure it can be improved.
Again it requires someone with time available and coding experience to
implement it.


There is no person with coding experience available, get used to it. 
Move on.


I also notice that I am being told to move on, who do you think is right 
or wrong, Geert?



--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 10:45, David T. via gnucash-devel wrote:

Adrien,
Using configuration files as a mechanism for working around the significant 
shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To 
be clear, I understand the challenges facing the team-- as well as accept that 
I am unable to effect change in these areas.  Nevertheless, I am disinclined to 
paper over these shortcomings by accepting such workarounds.

Furthermore, as I understand it, saved reports use the GUID of an account to 
refer to them, so any attempts at using a saved report from one file in another 
is likely doomed to fail.


Yup.  The transference is a specious argument.  Whoever thought it was a 
good idea was, quite simply wrong, or, at the very least, doesn't or 
didn't understand how gnc's reports work.



Or perhaps you're talking about settings associated with the standard reports? 
I profess I do not know how settings for these are stored-- although the fact 
that they are not stored with the actual saved reports (like the saved reports 
themselves) simply underscores the piecemeal mechanisms used for the reports.


I've no clue about this future mechanism, I want the existing one to work.


Your points about multiple user access are a red herring.  Since Gnucash 
doesn't support multiple users, there's no point in speculating on how we might 
circumvent this limitation.


Yay, David.T gets my vote!

I have a lot of ideas about gnc being multiuser but I'm not suggesting 
they break what we have.



Gnucash does, however, support one user having multiple data files, and in this 
case, a user opening file B will see all the (useless) saved reports for file A.


Waves!


Finally, the points originally raised regarding the scattershot storage of data 
that are integral to a set of books (whether reports, settings, or other data) 
remain.


Get elected, David! :)

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 09:11, Geert Janssens wrote:

Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens:

Adrien,

You beat me to it. I was about to also suggest making it a user preference
to be able to store the report configurations either with the book or as a
user location. Then the user could choose what suits their circumstances and
configuration.

David Cousens


Well, for me each reference to "a new user preference" triggers the question
"can't we solve it in another way".


I don't think we can solve this easily, Geert.

is there a way?  Yes.
Is there another way? Always.
Is there a good or right way?  Yes.


For starters the user preference is an all or nothing thing, either all
reports are in a book or in a common location. 


This simply is not true, Geert, I don't understand why you, who I 
respect so much, would say this when it is not true.



That's not very fine-grained.
Perhaps you consider some reports common and some reports book-specific. This
could be solved by making it a per report option of course.


Yes.


It also doesn't solve the issue of sharing those common reports with other
users (like your accountant).


My accountant is me, I am also other people's accountant.  I don't lie 
about money.


To some extent Geert is making a jurisdictional argument, major 
commercial accounting applications are failing to provide what 
governments want.  I think

Reports / Tax Schedule etc
should be removed for incompetence and trial balance reporting improved.


And yet another issue: reports are only suitable for multiple books if these
books have the exact same base as required per report. 


Yup, therefore it makes no sense for the reports to be stored per user. 
Do we know who came up with this stupid idea yet?



take the transaction report. The user selects a set of
transactions to display. Now suppose you select some accounts that are
exclusively to this particular book. If you save this preset, and use it in
another book that doesn't have these accounts there will be an issue.


Geert, the saved report will most likely be useless with another book.

Who was the fucking idiot that decided to use one set of saved reports?
Tell us that, please!  Be a man, Geert.


I
haven't tested, though at best the account is ignored, at worst the report
throws errors. That's the best scenario. The other way around is worse:
suppose you saved the report configuration with all asset accounts selected in
one book. You then try to use this report on a  book that has an additional
asset account. As this account is not part of the initial selection it won't
appear in the transaction report in the second book. Of course for a
transaction report it's fairly easy to spot. There are other reports where
this is much more subtle though. And this is not limited to account selections
though I suspect that's the most important one.


I'm seeing support for my concept, I like someone that thinks things 
through, eventually.



So my conclusion is that report configurations are essentially book specific
and should be treated as such to avoid unexpected accounting mistakes.


Yes.


On the other hand I understand it takes time to carefully configure reports to
your preference and there's a wish to reuse this effort across books.


That is easy, you just copy and paste a file.  I have no time for cheap 
and lazy accountants that want to charge people lots of money for little 
work.



I have done this thought exercise in the past. At that time the best I could
come up with was to provide gui functions to manage report presets. In
particular some form of import/export functionality. The configurations would
remain per book. But one could explicitly export a configuration from one book
and import it in another.


My problem, Geert, is why you allowed what we have now to happen. 
Surely you, a respected person, a monitor, should have noticed it was 
wrong when the 2.x to 3.x code was settling in?


I *did* talk about this!  You (pural) ignored me at the time.


It's not ideal as it doesn't solve the subtle errors issue. The user will
still have to verify the imported configuration works for the book it's
imported in. Improving on that will require smarter report options (like ways
to specify "select all asset accounts" or "select all children from account
xyz" instead of a dumb list of account ids). I'm pretty sure that would
increase internal option complexity a lot and I'm not convinced the benefit in
this case is worth the trouble.


Geert, I don't get the complexity you're describing.  If something 
ordinary that involves money happens in my life I add an account for 
that, this is how accounting is meant to work.


You seem to think adding an account is something to be thought about by 
a panel of wise men and women, that isn't how modern accounting works.



All brainstorming of course. No implementation in sight...


Why no implementation change?  The retrograde step happened in 2.x to 3.x

--
Wm

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 04:05, David Cousens wrote:

Adrien,

You beat me to it. I was about to also suggest making it a user preference
to be able to store the report configurations either with the book or as a
user location. Then the user could choose what suits their circumstances and
configuration.


If the default was near or with the book I'd run with that.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 03:44, Adrien Monteleone wrote:

One might want the same configuration in many respects and the same options on 
various reports to be ’saved’ (since there is no other way to accomplish this 
task) as user configured defaults to be useful across various books.

Some people have separate files for many entities and they shouldn’t have to 
re-create all of that work for each one. You might always want to roll up child 
totals to the parent or not show zero balance accounts for example, regardless 
of the entity you are running reports for. Your accountant might always want to 
see reports following a certain format, different from the GnuCash defaults, 
regardless of the entity.

But I also see the case where multiple users might access the same data file 
and you’d want them all to have the same configuration for the book options and 
a standard set of reports to be able to run.

Certainly, there is room for improvement for a multi-user environment. (which 
GnuCash does not officially support at present from my understanding)

Perhaps the user environment itself should be an option which would determine 
where the various configurations are stored. (or more likely, how they are 
stored, as they should probably all be located *with* the data file, though not 
necessarily a part of it.)

Another option, specific to reports would be the ability to create a ‘custom 
default’ set of options. This would allow the creation of new books without 
having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd 
to some, but think of this more like a ’template’.)



I think I understand "custom default" and it is not absurd.  You are (I 
think) saying that a book / file / set of transactions / whatever should 
be associated with the reports that are particular to it.


I also accept what you say about duplicating a configuration.  That 
should just be a process of finding the right files, copying them to a 
new place and ... begin!


We can't do that at the moment because someone decided to hide the 
important bits relative to a file and put them in a place that will be 
different for *every* person on *every* computer.


If I was a conspiracy theorist I'd say someone at gnc HQ was not acting 
in the interest of the people.


--
Wm



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 02:53, David T. via gnucash-devel wrote:


While I take exception to Wm's tone and language, I agree with his overall 
assessment of the reports and configuration management.


I am happy to apologize to you if someone eventually takes notice.  I 
will do this by paying for a meal if we ever meet in person.



Storing configuration data separately from the financial data and on a user (as 
opposed to a book) basis is questionable.


Yup.


Storing saved reports separately from the financial data and on a user basis 
makes no sense at all. A saved report for one file will be meaningless in 
another. This issue has come up many times on the lists.


Yup.


The fact that we even need a wiki page dedicated to file and configuration 
locations-- let alone one as long and convoluted as the one we have (and which 
needs additional diagramming)-- only underscores this problem.


I don't think the person that wrote the page understood what they were 
describing.  I am sure they were doing their best.



I want to be clear that I am truly grateful that Chris has decided to work on 
reports, and I have great respect for his ability to work with Scheme. I've yet 
to succeed in either editing an existing report or getting a third party report 
installed on my Mac. 13 years of futility on that front!

David T.


I second that, the fact that a diminishing handful of people can read 
Scheme is interesting, it isn't a progressive language, the fact that 
gnc is dependent on it is regressive.


I have made some small changes to a gnc Scheme report for my own 
purposes but when I put them forward for inclusion they were refused. 
Presumably because the person that needed to approve them didn't 
understand them.  The thing I worked out was how to do "end of next 
month" and similar for reports.


Sigh

David, I am always unhappy if I upset someone, I often find myself in 
the situation of not knowing what else to do as no one listened the 
first time.


--
Wm





___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 24/02/2019 02:25, David Cousens wrote:

Wm,


David, I appreciate your efforts as peacemaker, don't give up on all of 
us yet, most of us are trying to be good, promise :)



If you draw a diagram from the information in the wiki page
https://wiki.gnucash.org/wiki/Configuration_Locations
where the  meta data and report data is stored becomes fairly obvious and is
fairly simple.


I disagree, the user doesn't always know where their stuff is and 
therefore can't make a sensible backup.  We (gnc) have a theory about 
where stuff should be but in practice it could be just about anywhere.


My argument is that we should put important stuff near or approximate to 
the data it relates to rather than further away from it.



There was considerable discussion in the forums at the time the changes were
being made from 2.6 to 3.0.


Not all views were heard.  Taking a poll and not listening to the views 
that disagree with you is ordinary.


This has ended up with me saying Geert (a person I respect enormously) 
may be a liar :(



Not all users had the same report startegy you
were thinking of. Some users used the same report configurations with
different books. 


That breaks if you have more than one book and those books have more 
than one set of customers (we're all customers of gnc now, right?).


I think what you are saying is a tiny minority of self interested people 
overrode the real interest regarding where reports should be stored 
because it was convenient to them.


If you (or anyone reading this) actually understands how gnc stores 
reports, how it saves them and where it saves them it makes no sense to 
put them in the weird general space that MS and other OS expect them to 
be in.


Yah boo.  Someone further up the chain than you or I believed something 
they were told and forgot about accounting.



Going with the OS's recommendations has the advantage that
your backup strategy may be more general than that for a single app.


That means (yes, I am pushing buttons) you agree with the MS view that 
all your data is ours?



Note it is the report configuration which is saved in the configuration
locations not the report instance itself - that is in the book/main data
file 


wrong, the report is not in the book/main data file.

I am stating a fact, DavidC, you may believe it is there but it isn't

and/or reconstructed from the data there when it is displayed.

Nominally, yes.

You are avoiding two important issues:

1. the report configuration file belongs to an account file; do you 
understand this?  you can't apply my Balance Sheet report against your 
file and expect it to work, vice versa your Balance Sheet, we have 
different accounts!  surely this is obvious?


2. the file / book / whatever doesn't know where the reports are, i have 
 very good understanding of the formats involved and I'm telling you 
for free, your accounting data, as stored by gnc at present, has no 
fucking clue where anything else that you consider significant about it 
is stored.


i.e. it is a fucking mess because one of the options available was for 
the file / book to know where it's meta data was.



It is fairly simple to store a copy of user and configuarion locations
contents with each data file if you really require the user and config data
to be backed up along with the data file.


It should be fairly simple but isn't.

gnc has made a presumption about a user.  if you are that user it will 
be OK, if you aren't you're fucked.


David, keep going, please, if you think I'm bad read what I am actually 
saying.


--
Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-24 Thread David T. via gnucash-devel

Adrien,
Using configuration files as a mechanism for working around the significant 
shortcomings of the reports ecosystem in Gnucash is tortured logic, at best. To 
be clear, I understand the challenges facing the team-- as well as accept that 
I am unable to effect change in these areas.  Nevertheless, I am disinclined to 
paper over these shortcomings by accepting such workarounds.

Furthermore, as I understand it, saved reports use the GUID of an account to 
refer to them, so any attempts at using a saved report from one file in another 
is likely doomed to fail. 

Or perhaps you're talking about settings associated with the standard reports? 
I profess I do not know how settings for these are stored-- although the fact 
that they are not stored with the actual saved reports (like the saved reports 
themselves) simply underscores the piecemeal mechanisms used for the reports. 

Your points about multiple user access are a red herring.  Since Gnucash 
doesn't support multiple users, there's no point in speculating on how we might 
circumvent this limitation.  

Gnucash does, however, support one user having multiple data files, and in this 
case, a user opening file B will see all the (useless) saved reports for file A.

Finally, the points originally raised regarding the scattershot storage of data 
that are integral to a set of books (whether reports, settings, or other data) 
remain.  

David T. 

  On Sun, Feb 24, 2019 at 9:14, Adrien 
Monteleone wrote:   One might want the same 
configuration in many respects and the same options on various reports to be 
’saved’ (since there is no other way to accomplish this task) as user 
configured defaults to be useful across various books.

Some people have separate files for many entities and they shouldn’t have to 
re-create all of that work for each one. You might always want to roll up child 
totals to the parent or not show zero balance accounts for example, regardless 
of the entity you are running reports for. Your accountant might always want to 
see reports following a certain format, different from the GnuCash defaults, 
regardless of the entity.

But I also see the case where multiple users might access the same data file 
and you’d want them all to have the same configuration for the book options and 
a standard set of reports to be able to run.

Certainly, there is room for improvement for a multi-user environment. (which 
GnuCash does not officially support at present from my understanding)

Perhaps the user environment itself should be an option which would determine 
where the various configurations are stored. (or more likely, how they are 
stored, as they should probably all be located *with* the data file, though not 
necessarily a part of it.)

Another option, specific to reports would be the ability to create a ‘custom 
default’ set of options. This would allow the creation of new books without 
having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd 
to some, but think of this more like a ’template’.)

Regards,
Adrien

> On Feb 23, 2019, at 8:53 PM, David T. via gnucash-devel 
>  wrote:
> 
> Storing configuration data separately from the financial data and on a user 
> (as opposed to a book) basis is questionable.
> 
> Storing saved reports separately from the financial data and on a user basis 
> makes no sense at all. A saved report for one file will be meaningless in 
> another. This issue has come up many times on the lists. 
> 
> The fact that we even need a wiki page dedicated to file and configuration 
> locations-- let alone one as long and convoluted as the one we have (and 
> which needs additional diagramming)-- only underscores this problem. 
> 
> I want to be clear that I am truly grateful that Chris has decided to work on 
> reports, and I have great respect for his ability to work with Scheme. I've 
> yet to succeed in either editing an existing report or getting a third party 
> report installed on my Mac. 13 years of futility on that front!
> 
> David T. 
> 

___
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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-24 Thread Colin Law

On Sat, 23 Feb 2019 at 23:28, Wm via gnucash-devel
 wrote:
> ...
> You, Colin Law, seem to be the sort of person that votes for Trump
> because you aren't bothered if a black women gets shot.

I fail to see what I have done to be so vilely abused as to be accused
of being a Trump supporter or being a racist.

Also I fail to see what I said that so angered you.  I merely
expressed surprise that you use Gnucash when you have such a low
opinion of the developers.  How you can trust their work to look after
your financial data when you consider them so incompetent I don't
know.

As for my desire not to post words that may offend others then that is
why I do it, so as not to offend.  I have grandchildren and if they
should happen to google my name and come up with my posts I would not
want to be ashamed of what I have written.  Some obviously are not
worried about offending others.

>
> There aren't that many people like you out there, Colin Law, and you
> should let this community know which side you are on.

Which side of what?

Colin
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 05:05:21 CET schreef David Cousens:
> Adrien,
> 
> You beat me to it. I was about to also suggest making it a user preference
> to be able to store the report configurations either with the book or as a
> user location. Then the user could choose what suits their circumstances and
> configuration.
> 
> David Cousens

Well, for me each reference to "a new user preference" triggers the question 
"can't we solve it in another way".

For starters the user preference is an all or nothing thing, either all 
reports are in a book or in a common location. That's not very fine-grained. 
Perhaps you consider some reports common and some reports book-specific. This 
could be solved by making it a per report option of course.

It also doesn't solve the issue of sharing those common reports with other 
users (like your accountant).

And yet another issue: reports are only suitable for multiple books if these 
books have the exact same base as required per report. An example to clarify 
what I mean: take the transaction report. The user selects a set of 
transactions to display. Now suppose you select some accounts that are 
exclusively to this particular book. If you save this preset, and use it in 
another book that doesn't have these accounts there will be an issue. I 
haven't tested, though at best the account is ignored, at worst the report 
throws errors. That's the best scenario. The other way around is worse: 
suppose you saved the report configuration with all asset accounts selected in 
one book. You then try to use this report on a  book that has an additional 
asset account. As this account is not part of the initial selection it won't 
appear in the transaction report in the second book. Of course for a 
transaction report it's fairly easy to spot. There are other reports where 
this is much more subtle though. And this is not limited to account selections 
though I suspect that's the most important one.

So my conclusion is that report configurations are essentially book specific 
and should be treated as such to avoid unexpected accounting mistakes.

On the other hand I understand it takes time to carefully configure reports to 
your preference and there's a wish to reuse this effort across books.

I have done this thought exercise in the past. At that time the best I could 
come up with was to provide gui functions to manage report presets. In 
particular some form of import/export functionality. The configurations would 
remain per book. But one could explicitly export a configuration from one book 
and import it in another.

It's not ideal as it doesn't solve the subtle errors issue. The user will 
still have to verify the imported configuration works for the book it's 
imported in. Improving on that will require smarter report options (like ways 
to specify "select all asset accounts" or "select all children from account 
xyz" instead of a dumb list of account ids). I'm pretty sure that would 
increase internal option complexity a lot and I'm not convinced the benefit in 
this case is worth the trouble.

All brainstorming of course. No implementation in sight...

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Op zondag 24 februari 2019 03:53:52 CET schreef David T. via gnucash-devel:
> While I take exception to Wm's tone and language, I agree with his overall
> assessment of the reports and configuration management.
> 
> 
> Storing configuration data separately from the financial data and on a user
> (as opposed to a book) basis is questionable. 
> 
> Storing saved reports separately from the financial data and on a user basis
> makes no sense at all. A saved report for one file will be meaningless in
> another. This issue has come up many times on the lists. 
> 
Completely agree in today's context. There have been reasons in the past it 
was done as it is. If someone has spare time and epxerience I gladly accept 
patches to fix this technical debt.

> The fact that we even need a wiki page dedicated to file and configuration
> locations-- let alone one as long and convoluted as the one we have (and
> which needs additional diagramming)-- only underscores this problem. 
> 
No, it underscores the dev team's willingness to be as open as possible about 
the complexities of a mature cross-platform application. Many applications 
store (meta)data is locations defined by the context. Go search for 
libreoffice's metadata for example, or firefox'. If you would want to document 
their metadata structures, you'd see something similar or even more complex.
Part of the complexity comes from the multi-platform nature of gnucash. Each 
platform defines their own default locations for various kinds of data. And 
gnucash tries to apply these per platform.

> I want to be clear that I am truly grateful that Chris has decided to work
> on reports, and I have great respect for his ability to work with Scheme.
> I've yet to succeed in either editing an existing report or getting a third
> party report installed on my Mac. 13 years of futility on that front!

Yes, unfortunately this isn't very user friendly. I'm sure it can be improved. 
Again it requires someone with time available and coding experience to 
implement it.

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Adrien,

You beat me to it. I was about to also suggest making it a user preference
to be able to store the report configurations either with the book or as a
user location. Then the user could choose what suits their circumstances and
configuration.

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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-23 Thread Adrien Monteleone

One might want the same configuration in many respects and the same options on 
various reports to be ’saved’ (since there is no other way to accomplish this 
task) as user configured defaults to be useful across various books.

Some people have separate files for many entities and they shouldn’t have to 
re-create all of that work for each one. You might always want to roll up child 
totals to the parent or not show zero balance accounts for example, regardless 
of the entity you are running reports for. Your accountant might always want to 
see reports following a certain format, different from the GnuCash defaults, 
regardless of the entity.

But I also see the case where multiple users might access the same data file 
and you’d want them all to have the same configuration for the book options and 
a standard set of reports to be able to run.

Certainly, there is room for improvement for a multi-user environment. (which 
GnuCash does not officially support at present from my understanding)

Perhaps the user environment itself should be an option which would determine 
where the various configurations are stored. (or more likely, how they are 
stored, as they should probably all be located *with* the data file, though not 
necessarily a part of it.)

Another option, specific to reports would be the ability to create a ‘custom 
default’ set of options. This would allow the creation of new books without 
having to 'remake the wheel’. (I understand ‘custom default’ may sound absurd 
to some, but think of this more like a ’template’.)

Regards,
Adrien

> On Feb 23, 2019, at 8:53 PM, David T. via gnucash-devel 
>  wrote:
> 
> Storing configuration data separately from the financial data and on a user 
> (as opposed to a book) basis is questionable.
> 
> Storing saved reports separately from the financial data and on a user basis 
> makes no sense at all. A saved report for one file will be meaningless in 
> another. This issue has come up many times on the lists. 
> 
> The fact that we even need a wiki page dedicated to file and configuration 
> locations-- let alone one as long and convoluted as the one we have (and 
> which needs additional diagramming)-- only underscores this problem. 
> 
> I want to be clear that I am truly grateful that Chris has decided to work on 
> reports, and I have great respect for his ability to work with Scheme. I've 
> yet to succeed in either editing an existing report or getting a third party 
> report installed on my Mac. 13 years of futility on that front!
> 
> David T. 
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Wm

You could have a startup script which copied a common user config file for
GnuCash from a backup or other central location to each users home directory
and then copied it back on exit. 

On Linux the files would be those in the directories:

/home//.local/share/gnucash  (all user data)
/home//.config/gnucash  (gnucash config data)
/home//.local/share/gtk-3.0(gtk data)
/home//.config/gtk-3.0   (gtk config)

On Windows they should be in

c:\Users\\AppData\Local\GnuCash or
c:\Users\\AppData\Local\gtk-3.0

OR

c:\Users\\AppData\Roaming\GnuCash
c:\Users\\AppData\Roaming\gtk-3.0

Don't know enough about Windoze anymore to know which set is most likely to
be used but this link has an explanation
https://www.makeuseof.com/tag/appdata-roaming-vs-local/

If you only wanted to back up the reports not just all user data, you could
just backup the 
saved-reports-. from the requisite directories and just restore that
file from a backup or other central copy stored with the main book file.

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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-23 Thread David T. via gnucash-devel

While I take exception to Wm's tone and language, I agree with his overall 
assessment of the reports and configuration management.


Storing configuration data separately from the financial data and on a user (as 
opposed to a book) basis is questionable. 

Storing saved reports separately from the financial data and on a user basis 
makes no sense at all. A saved report for one file will be meaningless in 
another. This issue has come up many times on the lists. 

The fact that we even need a wiki page dedicated to file and configuration 
locations-- let alone one as long and convoluted as the one we have (and which 
needs additional diagramming)-- only underscores this problem. 

I want to be clear that I am truly grateful that Chris has decided to work on 
reports, and I have great respect for his ability to work with Scheme. I've yet 
to succeed in either editing an existing report or getting a third party report 
installed on my Mac. 13 years of futility on that front!

David T. 

 
 
  On Sun, Feb 24, 2019 at 7:55, David Cousens wrote:  
 Wm,

If you draw a diagram from the information in the wiki page
https://wiki.gnucash.org/wiki/Configuration_Locations
where the  meta data and report data is stored becomes fairly obvious and is
fairly simple. 

There was considerable discussion in the forums at the time the changes were
being made from 2.6 to 3.0. Not all users had the same report startegy you
were thinking of. Some users used the same report configurations with
different books. Going with the OS's recommendations has the advantage that
your backup strategy may be more general than that for a single app.

Note it is the report configuration which is saved in the configuration
locations not the report instance itself - that is in the book/main data
file and/or reconstructed from the data there when it is displayed.

It is fairly simple to store a copy of user and configuarion locations
contents with each data file if you really require the user and config data
to be backed up along with the data file.

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
  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Wm,

If you draw a diagram from the information in the wiki page
https://wiki.gnucash.org/wiki/Configuration_Locations
where the  meta data and report data is stored becomes fairly obvious and is
fairly simple. 

There was considerable discussion in the forums at the time the changes were
being made from 2.6 to 3.0. Not all users had the same report startegy you
were thinking of. Some users used the same report configurations with
different books. Going with the OS's recommendations has the advantage that
your backup strategy may be more general than that for a single app.

Note it is the report configuration which is saved in the configuration
locations not the report instance itself - that is in the book/main data
file and/or reconstructed from the data there when it is displayed.

It is fairly simple to store a copy of user and configuarion locations
contents with each data file if you really require the user and config data
to be backed up along with the data file.

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

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-23 Thread Chris Good

Message: 5
Date: Sat, 23 Feb 2019 16:30:58 -0600 (CST)
From: David Cousens 
To: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] GnuCash 3 on Linux
Message-ID: <1550961058473-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii

Chris,

If I save reports from GnuCash 3.4 on Linux Mint Tara (Ubuntu 18.04), the
reports are saved in
/home//.local/share/gnucash/saved-reports-2.8 and I have verified this
contains the report config which I saved.

This is where I expected to find them based on the description in
https://wiki.gnucash.org/wiki/Configuration_Locations.

I am not sure what the 2.4 in your case and 2.8 in my case actually refer
to. The wiki says  they are related to GnuCash versions but not obviously
the version which is running. 

David Cousens

Hi David,

Geert answered this 6/6/2018:

2.8, not 2.4. If not 2.8 file is found, gnucash 3 and up will search for a
saved-reports-2.4, but it will only save to saved-reports-2.8.

I haven't updated the wiki as it was recently changed to say:
saved-reports-x.y
presumably to ensure it doesn't quickly become outdated.

Personally, I would prefer if it was more specific.

I am finally about to release my BackupGnuCash java app 1.3.0, now updated
for GnuCash 3.
As it is difficult to tell if a configuration file location has been
overridden by an environment variable somewhere, I've taken the tack of only
looking for configuration files to backup in the default locations.

Regards,
Chris Good

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-23 Thread David Carlson

No, it is the name calling and digression from real subject matter.

On Sat, Feb 23, 2019, 6:26 PM Wm via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> On 23/02/2019 23:09, David Carlson wrote:
> > Obviously this is not worth reading
>
> Why? it is all about people presuming placement of significant personal,
> charitable and corporate assets and getting it wrong.
>
>
> Why is that not worth reading?
>
>
>
> ___
> 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

Re: [GNC-dev] GnuCash 3 on Linux


On 23/02/2019 23:09, David Carlson wrote:

Obviously this is not worth reading


Why? it is all about people presuming placement of significant personal, 
charitable and corporate assets and getting it wrong.



Why is that not worth reading?



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 23/02/2019 21:52, Colin Law wrote:

I cannot understand why you keep using this software since it is so
obviously horribly flawed and you have such a low opinion of the
developers.

I am sure you would be a much happier person if you used one of the
many alternatives that are conveniently available.

Surely anyone who keeps using it is just encouraging these ne'r do
well developers to carry on in their recalcitrant ways and you really
owe it to yourself to stop using it in order to show how disgusted you
are.  That'll show the F***Ts won't it.


Let's examine your inability to say fuck and how that affects your 
accounting.


You can check real sources (I don't do fake news, and you appear to be 
Trump fodder) or take it from me that people that swear or otherwise 
express themselves are generally happier than those that don't.


You, Colin Law, appear to be the sort of person that would lie or cover 
up something if you saw it, I'm the other sort of person.


That is why I like gnc, why do you use it?

You, Colin Law, seem to be the sort of person that votes for Trump 
because you aren't bothered if a black women gets shot.


There aren't that many people like you out there, Colin Law, and you 
should let this community know which side you are on.


There are, in truth, very few developers and they are diminishing.  It 
is possible the project could die.


My data is safe because I understand accounting and can move on. Can you 
Colin Law?


--
Wm



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-23 Thread David Carlson

Obviously this is not worth reading

On Sat, Feb 23, 2019 at 3:38 PM Wm via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> On 05/06/2018 13:53, Chris Good wrote:
> > Hi,
>
> Hello, Chris
>
> > I'm working on my BackupGnuCash stand-alone app.
> > I have 2 questions today:
>
> read
> https://wiki.gnucash.org/wiki/Configuration_Locations
> and weep at how bad things have become
>
> The last time i addressed this our idiots in charge were so recalcitrant
> about even considering they'd done a stupid thing I stopped reading the
> gnc lists.
>
> I am glad you, someone I respect, have raised it again.
>
> > 1.
> >
> > I'm a little uncertain about where the saved reports and metadata files
> are
> > in GnuCash 3.0 for Linux.
>
> unfortunately the people that think they know better decided to put them
> where Micrsosoft, etc thought best.  That means it changes at a whim, I
> am angry about this and they don't care.
>
> I cannot make a backup policy for my charitable organizations because
> our cleverer-than-thou FUCKWIT seniors just put stuff where they think
> MS or Linux policy suggests they should go and never actually think for
> themselves.
>
> The files should belong to the book and be closely associated with them.
>
> Our FUCKWITS IN CHARGE decided that the metadata belonged with the user
> not the book, that makes no fucking sense for an accounting file, they
> changed it anyway, gr
>
> > I suspect they are by default:
> >
> > ~/.local/share/gnucash/saved-reports-2.4
> >
> > ~/.local/share/gnucash/books/[BOOK].gnucash.gcm
> >
> > unless overridden by XDG_DATA_HOME.
>
> except you can't rely on those those locations.
>
> See the problem now?
>
> > Can some-one please confirm?
>
> Only thing I can confirm is I don't know where anything is.
>
> > 2.
> >
> > I tried to get version 3 on Linux (Ubuntu 16.04) running to test myself.
>
> that's the easy bit :)
>
> > Thanks in advance,
>
> Waves back.
>
> ___
> 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

Re: [GNC-dev] GnuCash 3 on Linux


On 23/02/2019 21:52, Colin Law wrote:

I cannot understand why you keep using this software since it is so
obviously horribly flawed and you have such a low opinion of the
developers.

I am sure you would be a much happier person if you used one of the
many alternatives that are conveniently available.

Surely anyone who keeps using it is just encouraging these ne'r do
well developers to carry on in their recalcitrant ways and you really
owe it to yourself to stop using it in order to show how disgusted you
are.  That'll show the F***Ts won't it.

Colin


Dear Colin, I think you have actually said something stupid.

Let's fight.

You'll lose because you are wrong.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 23/02/2019 22:30, David Cousens wrote:

Chris,

If I save reports from GnuCash 3.4 on Linux Mint Tara (Ubuntu 18.04), the
reports are saved in
/home//.local/share/gnucash/saved-reports-2.8 and I have verified this
contains the report config which I saved.

This is where I expected to find them based on the description in
https://wiki.gnucash.org/wiki/Configuration_Locations.

I am not sure what the 2.4 in your case and 2.8 in my case actually refer
to. The wiki says  they are related to GnuCash versions but not obviously
the version which is running.


So if you want to back stuff up, what do you back up and are you sure 
you are backing up sufficient to replace or recreate in case of emergency.


I can't do this for my charities because more than one person uses the 
book and I think this is what ChrisG was asking about at the start of 
this thread and what my general moan is.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 23/02/2019 21:52, Colin Law wrote:

I cannot understand why you keep using this software since it is so
obviously horribly flawed and you have such a low opinion of the
developers.

I am sure you would be a much happier person if you used one of the
many alternatives that are conveniently available.

Surely anyone who keeps using it is just encouraging these ne'r do
well developers to carry on in their recalcitrant ways and you really
owe it to yourself to stop using it in order to show how disgusted you
are.  That'll show the F***Ts won't it.


Open projects don't work like that, so no.

Love

Wm


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux


On 10/02/2019 12:28, Geert Janssens wrote:


FTR this code is not written by me. I'm merely reading how it currently works.


good, because I am still angry at the plain stupidity regarding this 
implementation



That aside, it will continue to work as long as the user uses a different name
when copying the file or using File, Save As


Doh!  User has to behave badly to enforce good behavior by programme.

The user *still* won't know where their fucking saved reports are unless 
they search for them!  Possibly on someone else's computer in a network. 
 Or maybe not available at all because they were using a shared laptop 
at a conference and now they're at home.


HOW FUCKING STUPID IS THIS APPROACH?

I honestly can't believe the brains we have available thought this was a 
good idea.


Seriously, I DO NOT KNOW were reports are saved any more.

WHO THE FUCK THOUGHT MYSTERY REPORTS WERE A GOOD IDEA

OWN UP!

WHO THOUGHT THIS WAS A GOOD IDEA?

I AM SO ANGRY ABOUT THIS I WANT A NAME


As there haven't been any complaints so far it looks that's what most people
are doing anyway.


liar, I protested in the user list (I do not call Geert a liar for 
nothing and expect him to be very angry with me in return for using that 
word about him but honesty must prevail)


It is possible Geert didn't see the conversation where I complained 
about this in the user list but I think it unlikely.



I think it would be useful if 2) above was changed so that a new book:id is
generated. Shall I raise a bug?


I don't know. As I said, if the file name is unique there's no need to rely on
the GUID. It looks like it's fairly uncommon to want to use the same file name
for books that are not related.


Happens all the time when I'm debugging stuff.


On the other hand I may also want to simply
copy my existing book to a new location and happen to use File, Save As to do
so. I don't think gnucash can make an assumption that either is right or
wrong.


You lose your reports and meta data when you do that.  Is it your 
intention to lose them?  At the moment you don't have the option.



In itself I think it's too ambiguous/insignificant to create a bug report for
it. 


I disagree, it makes consistent backups on networked systems near 
impossible.



But on the other hand I also think this is something that we could analyze
when we start revising our options/preferences system. On big aspect of this
is evaluating for each setting whether it should be book specific (like book
currency), computer specific (like saved window sizes) or user specific (like
I have no example right now...). The metadata file is really meant to store
computer specific data (though it currently does store more than that...).


SO IF YOU WERE THINKING ABOUT THIS BEFORE WHY DID YOU MAKE SUCH A BAD 
DECISION??


As far as I know you didn't even ask people about this!

What is a book option, what is metadata and so on *has* been discussed 
before and I am going to say *you* Geert are a liar if you think it was 
all new.


I hate dishonest people.

GR

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

Chris,

If I save reports from GnuCash 3.4 on Linux Mint Tara (Ubuntu 18.04), the
reports are saved in
/home//.local/share/gnucash/saved-reports-2.8 and I have verified this
contains the report config which I saved.

This is where I expected to find them based on the description in
https://wiki.gnucash.org/wiki/Configuration_Locations.

I am not sure what the 2.4 in your case and 2.8 in my case actually refer
to. The wiki says  they are related to GnuCash versions but not obviously
the version which is running. 

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

Re: [GNC-dev] GnuCash 3 on Linux

On 08/02/2019 09:04, Chris Good wrote:

-Original Message-
From: Geert Janssens 
Sent: Wednesday, 6 June 2018 12:10 AM
To: gnucash-devel@gnucash.org
Cc: Chris Good 
Subject: Re: [GNC-dev] GnuCash 3 on Linux

Op dinsdag 5 juni 2018 14:53:44 CEST schreef Chris Good:

Hi,

I'm working on my BackupGnuCash stand-alone app.

I have 2 questions today:

1.

I'm a little uncertain about where the saved reports and metadata
files are in GnuCash 3.0 for Linux.

I suspect they are by default:

~/.local/share/gnucash/saved-reports-2.4

  2.8, not 2.4. If not 2.8 file is found, gnucash 3 and up will search for a
saved-reports-2.4, but it will only save to saved-reports-2.8.

~/.local/share/gnucash/books/[BOOK].gnucash.gcm

Yes. Do note it can be [BOOK].gnucash_.gcm if you have several data
files named [BOOK]. And the gnucash part in that file name is only there if
the data file is called [BOOK].gnucash. Older versions of gnucash also
allowed to save to files without extension or with the .xac extension.
So it's really [BOOK-WITH-EXTENSION].gcm

our elders and betters DID NOT THINK THIS THROUGH

unless overridden by XDG_DATA_HOME.

If you override XDG_DATA_HOME the files will be searched for and saved in
$XDG_DATA_HOME/gnucash/

However this can be overridden even with GNC_DATA_HOME. If that's set,
gnucash will search and save in $GNC_DATA_HOME (which may or may not end in
"/gnucash" unlike the XDG_DATA_HOME to which gnucash will always append
"/gnucash")

basically you don't know where anything is, sailor.

Hi Geert,

Thanks very much for the above info.
I'm afraid it has been quite a while since these emails but hopefully now I
have a chance to follow up.

I was surprised to learn about the  part of
[BOOK-WITH-EXTENSION].gcm as I have never seen this.
I did some testing in Windows & Linux and I think I realise now how it
works.

you need to get the secret society part of gnc to document it then.

There is a guid in both the main data file and the metadata .gcm files.
For example,
In main data file:
fe06ec827c69b29977e25a7c6c090229

In .gcm:
BookGuid=fe06ec827c69b29977e25a7c6c090229

So when the metadata is saved, GnuCash looks for (or creates)  a .gcm file
with a BookGuid matching book:id.

It seems that when you create a new book by using File, New, the
subsequently saved main data file has a new book guid created.
However, if you create a new book by either:
1) manually copying a main data file to a different directory and/or
filename
Or
2) using File, Save As
there is no new book:id created so both books will continue to use the same
..gcm file.

Have you spotted the super simple "what files to backup" part yet?

I'm not sure and I really ought to know.

Actually I'm so unsure I'm leaving people on gnc 2.x because at least we 
know where stuff is.

I suspect there may be people who may like to have different settings for
different books but don't because they have created their new book by either
of the 1) or 2) methods above.

Don't confuse their little heads, they went with what the OS people said 
they should do.  Obedience is good.

As the book:id guid only appears once in my main data file, I assume it may
be possible to correct this situation by:
a) save the main data file uncompressed
b) make a minor random(ish) change to the guid using a text editor (do NOT
change the length of the guid)
c) copy the old .gcm to a new .gcm (i.e. copy TEST.gnucash.gcm to
TEST.gnucash_2.gcm)
d) use a text editor to change the old guid to the new guid in the new .gcm

That is all "don't do this unless you know what you are doing" and 
"don't do this at home" stuff.

I'd like to document this in the wiki.
Can you please let me know if I have made any errors in my above assumptions
or forgotten anything important?

I think it unlikely you will be allowed to wiki this because our idiots 
in charge made an executive decision that (for example) reports and 
books don't belong to each other!

Seriously, they need not have a relationship.  Even an invoice format 
(not something that belongs to each user) is now tucked away in each 
users private space making sensible and consistent backups near impossible.

I'm still recovering from the strangeness of that decision and have 
never got a sensible answer back from anyone about why they actually did it.

I think it would be useful if 2) above was changed so that a new book:id is
generated. Shall I raise a bug?

Go for it, bugs sometimes get listened to more than conversations.

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux

2019-02-23 Thread Colin Law

I cannot understand why you keep using this software since it is so
obviously horribly flawed and you have such a low opinion of the
developers.

I am sure you would be a much happier person if you used one of the
many alternatives that are conveniently available.

Surely anyone who keeps using it is just encouraging these ne'r do
well developers to carry on in their recalcitrant ways and you really
owe it to yourself to stop using it in order to show how disgusted you
are.  That'll show the F***Ts won't it.

Colin

On Sat, 23 Feb 2019 at 21:37, Wm via gnucash-devel
 wrote:
>
> On 05/06/2018 13:53, Chris Good wrote:
> > Hi,
>
> Hello, Chris
>
> > I'm working on my BackupGnuCash stand-alone app.
> > I have 2 questions today:
>
> read
> https://wiki.gnucash.org/wiki/Configuration_Locations
> and weep at how bad things have become
>
> The last time i addressed this our idiots in charge were so recalcitrant
> about even considering they'd done a stupid thing I stopped reading the
> gnc lists.
>
> I am glad you, someone I respect, have raised it again.
>
> > 1.
> >
> > I'm a little uncertain about where the saved reports and metadata files are
> > in GnuCash 3.0 for Linux.
>
> unfortunately the people that think they know better decided to put them
> where Micrsosoft, etc thought best.  That means it changes at a whim, I
> am angry about this and they don't care.
>
> I cannot make a backup policy for my charitable organizations because
> our cleverer-than-thou FUCKWIT seniors just put stuff where they think
> MS or Linux policy suggests they should go and never actually think for
> themselves.
>
> The files should belong to the book and be closely associated with them.
>
> Our FUCKWITS IN CHARGE decided that the metadata belonged with the user
> not the book, that makes no fucking sense for an accounting file, they
> changed it anyway, gr
>
> > I suspect they are by default:
> >
> > ~/.local/share/gnucash/saved-reports-2.4
> >
> > ~/.local/share/gnucash/books/[BOOK].gnucash.gcm
> >
> > unless overridden by XDG_DATA_HOME.
>
> except you can't rely on those those locations.
>
> See the problem now?
>
> > Can some-one please confirm?
>
> Only thing I can confirm is I don't know where anything is.
>
> > 2.
> >
> > I tried to get version 3 on Linux (Ubuntu 16.04) running to test myself.
>
> that's the easy bit :)
>
> > Thanks in advance,
>
> Waves back.
>
> ___
> 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

Re: [GNC-dev] GnuCash 3 on Linux


On 05/06/2018 15:09, Geert Janssens wrote:


If you override XDG_DATA_HOME the files will be searched for and saved in
$XDG_DATA_HOME/gnucash/

However this can be overridden even with GNC_DATA_HOME. If that's set, gnucash
will search and save in
$GNC_DATA_HOME (which may or may not end in "/gnucash" unlike the
XDG_DATA_HOME to which gnucash will always append "/gnucash")


it is just a messy breakfast spread across a table rather than on a 
plate, really


nothing is in one place, nothing is where one might expect it.

I am still very angry about this complete fuck up

--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 3 on Linux