Re: Scope of GNUCash

[Matt Graham]

90% agree with you Chris! The last 10% is because Im still yet to try it for 
myself in ledger (probably next weekend).

Since GNUCash doesnt implement them, I am thinking Ill just have links to the 
plain text accounting pages, giving users other reading to do it outside of 
gnucash


Thanks and regards,
Matt


 Original message 
From: Christopher Lam <christopher@gmail.com>
Date: 17/2/18 15:22 (GMT+10:00)
To: gnucash-devel@gnucash.org
Subject: Re: Scope of GNUCash

Hi Matt

Thank you very much for documentation efforts.

FWIW I still prefer virtual transactions which are ridiculously easy to
generate, and to keep up to date. The challenge is not technical, but
it's the mindshare. I've sat through YNAB videos long enough to
understand how it works. It is also a very optional feature that not
everyone needs to use. e.g. I never void transactions nor bother with
clearing balances; for me reconciled balances are sufficient.

Subaccounts will have an unfortunate consequence of being real
transactions in real accounts, which will calculate real balances, need
to match real bank statements, affect real reports.


On 14/02/18 12:46, Matt Graham wrote:
> Not sure why you think I’m one  of the “demanding” people... I’m not actually 
> asking for anything – I’m trying to figure out how this all works, what I 
> really need, and how I can contribute to make it happen I don’t expect 
> anything specific from the core dev group – I just want to fit in with their 
> plans.
>
> I am not sure why you think I’m defining the scope for anyone in these 
> emails I started this thread asking what the scope is (triggered because 
> you keep telling me that all the stuff I’m interested in is out of scope...). 
> I don’t expect to get a say – I just thought there would be something that 
> states it so that I can admit you are right (and stop focussing on that) or 
> get you to stop saying that things people want to do “isn’t what GNUcash is 
> for”. (Note: “We haven’t had time to implement that and probably wont get 
> time” is a very different statement from “we won’t implement that because 
> that isn’t what GNUCash is for”. The former => no worries I’ll help out if I 
> can to get it to happen. Until then, I’ll make do. The latter => No worries, 
> I’ll figure out a way to do it out of GNUCash and I’ll stop asking about it. 
> Again: I’M NOT DEMANDING ANYTHING – I’M TRYING TO UNDERSTAND.
>
> So based on the questions I’m asking you (running around in circles?), I’m 
> pretty confident I’m missing a lot of your points. I’ve read through a lot of 
> the text accounting references you gave me a while ago about budgeting 
> And it all seems pretty much in line with what Chris L and I were talking 
> about ages ago. I was thinking along the lines of envelope budgeting with 
> sub-accounts and tools to help that. Chris was talking about virtual 
> transactions and how that would work. Both are described in various wiki’s 
> and help docs found off the plain text accounting budgeting area: 
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fplaintextaccounting.org%2F%23budgeting=02%7C01%7C%7C6e086cdfd2984fb3c09e08d575be09e6%7C84df9e7fe9f640afb435%7C1%7C0%7C636544381431292259=vgDy3yjfROI78M18qn83rzwvyefWUczMecs48Dfb2XU%3D=0.
>  So if I understand your point, you are saying that I should be exporting my 
> accounts to text, then using another program to implement such a system?
>
>1.  I would rather use GNUCash over the plaintext tools if it is an 
> option. Mainly because of the convenience in layout, display and interaction 
> with my data. GNUCash it already gives somewhere between 70-85% of what I 
> would need/want from the ideal.
>2.  I could spend my time learning the command line tools. or I could 
> spend my time helping out with GNUCash to build in the functionality I want 
> (and evidently lots of other people want – but I don’t say any of this 
> meaning the dev’s should do it for me. I say it to fend off your constant 
> assertion: “that’s not what GNUCash is for!!!”. I’m still confused on what 
> you think GNUCash should be for).
>3.  If I am supposed to export from GNUcash regularly and then import to 
> the command line tool to do stuff I’ll regularly want to do... then why 
> wouldn’t I just use the command line tool for everything? Based on what you 
> say, why do you use GNUCash at all??? What can it do that the command line 
> tools can’t?
>
> For David T: What I’m planning to put into the Tut and Concepts at the moment 
> is a description of how to use sub-accounts for envelope budgeting – Similar 
> to the “Poor Postgrad System” in this link (but for GNUCash): 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmemo.barrucadu.co.uk%2F2018-budget.html=0

Re: Scope of GNUCash

[Matt Graham]

I have always assumed (without purpose or thinking about it) that Gnucash was 
"supposed" to be a "financial management" program, rather than more strictly an 
"accounting" program. So my original question was to clarify which it is 
supposed to be. (And if this has been answered, then I have completely missed 
it... sorry).

However, my question was flawed because the answer doesnt change any action I 
will do . GNUcash is useful to me, so that is enough. For extending out to the 
last 20% of what I want, I can either find a way to do it outside of gnc, or I 
can alter the gnc code to do it. If my stuff is out of scope, then no worries, 
it just wont go in the releases.

Im sorry if any of my posts come across as passive agressive, rude, defensive, 
angry, or demanding. Despite english being my first and only language, I am 
easily misunderstood.

For the tut guide on budgets, Im only putting in an example of how to use 
sub-accounts as virtual breakdowns of their money. So not going to mention 
virtual transactions unless virtual or budget accounts are implemented in 
gnucash (and Im not worried if they are or arent at this point).

If anything in this post sounds arrogant, passive agressive, or demanding, 
please know I didn't mean it that way.



Thanks and regards,
Matt


 Original message 
From: Wm via gnucash-devel <gnucash-devel@gnucash.org>
Date: 17/2/18 01:50 (GMT+10:00)
To: gnucash-de...@lists.gnucash.org
Subject: Re: Scope of GNUCash

On 14/02/2018 04:46, Matt Graham wrote:
> Not sure why you think I’m one  of the “demanding” people... I’m not actually 
> asking for anything – I’m trying to figure out how this all works, what I 
> really need, and how I can contribute to make it happen I don’t expect 
> anything specific from the core dev group – I just want to fit in with their 
> plans.
>
That's a bit passive aggressive, again.

> I am not sure why you think I’m defining the scope for anyone in these 
> emails

How about the headline "Scope of GNUCash" as a clue ?

 > I started this thread asking what the scope is (triggered because you
keep telling me that all the stuff I’m interested in is out of
scope...). I don’t expect to get a say – I just thought there would be
something that states it so that I can admit you are right (and stop
focussing on that) or get you to stop saying that things people want to
do “isn’t what GNUcash is for”.


yes, scope includes time.  if the thing you want is 35 years in the
future you my want to do something nearer now.

 > (Note: “We haven’t had time to implement that and probably wont get
time” is a very different statement from “we won’t implement that
because that isn’t what GNUCash is for”. The former => no worries I’ll
help out if I can to get it to happen. Until then, I’ll make do. The
latter => No worries, I’ll figure out a way to do it out of GNUCash and
I’ll stop asking about it. Again: I’M NOT DEMANDING ANYTHING – I’M
TRYING TO UNDERSTAND.
>

I am saying if you are prepared to wait a decade you might get what you
want.  I'm asking if you are a 10 year person or a 10 month person.

> So based on the questions I’m asking you (running around in circles?), I’m 
> pretty confident I’m missing a lot of your points. I’ve read through a lot of 
> the text accounting references you gave me a while ago about budgeting 
> And it all seems pretty much in line with what Chris L and I were talking 
> about ages ago. I was thinking along the lines of envelope budgeting with 
> sub-accounts and tools to help that. Chris was talking about virtual 
> transactions and how that would work. Both are described in various wiki’s 
> and help docs found off the plain text accounting budgeting area: 
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fplaintextaccounting.org%2F%23budgeting=02%7C01%7C%7C12c69052d26a43da4aca08d5754c98ba%7C84df9e7fe9f640afb435%7C1%7C0%7C636543894193512179=6c8JMa5%2B35IVM7wsPhH3zM3529gUgGpO7VtoEYz0UqI%3D=0.
>  So if I understand your point, you are saying that I should be exporting my 
> accounts to text, then using another program to implement such a system?

Not quite, you only need to export a bit of your accounts.  Otherwise, yes

>1.  I would rather use GNUCash over the plaintext tools if it is an 
> option. Mainly because of the convenience in layout, display and interaction 
> with my data. GNUCash it already gives somewhere between 70-85% of what I 
> would need/want from the ideal.

Me too!

>2.  I could spend my time learning the command line tools. or I could 
> spend my time helping out with GNUCash to build in the functionality I want 
> (and evidently lots of other people want – but I don’t say any of this 
> meaning the dev’s should do it for me. I say it to fend off your constant 
> assertion: “that’s not what GNUC

RE: Scope of GNUCash

[Matt Graham]

Not sure why you think I’m one  of the “demanding” people... I’m not actually 
asking for anything – I’m trying to figure out how this all works, what I 
really need, and how I can contribute to make it happen I don’t expect 
anything specific from the core dev group – I just want to fit in with their 
plans.

I am not sure why you think I’m defining the scope for anyone in these 
emails I started this thread asking what the scope is (triggered because 
you keep telling me that all the stuff I’m interested in is out of scope...). I 
don’t expect to get a say – I just thought there would be something that states 
it so that I can admit you are right (and stop focussing on that) or get you to 
stop saying that things people want to do “isn’t what GNUcash is for”. (Note: 
“We haven’t had time to implement that and probably wont get time” is a very 
different statement from “we won’t implement that because that isn’t what 
GNUCash is for”. The former => no worries I’ll help out if I can to get it to 
happen. Until then, I’ll make do. The latter => No worries, I’ll figure out a 
way to do it out of GNUCash and I’ll stop asking about it. Again: I’M NOT 
DEMANDING ANYTHING – I’M TRYING TO UNDERSTAND.

So based on the questions I’m asking you (running around in circles?), I’m 
pretty confident I’m missing a lot of your points. I’ve read through a lot of 
the text accounting references you gave me a while ago about budgeting And 
it all seems pretty much in line with what Chris L and I were talking about 
ages ago. I was thinking along the lines of envelope budgeting with 
sub-accounts and tools to help that. Chris was talking about virtual 
transactions and how that would work. Both are described in various wiki’s and 
help docs found off the plain text accounting budgeting area: 
http://plaintextaccounting.org/#budgeting. So if I understand your point, you 
are saying that I should be exporting my accounts to text, then using another 
program to implement such a system?

  1.  I would rather use GNUCash over the plaintext tools if it is an option. 
Mainly because of the convenience in layout, display and interaction with my 
data. GNUCash it already gives somewhere between 70-85% of what I would 
need/want from the ideal.
  2.  I could spend my time learning the command line tools. or I could 
spend my time helping out with GNUCash to build in the functionality I want 
(and evidently lots of other people want – but I don’t say any of this meaning 
the dev’s should do it for me. I say it to fend off your constant assertion: 
“that’s not what GNUCash is for!!!”. I’m still confused on what you think 
GNUCash should be for).
  3.  If I am supposed to export from GNUcash regularly and then import to the 
command line tool to do stuff I’ll regularly want to do... then why wouldn’t I 
just use the command line tool for everything? Based on what you say, why do 
you use GNUCash at all??? What can it do that the command line tools can’t?

For David T: What I’m planning to put into the Tut and Concepts at the moment 
is a description of how to use sub-accounts for envelope budgeting – Similar to 
the “Poor Postgrad System” in this link (but for GNUCash): 
https://memo.barrucadu.co.uk/2018-budget.html

I hope I’m not being unreasonable (or being misunderstood) in all my posts. I 
am very grateful for the functionality and capability that GNUcash already has, 
and hopefully people aren’t getting offended when I ask my questions.
Is it unreasonable to always be looking for a better way of doing things???

Thanks and regards,

Matt

From: Wm via gnucash-devel<mailto:gnucash-devel@gnucash.org>
Sent: Wednesday, 14 February 2018 11:35 AM
To: gnucash-de...@lists.gnucash.org<mailto:gnucash-de...@lists.gnucash.org>
Subject: Re: Scope of GNUCash

On 13/02/2018 21:53, Matt Graham wrote:
>  I think I would love to sit down in a pub with the three of you (Wm, 
> Adrien, and Mike). I think we could have such awesome semi-drunken 
> discussions about the nature of life, the universe and everything!

I'm in London. Mike is in a Trump voting bit of Merka. Don't know where
Adrien is and he shouldn't have to say.

Accounting is a way of measuring life.  Happiness is harder to quantify.
  Life should be enjoyable and measuring money shouldn't occupy too much
of our time.

Most crass philosophical sayings are also guaranteed to be crap.

> I think you have basically answered my question, and I think we all basically 
> agree on the rough direction things *should* go in (separate interacting 
> packages).

I'm the person arguing for stuff to be taken *out* of the basic package
so the important stuff can more easily be better interpreted or used,
the important stuff being the data that each of us owns or has
responsibility for.

Meanwhile, since I have a good understanding of accounting and databases
and related stuff, I just do the bits I need that gnc doesn't cover
using plain text 

RE: Scope of GNUCash

[Matt Graham]

 I think I would love to sit down in a pub with the three of you (Wm, Adrien, 
and Mike). I think we could have such awesome semi-drunken discussions about 
the nature of life, the universe and everything!

I think you have basically answered my question, and I think we all basically 
agree on the rough direction things *should* go in (separate interacting 
packages). I’m just not sure how to help make it happen (I’m an enthusiastic 
amateur when it comes to programming). I think I’ll start by updating the 
budget part of the tuts and concept guide like I have promised elsewhere, and 
then start looking into how the C++ modules have been structured (to see what 
connection will be possible within the 3.0 releases).

Thanks and regards,

Matt

From: Adrien Monteleone
Sent: Wednesday, 14 February 2018 2:31 AM
To: gnucash-devel
Subject: Re: Scope of GNUCash

Michael,

I agree completely on the separation point, especially with regard to controls.

I’ve seen first hand when sales clerks have the ability to void and edit their 
own transactions from a point of sales system. I can’t imagine the damage that 
WOULD be done if they also had the ability to access the inventory system AND 
the general accounting software. (even just the ability to partially close a 
ticket is dangerous)

As for interoperability, the devil is always in the details but I see three 
main hangups. First, any software should be able to import it’s own exports. 
Second, any software with imports should be able to allow the user an easy way 
to map fields and save that mapping for future use. Third, importing and 
exporting should be possible to schedule or trigger without manual user 
intervention. (so apps can talk to each other reliably without lag)

I think 3.0 is going to partially address the first and second case. I don’t 
think the third is contemplated yet. The third is also dangerous for accounting 
so it should be very carefully implemented and certainly not a default 
condition.

Regards,
Adrien

> On Feb 13, 2018, at 8:10 AM, Mike or Penny Novack 
>  wrote:
>
> On 2/13/2018 2:55 AM, Wm via gnucash-devel wrote:
>
>>
>>> A couple of times I have noticed that people have said "That's not what 
>>> GNUCash is for". It begs the question - where is it defined what GNUCash is 
>>> and isn't for? The charter for GNUCash doesn't seem to ever been formalised.
>> There is a long term plan, we never write it down because people ask us 
>> about it :) Is it intended that people should establish a complementary but 
>> separate project for functionality they want, but is not included in GNUCash 
>> scope?
>>
>> I don't see why not if that is what they want to do.
>
> Since I have been one of the people arguing for "separation" (I think this is 
> being misunderstood) I want to clarify the reasons and what I mean when I use 
> the term.
>
> a) I do NOT mean that needs to be a separate project. Could be part of a 
> PACKAGE (even installed together) but not a single program.
>
> b) The reason for separate "packages" that interact with each other rather 
> than a single program (that a user is or is not allowed to use) is so that 
> ONE "system" (interacting parts) can be used for all. Those people who are 
> running "one man band" businesses do not see the problem, do not see why 
> things like (proposed extensions) like "inventory", "point of sales", 
> "payroll",  etc. cannot be PART of the "general ledger" program. Call these 
> "one man band" users businesses of class A.
>
> But there is another sort of business user, call these class B. They have 
> employees, they have division of responsibility and authority. They may have 
> need of safeguards. I am not meaning JUST businesses since even a larger 
> non-profit (call these class C, they might have other needs too) might need 
> safeguards making embezzlement more difficult.
>
> These need separation. They need to be able to have people "log in and use" 
> things like an inventory system or "point of sales" system WITHOUT being able 
> to access "general ledger. Does not have to be a very large small business 
> before it has people waiting on customers, stocking inventory, etc. These 
> people need to be able to do their jobs without being able to access "general 
> ledger".
>
> c) A solution with separated subsystems that feed each other would satisfy 
> the needs of these entities (class B and C) while at the same time satisfy 
> the needs of entities of class A. The reverse is not true AND not practical 
> to "first build what would just work for class A and then modify that to work 
> for classes B and C". That would be pretty much a complete rewrite.
>
> d) However, the IS a common element for all the proposed additions (if 
> separate). They need a way to FEED (send transactions to) general ledger. So 
> general ledger (gnucash as it is) would need a way to accept feeds. And 

Scope of GNUCash

[Matt Graham]

>IIRC the discussion at the time was about whether gnc should or could be  used 
>for trading.  the result was "no"

A couple of times I have noticed that people have said "That's not what GNUCash 
is for". It begs the question - where is it defined what GNUCash is and isn't 
for? The charter for GNUCash doesn't seem to ever been formalised.

Is it intended that people should establish a complementary but separate 
project for functionality they want, but is not included in GNUCash scope?

Thanks and regards,
Matt
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: Future allocated money, aka Envelope Budgeting

[Matt Graham]

Thanks for your replies!

I still need to go through all the interesting links from that plain text 
accounting page, so that might change my mind, but I hope they keep at least 
the existing budget functionality.  I see the existing budget tool as just a 
way to plan out the future state of your accounts – so perfectly appropriate 
for anyone.

Though you are right, it doesn’t enforce double entry so it is different from 
the core use of Gnucash.

Thanks and regards,

Matt

From: Wm via gnucash-devel<mailto:gnucash-devel@gnucash.org>
Sent: Sunday, 4 February 2018 11:57 PM
To: gnucash-de...@lists.gnucash.org<mailto:gnucash-de...@lists.gnucash.org>
Subject: Re: Future allocated money, aka Envelope Budgeting

On 03/02/2018 00:12, Matt Graham wrote:
> Wow! That become contentious quick!!!

Only sort of.  If you read the devel list before the user list you get a
feeling for what isn't going to happen soon and why.

> The primary issue I’m seeing here is one of philosophy. What is GNUCash for? 
> What is the purpose? What “should” be included and what “shouldn’t” be?

It is for people, of course ! Perhaps you meant, "who is it for?" :)

There is a universe of people that like, use and prefer single entry
accounting along with the budgeting spiritualism and personal mantras
that accompany some of them.  gnc ain't that and may not be for them.

Let me mention something else I think should, for example, be removed
once the db is sorted out: USA and other country specific tax stuff (I'm
not even sure how much of it works any more as governments change their
tax systems without consulting gnc, etc)

Double entry accounting has been around for a while, that is definitely
going to be included for ever.

Budgeting is, as I said before, personal.  It varies from person to
person (I think envelope budgeting is short sighted) and what is
appropriate for a person is inappropriate for more formal organisations
that might require auditing or oversight.

If *all* the myriad of wonderful budgeting weirdness was added to gnc
the prog would more than double in size in a year ... each year ... and
3 people would be using each of the special budgets and another 2
requests would come in each year, etc.

It just doesn't make sense putting more into an over stretched db
compared to an interface that anyone can grab anything they want from
using an ordinary spreadsheet.

Am I making sense?
gnc isn't
for a person of a certain nationality, it should work for most
gnc isn't
for a person or an organisation, it should work for most
gnc isn't
for a charity vs a business, it should work for most
gnc isn't
for a country, it works with currencies
etc

> As has been highlighted, when someone loads up software they have a preset 
> notion in their own mind of how it “should” work, and that is usually their 
> own very narrow context (e.g. “That’s not how budgets work!”).

gnc's existing budgeting is very useful to some businesses and charity
organisations, even though I use them in that context I still think they
should be pulled out in the long term.  Budgeting is too idiosyncratic.

And anyway, given a good interface you could use, I could probably write
a budget app a day.

NB: budgeting is not complicated computing, it is largely a human
problem rather than a computing one.

> My assumption on purpose: Open source software is created out of need and 
> altruism. People who know how and want help create and maintain the project 
> both because they are interested in software and enjoy the process, but also 
> because they like being altruistic and providing something that others find 
> useful.

I won't speak for seniors, I do read what they say. Of course, my
understanding is mine if incorrect.

> Based on that assumption, I have had the attitude “All requests should be 
> considered and prioritised by the devs, but of course they will mainly 
> implement what they find useful and of course they will only give how much 
> time they can afford to”.

devs may be busy, devs may have a long list, devs may have lives aside
from the project, etc

> The natural flow on from my attitude is that I should indeed throw in what I 
> want/need from my financial tools, but not expect anyone to act on it. If I 
> want it done, I need to donate my time and implement it because it is 
> definitely unreasonable to demand others to do it when it isn’t useful for 
> them. (On that note, I’m keen to help out, but don’t yet have knowledge (and 
> also struggle for time) in all this).
>

The problem with gnc code at the moment is that there is very little
most people (or at least I) can do coding wise until the seniors get
their stuff done.

Monitoring the user list, knowing accounting, understanding stuff, these
are all useful things to do.

> I have lots of specific comments against what people are saying, but all 
> would be unhelpful if my fund

RE: Future allocated money, aka Envelope Budgeting

[Matt Graham]

Wow! That become contentious quick!!!

The primary issue I’m seeing here is one of philosophy. What is GNUCash for? 
What is the purpose? What “should” be included and what “shouldn’t” be?
As has been highlighted, when someone loads up software they have a preset 
notion in their own mind of how it “should” work, and that is usually their own 
very narrow context (e.g. “That’s not how budgets work!”).

My assumption on purpose: Open source software is created out of need and 
altruism. People who know how and want help create and maintain the project 
both because they are interested in software and enjoy the process, but also 
because they like being altruistic and providing something that others find 
useful.

Based on that assumption, I have had the attitude “All requests should be 
considered and prioritised by the devs, but of course they will mainly 
implement what they find useful and of course they will only give how much time 
they can afford to”.

The natural flow on from my attitude is that I should indeed throw in what I 
want/need from my financial tools, but not expect anyone to act on it. If I 
want it done, I need to donate my time and implement it because it is 
definitely unreasonable to demand others to do it when it isn’t useful for 
them. (On that note, I’m keen to help out, but don’t yet have knowledge (and 
also struggle for time) in all this).

I have lots of specific comments against what people are saying, but all would 
be unhelpful if my fundamental attitude to the project is wrong.

Thanks and regards,

Matt

From: John Ralls
Sent: Saturday, 3 February 2018 3:51 AM
Cc: gnucash-devel
Subject: Re: Future allocated money, aka Envelope Budgeting



> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel  > wrote:
>
> There is, IMO, work to be done on on the underlying db structure, have you 
> seen this monster ?
> ===
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2Fimages%2F8%2F86%2FGnucash_erd.png=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=aEzd9p0oY9t1%2Bczj66N5%2Fg3bfwhBmGEq6YCXy2xn%2FEA%3D=0
>  
> 
> ===
> It is as ugly as an ugly thing (I'd say what I thought but I'd like more than 
> a  mod to get to read this).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that 
implements it to C++ with clearly defined objects instead of a rather quirky 
collection of macros. That’s in the current “unstable” and will be released in 
3.0.

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ 
objects with proper constructors so that creating an object doesn’t involve 
calling a bunch of property setters (one at a time!) that want to commit the 
object and write it back to the database. That will be my focus for the next 
development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit 
more reasonable and get away from sucking the whole DB into memory at load time.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435%7C1%7C0%7C636531870670279982=hTrghqjNt8XEYkE05%2FGtO7YQQre21RRVh%2Fm9LZMP8LY%3D=0

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

Re: Future allocated money, aka Envelope Budgeting

[Matt Graham]

ot;c" 
> including future splits.
> Unreconciled $50 - counts splits-values from "n"
> Cleared $0 - counts splits-values from "n" "c"
> Reconciled $0 - counts splits-values from "n" "y" c"
> Budget $250 - counts all split-values from "n" "y" "c" "b"
>
> 5. A Budget report could be created, comparing the various expenses' running 
> balances vs the budget balance. The difference is the amount left to spend in 
> this category. For the food account it's 250-50 = $200 left to spend.

So you go through the trouble of creating a new split status to keep track of 
the remaining budget, but still have to calculate the remaining budget?

>
> 6. Anytime the user wishes to allocate more budget to food, they can simply 
> create (b)udget transaction from Bank or Imbalance account to the Food 
> account.
>
> 7. This means, in the account register, we'll see regular transactions which 
> can be reconciled with the bank statement. We'll also see budget 
> transactions, not reconcilable with the bank statement. Perhaps they should 
> be a different color/background. But this is ok, because their amounts do not 
> affect the account running balance. The Reconcile window can also filter them 
> out. The existing reports are unaffected. The query mechanism should ignore 
> them by default.
>
> What do we think of this?
>
> The budget balance for an asset account represents "money remaining to 
> allocate", and the budget balance for an expense account effectively 
> represents "the upper limit that I'll allow this account to be". The budget 
> balance, minus running balance represents "money left in envelope". I can 
> increase envelope contents by transferring budget money from asset to the 
> expense accounts.
>
> I wouldn't know how to handle credit card nor loan interest.
>
> I think it's an interesting thought experiment. The devil will be in the 
> details.
>
> The advantage will be that the underlying code can handle this augmented 
> functionality without major difficulty (famous last words.)
>
> Chris

In the short term, if the code for SX could either be borrowed, or amended to 
allow for saving a template of a transaction that is then fired on demand (say 
with a button) instead of on a date stamp, that could help tremendously paired 
with the sub-account method outlined in the user thread. I think template 
transactions are already an enhancement request, so there are other use cases 
for this feature. The most prominent I can think of is payroll.

Regards,
Adrien

>
> On 31/01/18 15:59, David T. via gnucash-user wrote:
>> Matt,
>> I have to admit that I misread the tally; I did not see that the first $500 
>> (AllocatedCash) was balancing the others. My apologies.
>> I'll let you and Adrien work this out, since I don't have a lot of 
>> background in this.
>> David
>>
>>   On Wed, Jan 31, 2018 at 8:58, Matt Graham<matt_graham2...@hotmail.com> 
>> wrote:   #yiv0595440679 #yiv0595440679 -- _filtered #yiv0595440679 
>> {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0595440679 
>> {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv0595440679 
>> #yiv0595440679 p.yiv0595440679MsoNormal, #yiv0595440679 
>> li.yiv0595440679MsoNormal, #yiv0595440679 div.yiv0595440679MsoNormal 
>> {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;}#yiv0595440679 a:link, 
>> #yiv0595440679 span.yiv0595440679MsoHyperlink 
>> {color:blue;text-decoration:underline;}#yiv0595440679 a:visited, 
>> #yiv0595440679 span.yiv0595440679MsoHyperlinkFollowed 
>> {color:#954F72;text-decoration:underline;}#yiv0595440679 
>> .yiv0595440679MsoChpDefault {} _filtered #yiv0595440679 {margin:72.0pt 
>> 72.0pt 72.0pt 72.0pt;}#yiv0595440679 div.yiv0595440679WordSection1 
>> {}#yiv0595440679
>> Hi Dave!
>>
>> Yep, that is pretty much the conclusion I’ve come to. Not sure what you 
>> are asking about in “where are you balancing the funds”. The Cr and Dr are 
>> balanced in the example. Maybe you are asking the location in the hierarchy 
>> for the accounts? It all goes up to the root account “Assets”. For this 
>> idea, I had Current Assets, Fixed assets, and Allocated Assets. All the 
>> little allocation accounts were stored in the Allocated Assets branch.
>>
>> They were balanced by a single account under current assets called 
>> “AllocatedCash” (as per the example below). This is the weird one – a 
>> negative asset account that reflects how much I SHOULDN’T spend out of 
>> current assets unless I am spending on my allocated causes.
>>
>> As per Adrian’s discus

Re: On development/release processes and version numbers

[Matt Graham]

As a Noob following this with interest:
1. If a platform makes a decision that breaks a previous stable version, it 
could be a case if create a quick fix branch off that version tag, and release 
an extra ".1". So 2.6.1 would become 2.6.1.1. Note that I am assuming that this 
is rare and that most people are keeping up to date with stable releases (so 
most bugs are off that).

2. Ultimately, it sounds like step 1 (regardless of which version control 
labelling is used) is to try to automate as much of the "release process" as 
possible. This frees up time from an experienced coder.
Should we have a separate part of the source code for release scripts (that the 
release manager can just run)? Is this something that people like me can help 
with? (Not that I know enough yet to be much help...)

Thanks and regards,
Matt


 Original message 
From: Glen Ditchfield 
Date: 26/1/18 12:43 (GMT+10:00)
To: gnucash-devel@gnucash.org
Subject: Re: On development/release processes and version numbers

Regarding EOL management, I think you will soon have three supported
"product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
...), and a 2.4.x series.   (The level of support might be something
low like "security fixes only".)  3.1 will likely come out before 2.6.x
reaches end-of-life.

If that is correct, you'll have to be able develop bug fixes that don't
apply to all of the supported series.  I don't think that will be easy
if you have just one bugfix branch.

I looked around and couldn't find any helpful Git advice for projects
that have more than one supported version.  Every detailed work flow
seemed to assume that there just one blob of current production code,
and one development branch.

Perhaps this would work:
 * Normal development (refactorings, enhancements, etc) goes on master.
 * Every supported series has a branch: for now, create releases-2.6.x
   and releases-2.4.x.  Bug fixes accumulate on these branches.
 * Use feature branches for development: every enhancement and every
   bug fix gets its own branch.  Enhancements branch off from master.
   Bug fixes for old versions branch off from a releases-* branch.
 * When the time comes to prepare for the GnuCash 3 release, create
   branch releases-3.0.x from master.  Make any necessary adjustments
   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
   work done on master after the branch will be part of v3.1.0.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C398a5e971c26478e833508d5645e22fc%7C84df9e7fe9f640afb435%7C1%7C0%7C636525277829194997=jxw9jYSj39B%2B%2ByIsE7ElE8fwm5d6pNFie3JU%2FMpEph4%3D=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Budgets Wiki Page

[Matt Graham]

Thanks John,

For now I was going to rename the current budget wiki page to be called "Budget 
History" or something like that and create a new page called "Budget 
Requirements" to house the requirements stuff.

I only recently signed up to the wiki, so that's probably why I can't do it!

Fair Winds, and happy new year!

Matt /|\

 John Ralls wrote 


> On Dec 31, 2015, at 3:15 PM, Matt Graham <matt_graham2...@hotmail.com> wrote:
>
> Thanks John! Greatly appreciated. Unfortunately I don't have privileges to 
> create new pages. This is weird, because when I read the MediaWiki 'help' 
> section (something I should have done before initially posting... sorry...) 
> it seems to indicate that all users should have the ability to edit pages.
>
> Tried the main ways in the manual under User help => Editing => starting a 
> new page. An easier way than searching is to use the URL method!
>
> Further searches of the manual revealed nothing useful - My conclusion is 
> that at some point permissions for creating pages have been removed from 
> general users. Anyone on this list an administrator to be able to change it 
> back?

Hmm. AFAICT from the user rights page and from Mediawiki help, create page is 
granted by being autoconfirmed, which requires that your ID has existed for a 
certain amount of time and that you've made a certain number of contributions. 
I haven't yet figured out what those numbers are.

Tell me the names of the pages you want to create and I'll create them for you.

Regards (and Happy New Year),
John Ralls

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

Re: Budgets Wiki Page

[Matt Graham]

Thanks John! Greatly appreciated. Unfortunately I don't have privileges to 
create new pages. This is weird, because when I read the MediaWiki 'help' 
section (something I should have done before initially posting... sorry...) 
it seems to indicate that all users should have the ability to edit pages.


Tried the main ways in the manual under User help => Editing => starting a 
new page. An easier way than searching is to use the URL method!


Further searches of the manual revealed nothing useful - My conclusion is 
that at some point permissions for creating pages have been removed from 
general users. Anyone on this list an administrator to be able to change it 
back?


Cheers,

Matt

P.s. for Future people reading this, if you need help on how to use wiki's 
click on "Help" in the right column of the wiki. Duh, right? 


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

Budgets Wiki Page

[Matt Graham]

G’day Devs,

Not sure if this is the right place to ask this. Does anyone know how I request 
new wiki pages be created on wiki.gnucash.org? The ‘Requirements for Gnucash 
Budgets’ section of the Budgets page http://wiki.gnucash.org/wiki/Budgets 
really should be split from the rest of the page which is all about history of 
budget creation (with links between the two as they are related).

How would I go about doing this? Don’t think I have privileges to do it (or at 
least can’t find how to create pages in the wiki). 

Cheers,

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

Re: Cutecash Compiling

[Matt Graham]

Thanks for the quick reply John!

With respect to warnings as errors, sounds good - I'll change my
compilation of gnucash to use this and try and help out by fixing
warnings that show up.

Sounds like I have misunderstood cutecash. I got the impression that
this was an attempt to bring gnucash (slowly) into C++. re-reading the
wiki page more closesly, what you say makes sense - one of the devs
trying to re-write the gui in C++ and use qt. In the past, you have
made comment that there is moves going on to bring gnucash code into a
more modern language - was this cutecash or something else?

As a side note, the dependencies on Gtk+ and gnomecanvas in my ebuild
are there because I started by just copying the gnucash ebuild => I
don't actually know much about these packages, so I assumed they are
still needed. The result would be that anyone that uses this ebuild
will have portage installing packages they don't need... (but they'd
still get cutecash, since the compilation uses cmake with cutecash on).

However, all of this is a bit redundant - if cutecash is not actively
developed at the moment I think I'll leave it. There are far better
contributions I can make than doing this (especially since I have no
understanding or experience with cmake or qt).

Thanks for your help!

Cheers,

Matt G


On Wed, 2015-12-23 at 22:25 -0800, John Ralls wrote:
> > On Dec 23, 2015, at 9:28 PM, Matt Graham <
> > matt_graham2...@hotmail.com> wrote:
> > 
> > G’day All,
> > 
> > I’ve been keen to try out cutecash to see how it all goes, and
> > maybe help out (if my noobiness can be overcome...). Got through
> > quite a few problems, and learned a lot about Cmake in the process.
> > I’m currently at a point where I think it isn’t a gentooism that is
> > holding me back...
> > 
> > Firstly, all warnings are being treated as errors. Looking through
> > options provided in CMakeLists.txt of the root gnucash sources
> > directory, there doesn’t seem to be an “OPTION (WITH_WERROR ...”
> > kind of definition for me to be able to disable this activity. As
> > far as i can see this is hardcoded in the compile flags by the line
> > (same file): 
> > 
> > SET( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror -Wdeclaration-after
> > -statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -Wall -Wunused 
> > -Wmissing-prototypes -Wmissing-declarations  -Wno-unused")
> > 
> > This is the one for unix, but there is an equivalent for windows
> > (although I think Apple gets away without an equivalent)
> > 
> > The First question: Was this on purpose, and why? Is there a way in
> > Cmake for me to override this behaviour? e.g. can I pass something
> > like “–D Werror=OFF” as a configuration line to cmake?
> > I would have thought you would want to set a default in this
> > respect then let the user decide how they want the compile to
> > progress. Unless you want to get cutecash to a point where it
> > doesn’t have warnings => sounds like a lot of work...
> > 
> > The specific problem stopping me from building cutecash is a
> > warning “_FORTIFY_SOURCE redefined”. Sounds like this variable has
> > been defined twice somewhere. Not too sure where because the
> > referenced files don’t exist in the source code – they must be
> > getting generated by cmake. Build log is attached. If you know
> > gentoo and want to see my ebuild it is on my public github:
> > https://github.com/mattig7/MattsPackages/blob/master/app-office/cut
> > ecash/cutecash-99.ebuild
> > The commit used for building the attached build log is b3c1203 (in
> > case I change it before you see it).
> > 
> > The Questions: 
> > 1. Is this something to bother solving, or would you get past this
> > by disabling the ‘all warnings are errors’ behaviour?
> > 2. How on earth do we find out where this comes from in Cmake? in
> > this one, I don’t really know where to start other than trying to
> > learn a HUGE amount about Cmake to figure out where all these files
> > are generated from and why.
> 
> We expect that the code will compile without errors or warnings, and
> specify -Werror to enforce that. See below for particulars about the
> error you encountered. But note as well that the master branch is
> very unstable, particularly in this development cycle where we're
> making some very ambitious changes aimed towards making GnuCash a
> true database application able to support multiple simultaneous
> sessions.
> 
> As for CuteCash, it's really an experiment by one developer,
> Christian Stimming. It's in the main repository because it predates
> git; nowadays we'd expect that it would live in its own branch in a
> personal Github repo, b

Recommendations on Coding programs

[Matt Graham]

G’day all,

Now that I finally have myself set up to be able to view, edit and test the 
gnucash sources, I have come across the limitation of using text editors (using 
nano at the moment...) to code. Can anyone recommend a good program for doing 
coding for Gnucash? I’m mainly looking at the C side of things rather than 
guile, but a program that can do multiple types of code would be useful. 
Preferably ones that are supported on both windows and linux.

Cheers,

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

Maint branch minor issues - file bugs?

[Matt Graham]

G’day All,

Found an unterminated comment in git maint branch that prevented my compiling. 
Offending file was /src/register/register-gnome/gnucash-sheetP.h. Basically 
someone put “/@” rather than “@ */”. Because it is on a git working branch 
(rather than a released version) should I be filing a bug for this one? To be 
honest, someone with write access to the git sources could just go in and 
quickly fix it might be easier anyway.

Cheers,

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

Re: Make fail - No rule to make target COPYING

[Matt Graham]

Ignore this one – figured it out.

I had assumed that the gentoo eclass function for downloading the sources ran 
the autogen.sh script, but no... a misunderstanding of the process on my 
account!

Running ./autogen.sh as per the gnucash build instructions on the web fixed the 
problem.

Cheers,

Matt

From: Matt Graham 
Sent: Sunday, October 11, 2015 4:14 PM
To: gnucash-devel@gnucash.org 
Subject: Make fail - No rule to make target COPYING

G’day all,

I’m a bit of a noob, so please bear with me. I’m trying to compile gnucash 
directly from the git sources. Since I work on Gentoo, I’ve been having all 
sorts of fun with overlays and ebuilds... but that’s another story. 

When it begins the compile phase, I get an error:

make[2]: *** No rule to make target ‘COPYING', needed by ‘all-am’. Stop


Looking through the make file generated by automake and configure, I’m guessing 
that this error relates to the following command:

dist_doc_DATA = \
AUTHORS \
   COPYING \
   ChangeLog \
   ...


The variable “dist_doc_DATA” has a number of values in it, and as far as i can 
see “COPYING” is the only one that isn’t a file present. I also can’t find this 
as a file anywhere within the git sources.

Where should I go from here? Does this sound like a Gnucash bug I should raise, 
or is it likely I am missing something simple?

Thanks and regards,

Matt Graham /|\

P.s. If it helps, my ebuild is on my public gentoo repository, cloneable from 
https://github.com/mattig7/MattsPackages.git
I’m using version 2.6.8 – ignore the other ones, haven’t fixed lots of issues 
with them yet. Just realised that I should have changed to 2.6.9 that can 
be next I guess!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Make fail - No rule to make target COPYING

[Matt Graham]

G’day all,

I’m a bit of a noob, so please bear with me. I’m trying to compile gnucash 
directly from the git sources. Since I work on Gentoo, I’ve been having all 
sorts of fun with overlays and ebuilds... but that’s another story. 

When it begins the compile phase, I get an error:

make[2]: *** No rule to make target ‘COPYING', needed by ‘all-am’. Stop


Looking through the make file generated by automake and configure, I’m guessing 
that this error relates to the following command:

dist_doc_DATA = \
AUTHORS \
   COPYING \
   ChangeLog \
   ...


The variable “dist_doc_DATA” has a number of values in it, and as far as i can 
see “COPYING” is the only one that isn’t a file present. I also can’t find this 
as a file anywhere within the git sources.

Where should I go from here? Does this sound like a Gnucash bug I should raise, 
or is it likely I am missing something simple?

Thanks and regards,

Matt Graham /|\

P.s. If it helps, my ebuild is on my public gentoo repository, cloneable from 
https://github.com/mattig7/MattsPackages.git
I’m using version 2.6.8 – ignore the other ones, haven’t fixed lots of issues 
with them yet. Just realised that I should have changed to 2.6.9 that can 
be next I guess!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

RE: Doxygen Generated Code - High level structure

[Matt Graham]

You are 100% right, John – since we want multiple files in the one group we 
need to always use addtogroup and not defgroup.

But is the idea about module structure definition and standardisation worth 
considering? I.e. having a single file lay out the hierarchical structure of 
the modules (using addtogroup with the sub group inside @{ and @} ). That way 
you would just need to add the file with addtogroup and it would automatically 
be in the module hierarchy.

Am I just overthinking things? Am I best off focusing on updating the current 
structure? Or is this a good idea?

Cheers,

Matt 



From: John Ralls
Sent: Friday, 11 September 2015 12:40 PM
To: Matt Graham
Cc: gnucash-devel@gnucash.org
Subject: Re: Doxygen Generated Code - High level structure



> On Sep 10, 2015, at 7:03 PM, Matt Graham <matt_graham2...@hotmail.com> wrote:
> 
> G’day All,
> 
> I’ve been monitoring this list and trying to learn the structure of GNUCash 
> code for about 4 months now. I’m a bit of a noob, so it is slow going. 
> 
> I believe that code documentation (i.e. the Doxygen generated stuff) should 
> allow someone like me to quickly gain a grasp of how everything is worked and 
> linked. The detailed understanding, of course, needs to come from reviewing 
> the actual code of interest. After pouring through a lot of the current 
> doxygen generated stuff, my conclusion is that a lot of it is there, but in a 
> chaotic order. Some things are not up to date, but there is no easy way to 
> tell what needs updating and what doesn’t. Most modules (i.e. groups) do not 
> have a ‘defgroup’ definition, only ‘addtogroup’ commands for each of the 
> relevant files. This is not a problem, but the result in the past seems to be 
> that not all files have been associated with the group they need to be, and 
> creating sub-groups is somewhat inconsistent. E.g. I just added 
> gnu-budget-view.c to the Budgets group, which is called ‘budget’. I copied 
> the script from gnu-budget-view.h to get this. Additionally, we have ‘design 
> concept’ type documentation mixed into different places – e.g. the budget 
> concept document that is on the main screen under Doxygen Overviews, but 
> can’t be found with the “Budgets” module. 
> 
> What I suggest:
> 
> We have a single file in /src/doc that contains all of the defgroup commands. 
> This way it would be very simple to see and amend the structure of the 
> modules as you like. Every file that needs to has its appropriate 
> ‘addtogroup’ command within it to get it into the best point in the defgroup 
> breakdown. The very first sub-group for most modules will be a “design 
> considerations” group/file that will bring up the relevant design 
> consideration file. The next will be about the implementation (broken down 
> into sub groups if necessary, or a single ‘implementation’ group otherwise. 
> On the main page, we would keep the first section on “External 
> Documentation”, but remove “Documentation elsewhere in the source tree.”. 
> “Doxygen Overviews” would be replaced with a reference to the modules section 
> telling people to look at the appropriate module for information (because all 
> information would be there – the files, the implementation, the design 
> concepts etc). The ‘General Doxygen help” would be kept as is.
> 
> With this kind of structure, adding modules or adding files to modules 
> becomes really easy. Keeping a module up-to-date should happen automatically 
> as people update the files they are changing.
> 
> The downside is a little bit of time to change the relevant commands. I’m 
> happy to open a bug and take the lead on updating the structure to reflect 
> this. I’ll create a plan when I open the bug to ensure we aren’t left with 
> useless documentation at any point during the process.
> 
> What I am seeking is your input! Am I going down a good line? Any 
> suggestions/recommendations?

Matt,

From the Doxygen docs:
"You will get an error message when you use the same group label more than 
once. If you don't want doxygen to enforce unique labels, then you can use 
\addtogroup instead of \defgroup. It can be used exactly like \defgroup, but 
when the group has been defined already, then it silently merges the existing 
documentation with the new one.” 

IOW there’s no need to use \defgroup.

Regards,
John Ralls


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

Doxygen Generated Code - High level structure

[Matt Graham]

G’day All,

I’ve been monitoring this list and trying to learn the structure of GNUCash 
code for about 4 months now. I’m a bit of a noob, so it is slow going. 

I believe that code documentation (i.e. the Doxygen generated stuff) should 
allow someone like me to quickly gain a grasp of how everything is worked and 
linked. The detailed understanding, of course, needs to come from reviewing the 
actual code of interest. After pouring through a lot of the current doxygen 
generated stuff, my conclusion is that a lot of it is there, but in a chaotic 
order. Some things are not up to date, but there is no easy way to tell what 
needs updating and what doesn’t. Most modules (i.e. groups) do not have a 
‘defgroup’ definition, only ‘addtogroup’ commands for each of the relevant 
files. This is not a problem, but the result in the past seems to be that not 
all files have been associated with the group they need to be, and creating 
sub-groups is somewhat inconsistent. E.g. I just added gnu-budget-view.c to the 
Budgets group, which is called ‘budget’. I copied the script from 
gnu-budget-view.h to get this. Additionally, we have ‘design concept’ type 
documentation mixed into different places – e.g. the budget concept document 
that is on the main screen under Doxygen Overviews, but can’t be found with the 
“Budgets” module. 

What I suggest:

We have a single file in /src/doc that contains all of the defgroup commands. 
This way it would be very simple to see and amend the structure of the modules 
as you like. Every file that needs to has its appropriate ‘addtogroup’ command 
within it to get it into the best point in the defgroup breakdown. The very 
first sub-group for most modules will be a “design considerations” group/file 
that will bring up the relevant design consideration file. The next will be 
about the implementation (broken down into sub groups if necessary, or a single 
‘implementation’ group otherwise. On the main page, we would keep the first 
section on “External Documentation”, but remove “Documentation elsewhere in the 
source tree.”. “Doxygen Overviews” would be replaced with a reference to the 
modules section telling people to look at the appropriate module for 
information (because all information would be there – the files, the 
implementation, the design concepts etc). The ‘General Doxygen help” would be 
kept as is.

With this kind of structure, adding modules or adding files to modules becomes 
really easy. Keeping a module up-to-date should happen automatically as people 
update the files they are changing.

The downside is a little bit of time to change the relevant commands. I’m happy 
to open a bug and take the lead on updating the structure to reflect this. I’ll 
create a plan when I open the bug to ensure we aren’t left with useless 
documentation at any point during the process.

What I am seeking is your input! Am I going down a good line? Any 
suggestions/recommendations?

Cheers,

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

Re: Doxygen Warnings

[Matt Graham]

Thanks John,

I'm running doxygen directly on the src directory of the code.

Windows 8.1 at the moment. I'm travelling for work at the moment, when I get 
home over the weekend I'll try it on my gentoo box too

Cheers,
Matt /|\

 John Ralls wrote 


> On Sep 1, 2015, at 2:04 AM, Matt Graham <matt_graham2...@hotmail.com> wrote:
>
> I think I might have a mistake in my doxygen configuration. When generating 
> from the source (obtained by cloning Github repository) I get nearly 450 
> warnings.
>
>
> A lot of these relate to references that aren't found. Immediately, on the 
> index.htm page I notice that only one of all the links under “Doxygen 
> Overviews” has been created successfully. Has anyone else generated the 
> documentation from the current source and have you had a similar problem?

Matt,

The docs are built nightly (you can find them at 
http://code.gnucash.org/docs/HEAD) and built last night. I ran Doxygen locally 
a month or so ago without trouble. Did you try running Doxygen by hand or did 
you `make docs`? What OS/distro?

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Doxygen Warnings

[Matt Graham]

I think I might have a mistake in my doxygen configuration. When generating 
from the source (obtained by cloning Github repository) I get nearly 450 
warnings. 


A lot of these relate to references that aren't found. Immediately, on the 
index.htm page I notice that only one of all the links under “Doxygen 
Overviews” has been created successfully. Has anyone else generated the 
documentation from the current source and have you had a similar problem?






Thanks and regards,

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

Re: Doxygen Code Documentation

[Matt Graham]

Thanks for responding so quickly guys!


FYI John, I’m not planning on commenting line by line - just commenting all the 
methods/variables/structures so that people can see how things interact whilst 
browsing doxygen pages. I’ll try to get around to reading your recommended 
book, but it probably wont be for a few days.


I like Derek's idea of commenting blocks of code, but I'll probably only do 
this for areas that look really hard to understand (and probably more for 
myself than for submission).





Thanks and regards,

Matt Graham





From: Derek Atkins
Sent: ‎Tuesday‎, ‎1‎ ‎September‎ ‎2015 ‎01‎:‎13‎ ‎
To: John Ralls
Cc: Matt Graham, gnucash-devel@gnucash.org





John Ralls <jra...@ceridwen.us> writes:

> Some programmers, often less-experienced ones, will comment code
> liberally to explain what they’re doing. More experienced programmers
> often find this irritating because they’re fluent enough in the
> programming language that they can understand the code without the
> comments and the comments just get in the way. Those programmers
> prefer a brief descriptive comment only when the author finds it
> necessary to do something non-ideomatic.

I dunno; I consider myself an experienced programmer and I like
documenting my algorithms (to explain how chunks of code work).  I don't
necessarily comment each line (e.g., I wouldn't be in a comment
"increment x" next to or above "x++;") but I do like to, even 10-20
lines or so, put in a comment about what the block of code is supposed
to do.

If nothing else it helps me when I revisit the code a year later to get
myself back into the mindset, otherwise I wind up going "what was I
THINKING when I wrote that?"

> None of which should be taken as a defense of GnuCash’s code or API
> documentation. A lot of the code is a turgid, unideomatic mess with
> several-hundred-line functions calling all over the place and
> sometimes flipping back and forth between Scheme and C. Writing bug
> reports about it won’t be helpful unless you submitting a patch, and
> then only if it’s a good patch that improves code readability,
> testability, or Doxygen documentation. If that’s the sort of work you
> want to take on, Welcome! If you haven’t already, get a copy of Martin
> Fowler’s “Refactoring” and study it: It’s the bible for fixing ugly
> code.
>
> Regards,
> John Ralls

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Doxygen Code Documentation

[Matt Graham]

G’day all!


Whilst there is  lot of enthusiasm about documentation flowing around, I 
thought I’d ask a general question regarding the last type of documentation not 
previously mentioned: The doxygen generated documentation about how the code 
works (can I call it the API?).


I’ve been taking my time learning and setting up git whilst browsing through 
doxygen and code - specifically around budgets. What I am finding is that the 
level of documentation generated varies greatly from file to file (and even 
within a file).  I generate the documentation myself from my clone of the 
repository.


I’m very much a noob (have mainly worked with java in the past, and never with 
anything like gtk) - I am currently have to go line by line in the code to 
figure out specifically what a lot of the methods do, and how they all relate 
to each other to achieve the end goal. Is this usual, or is this an area where 
I can (and should) help out by submitting a bug report and developing a patch?





Keep up the good work all!

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

How are Budgets Implemented in GNU Cash

[Matt Graham]

I would like to contribute to GNUCash, and get into the development side of the 
house.

I figure that a (relatively) quick and easy contribution (that will also help 
me personally) is for me to create a patch to correct the bug where budgeted 
expenses don’t show up in the summary section at the bottom of the screen 
(https://bugzilla.gnome.org/show_bug.cgi?id=742352).

My problem is that I cannot find (from the documentation) where the budget side 
of code is implemented within GNU Cash (even after much Googling). Can anyone 
steer me towards somewhere to look for more information about how Budgets are 
implemented?

Thanks,

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