[GNC-dev] Widget naming and css

[Robert Fewell]

I have been thinking about naming some widgets and changing some of the
entries I added with css style classes and wondered if there has been a
convention decided.

What I would like to see is a couple of unique prefixes so that one could
do a grep on the top level directory and obtain all such entries and maybe
manipulate into some sort of list that could be published some ware.

Doing a quick content search shows 'gnc-style-' and 'gnc-name-' would work
but open to suggestions.

This would allow those users inclined to customise the appearance more
easily.
I would probably do this on master over time.

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

[GNC-dev] Transaction / Split Action List

[Robert Fewell]

There have been some enquiries about customising this list so I thought I
would propose a possible solution that I may work.
At the moment the static lists are based on register type in
split-register.c and it looks to me there are two possible options.

1, Dynamicaly add to these lists based on past entries, probably there
would be an overhead do so.
2, Allow the lists to be customised in some sort of config file.

I think 2, is the better option and in the source it mentions about using a
config file so I was thinking along those lines to basicly do...

Create a new user key file probably in .config/gnucash called
user-config.gcm

On gnucash load, test for the file and if not present create it with the
default list content of split-register.c, I assume this would populate the
file with the translated entries.

A section name would then have list keys for the entries, something like...

[Action List]
cash_register=Increase;Decrease;Buy;Sell
asset_register=Buy;Sell;Fee

Change gnc_split_register_config_action to read the key file content to
populate the appropriate list.

A missing register key would get a list of one entry with "Empty".

This would allow the users, once the file is created to add or remove
entries as required.

Any thoughts, wrong approach ?

This would probably be a master project.

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

Re: [GNC-dev] Budgets: showing total-to-date in budget period, and previous month totals only

[Phil Longstaff]

Hi Chris,

I am running 3.1 and it works. The only comment I have is that the 'Bgt',
'Act' and 'Diff' headings are left-justified and look a bit strange. I
think center- or right-justified would be better.

Thanks for doing this.
Phil

On Sun, Jun 17, 2018 at 11:16 AM Christopher Lam 
wrote:

> Hi Phil
> I've taken the liberty of fixing up your YTD-budget, renamed to budget-ytd.
> I don't use budgeting myself and cannot check figures. But it seems useful
> enough.
> https://github.com/christopherlam/gnucash/tree/master-ytd
> Would you be kind to double check it works as expected in 3.1/maint
> onwards?
> C
>
> On 26 March 2018 at 20:04, Phil Longstaff 
> wrote:
>
>> I have attached a report which does this.
>>
>> I have attached ytd-budget.scm. I have this file in
>> c:\Users\phill\.gnucash\reports. I then add this line to
>> c:\Users\phill\.gnucash\config.user:
>>
>> (load "c:\\Users\\phill\\.gnucash\\reports\\ytd-budget.scm")
>>
>> This gives me a new "YTD budget" with 3 sets of columns:
>> 1) selected month
>> 2) year-to-date
>> 3) full year
>>
>> It always shows actual and budget amounts, and there is an option to add
>> difference. There is also an option to select which month you want to
>> show.
>>
>> On Sun, Mar 25, 2018 at 7:21 PM, Macho Philipovich 
>> wrote:
>>
>> > Dear Gnucash Users,
>> >
>> >
>> > I am looking to for a report/view that will show
>> > budgeted/actual/difference amounts for selected accounts for the
>> > previous month, as well as the totals for all months to date in the
>> > current budgeting period.
>> >
>> >
>> > The wiki seems to suggest that GnuCash does not natively support this,
>> > but that it's possible using the third-party "Little Budget Tool":
>> >
>> >
>> > https://wiki.gnucash.org/wiki/Budget_History#Add-On:_.22The_
>> > Little_Budget_Tool.22
>> >
>> >
>> > When I tried to download and compile the said software, however I didn't
>> > get anywhere. I couldn't get ./configure to recognize the presence of
>> > qt, and when I told it to ignore, it balked on the first g++ command. On
>> > the one hand, it would not surprise me to learn that I'm just not doing
>> > the configure && make process properly. On the other, this software was
>> > last revised thirteen years ago.
>> >
>> >
>> > Any advice you can provide on getting the report view I'm looking for
>> > would be greatly appreciated!
>> >
>> >
>> > Thanks,
>> >
>> > Macho
>> >
>> >
>> > ___
>> > gnucash-user mailing list
>> > gnucash-u...@gnucash.org
>> > To update your subscription preferences or to unsubscribe:
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> > If you are using Nabble or Gmane, please see
>> > https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> > -
>> > Please remember to CC this list on all your replies.
>> > You can do this by using Reply-To-List or Reply-All.
>> >
>>
>> ___
>> gnucash-user mailing list
>> gnucash-u...@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Budgets: showing total-to-date in budget period, and previous month totals only

[Christopher Lam]

Hi Phil, glad to know I haven't broken anything. Can't think what to do 
about headers; these are problems that should be fixed in CSS! If you 
wish I can submit a PR but ideally would wish to create a satisfactory 
test datafile and report output. I don't use budget, so, I wouldn't be 
the best here. If you can send me, I'll try make a basic test for it. C


On 23/06/18 20:05, Phil Longstaff wrote:

Hi Chris,

I am running 3.1 and it works. The only comment I have is that the 
'Bgt', 'Act' and 'Diff' headings are left-justified and look a bit 
strange. I think center- or right-justified would be better.


Thanks for doing this.
Phil

On Sun, Jun 17, 2018 at 11:16 AM Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi Phil
I've taken the liberty of fixing up your YTD-budget, renamed to
budget-ytd.
I don't use budgeting myself and cannot check figures. But it
seems useful enough.
https://github.com/christopherlam/gnucash/tree/master-ytd
Would you be kind to double check it works as expected in
3.1/maint onwards?
C

On 26 March 2018 at 20:04, Phil Longstaff
mailto:phil.longst...@gmail.com>> wrote:

I have attached a report which does this.

I have attached ytd-budget.scm. I have this file in
c:\Users\phill\.gnucash\reports. I then add this line to
c:\Users\phill\.gnucash\config.user:

    (load "c:\\Users\\phill\\.gnucash\\reports\\ytd-budget.scm")

This gives me a new "YTD budget" with 3 sets of columns:
1) selected month
2) year-to-date
3) full year

It always shows actual and budget amounts, and there is an
option to add
difference. There is also an option to select which month you
want to show.

On Sun, Mar 25, 2018 at 7:21 PM, Macho Philipovich
mailto:mach...@riseup.net>>
wrote:

> Dear Gnucash Users,
>
>
> I am looking to for a report/view that will show
> budgeted/actual/difference amounts for selected accounts for the
> previous month, as well as the totals for all months to date
in the
> current budgeting period.
>
>
> The wiki seems to suggest that GnuCash does not natively
support this,
> but that it's possible using the third-party "Little Budget
Tool":
>
>
> https://wiki.gnucash.org/wiki/Budget_History#Add-On:_.22The_
> Little_Budget_Tool.22
>
>
> When I tried to download and compile the said software,
however I didn't
> get anywhere. I couldn't get ./configure to recognize the
presence of
> qt, and when I told it to ignore, it balked on the first g++
command. On
> the one hand, it would not surprise me to learn that I'm
just not doing
> the configure && make process properly. On the other, this
software was
> last revised thirteen years ago.
>
>
> Any advice you can provide on getting the report view I'm
looking for
> would be greatly appreciated!
>
>
> Thanks,
>
> Macho
>
>
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org 
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more
information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>

___
gnucash-user mailing list
gnucash-u...@gnucash.org 
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.




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

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

[John Ralls]

> On Jun 22, 2018, at 9:42 PM, Christopher Lam  
> wrote:
> 
> Hi All
> 
> I'm working through balance-sheet.scm and overhauling this report.
> 
> At the same time, I can see that balance-sheet.scm and income-statement.scm 
> can be merged together.
> 
> After all
> 
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at date X and Y
> 
> The issue I have is that the balance sheet can call 
> xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the 
> balance, whereas income statement cannot directly call it because it also 
> includes closing transactions.
> 
> My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd 
> boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) 
> which will selectively produce the balance, ignore closing transactions.
> 
> This is partly done in the last commit of 
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>  - it will augment API everywhere, and also modify Account.cpp, especially 
> xaccAccountRecomputeBalance which will call 
> xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the 
> account to determine closing status and cache the balances for each split. 
> See draft on 
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>  - this currently fails because I'm not good at C.
> 
> *My query is whether it will be too expensive to call 
> xaccTransGetIsClosingTxn for each split in Account.cpp to produce the 
> split->noclosing_balance, which will be crucial to calculate income between 
> two dates.*
> 
> *Currently this 'closing-txn' filter is done in income-statement.scm via a 
> "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls, 
> which IMHO is not ideal either.
> *
> 
> Any help welcome!
> 
> P.S. if this last commit is removed, the 
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
>  branch contains work-so-far for updated balance-sheet. Screenshot 
> https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the multilevel 
> subtotals were previously horizonal, are now vertical; original-currency 
> amounts, and multiple-date balance sheets.
> 
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s no-closing 
balance. Perhaps that’s why it doesn’t work?

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

Re: [GNC-dev] Widget naming and css

[John Ralls]

> On Jun 23, 2018, at 4:18 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> I have been thinking about naming some widgets and changing some of the
> entries I added with css style classes and wondered if there has been a
> convention decided.
> 
> What I would like to see is a couple of unique prefixes so that one could
> do a grep on the top level directory and obtain all such entries and maybe
> manipulate into some sort of list that could be published some ware.
> 
> Doing a quick content search shows 'gnc-style-' and 'gnc-name-' would work
> but open to suggestions.
> 
> This would allow those users inclined to customise the appearance more
> easily.
> I would probably do this on master over time.

Bob,

I’m not sure I understand what you’re suggesting. Perhaps you could suggest a 
concrete example?

Regards,
John Ralls

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

Re: [GNC-dev] Transaction / Split Action List

[John Ralls]

> On Jun 23, 2018, at 4:58 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> There have been some enquiries about customising this list so I thought I
> would propose a possible solution that I may work.
> At the moment the static lists are based on register type in
> split-register.c and it looks to me there are two possible options.
> 
> 1, Dynamicaly add to these lists based on past entries, probably there
> would be an overhead do so.
> 2, Allow the lists to be customised in some sort of config file.
> 
> I think 2, is the better option and in the source it mentions about using a
> config file so I was thinking along those lines to basicly do...
> 
> Create a new user key file probably in .config/gnucash called
> user-config.gcm
> 
> On gnucash load, test for the file and if not present create it with the
> default list content of split-register.c, I assume this would populate the
> file with the translated entries.
> 
> A section name would then have list keys for the entries, something like...
> 
> [Action List]
> cash_register=Increase;Decrease;Buy;Sell
> asset_register=Buy;Sell;Fee
> 
> Change gnc_split_register_config_action to read the key file content to
> populate the appropriate list.
> 
> A missing register key would get a list of one entry with "Empty".
> 
> This would allow the users, once the file is created to add or remove
> entries as required.
> 
> Any thoughts, wrong approach ?
> 
> This would probably be a master project.

Bob,

User-edited “ini” files are so 1980s. Anything like this should have a GUI 
interface.

I suspect at least some users would want to be able to set this per-account, 
but I think it more important to find out how many care at all and where it 
fits in most users’ list of priorities for improvements. It might even be that 
most users prefer the current pre-populated combo box that allows them to put 
anything they like in there, or that most don’t even use it.

Regards,
John Ralls

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

Re: [GNC-dev] Transaction / Split Action List

[Geert Janssens]

Op zaterdag 23 juni 2018 18:12:34 CEST schreef John Ralls:
> > On Jun 23, 2018, at 4:58 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > 
> > There have been some enquiries about customising this list so I thought I
> > would propose a possible solution that I may work.
> > At the moment the static lists are based on register type in
> > split-register.c and it looks to me there are two possible options.
> > 
> > 1, Dynamicaly add to these lists based on past entries, probably there
> > would be an overhead do so.
> > 2, Allow the lists to be customised in some sort of config file.
> > 
> > I think 2, is the better option and in the source it mentions about using
> > a
> > config file so I was thinking along those lines to basicly do...
> > 
> > Create a new user key file probably in .config/gnucash called
> > user-config.gcm
> > 
> > On gnucash load, test for the file and if not present create it with the
> > default list content of split-register.c, I assume this would populate the
> > file with the translated entries.
> > 
> > A section name would then have list keys for the entries, something
> > like...
> > 
> > [Action List]
> > cash_register=Increase;Decrease;Buy;Sell
> > asset_register=Buy;Sell;Fee
> > 
> > Change gnc_split_register_config_action to read the key file content to
> > populate the appropriate list.
> > 
> > A missing register key would get a list of one entry with "Empty".
> > 
> > This would allow the users, once the file is created to add or remove
> > entries as required.
> > 
> > Any thoughts, wrong approach ?
> > 
> > This would probably be a master project.
> 
> Bob,
> 
> User-edited “ini” files are so 1980s. Anything like this should have a GUI
> interface.
> 
> I suspect at least some users would want to be able to set this per-account,
> but I think it more important to find out how many care at all and where it
> fits in most users’ list of priorities for improvements. It might even be
> that most users prefer the current pre-populated combo box that allows them
> to put anything they like in there, or that most don’t even use it.
> 
> Regards,
> John Ralls

Agreed. I propose someone that cares to put up a feature request on userbase 
and invite others to vote on it. That should give some indication of perceived 
user priority.

Geert


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

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

[Christopher Lam]

Hi John, the split->noclosing_balance is updated in
xaccAccountRecomputeBalance. Will continue copypasta coding until it works!

On Sat, 23 Jun 2018, 23:56 John Ralls  wrote:

>
>
> > On Jun 22, 2018, at 9:42 PM, Christopher Lam 
> wrote:
> >
> > Hi All
> >
> > I'm working through balance-sheet.scm and overhauling this report.
> >
> > At the same time, I can see that balance-sheet.scm and
> income-statement.scm can be merged together.
> >
> > After all
> >
> > * balance sheet = asset/liability/equity balance at date X,
> > * income statement = difference in income/expense balances at date X and
> Y
> >
> > The issue I have is that the balance sheet can call
> xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the
> balance, whereas income statement cannot directly call it because it also
> includes closing transactions.
> >
> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd
> boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing)
> which will selectively produce the balance, ignore closing transactions.
> >
> > This is partly done in the last commit of
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - it will augment API everywhere, and also modify Account.cpp, especially
> xaccAccountRecomputeBalance which will call
> xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the
> account to determine closing status and cache the balances for each split.
> See draft on
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - this currently fails because I'm not good at C.
> >
> > *My query is whether it will be too expensive to call
> xaccTransGetIsClosingTxn for each split in Account.cpp to produce the
> split->noclosing_balance, which will be crucial to calculate income between
> two dates.*
> >
> > *Currently this 'closing-txn' filter is done in income-statement.scm via
> a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls,
> which IMHO is not ideal either.
> > *
> >
> > Any help welcome!
> >
> > P.S. if this last commit is removed, the
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> branch contains work-so-far for updated balance-sheet. Screenshot
> https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
> multilevel subtotals were previously horizonal, are now vertical;
> original-currency amounts, and multiple-date balance sheets.
> >
> > _
>
> Chris,
>
> Only profiling will tell how much of a performance hit this creates.
>
> I don’t see where in your commit you’re computing the split’s no-closing
> balance. Perhaps that’s why it doesn’t work?
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Transaction / Split Action List

[John Ralls]

> On Jun 23, 2018, at 9:14 AM, Geert Janssens  
> wrote:
> 
> Op zaterdag 23 juni 2018 18:12:34 CEST schreef John Ralls:
>>> On Jun 23, 2018, at 4:58 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>>> 
>>> There have been some enquiries about customising this list so I thought I
>>> would propose a possible solution that I may work.
>>> At the moment the static lists are based on register type in
>>> split-register.c and it looks to me there are two possible options.
>>> 
>>> 1, Dynamicaly add to these lists based on past entries, probably there
>>> would be an overhead do so.
>>> 2, Allow the lists to be customised in some sort of config file.
>>> 
>>> I think 2, is the better option and in the source it mentions about using
>>> a
>>> config file so I was thinking along those lines to basicly do...
>>> 
>>> Create a new user key file probably in .config/gnucash called
>>> user-config.gcm
>>> 
>>> On gnucash load, test for the file and if not present create it with the
>>> default list content of split-register.c, I assume this would populate the
>>> file with the translated entries.
>>> 
>>> A section name would then have list keys for the entries, something
>>> like...
>>> 
>>> [Action List]
>>> cash_register=Increase;Decrease;Buy;Sell
>>> asset_register=Buy;Sell;Fee
>>> 
>>> Change gnc_split_register_config_action to read the key file content to
>>> populate the appropriate list.
>>> 
>>> A missing register key would get a list of one entry with "Empty".
>>> 
>>> This would allow the users, once the file is created to add or remove
>>> entries as required.
>>> 
>>> Any thoughts, wrong approach ?
>>> 
>>> This would probably be a master project.
>> 
>> Bob,
>> 
>> User-edited “ini” files are so 1980s. Anything like this should have a GUI
>> interface.
>> 
>> I suspect at least some users would want to be able to set this per-account,
>> but I think it more important to find out how many care at all and where it
>> fits in most users’ list of priorities for improvements. It might even be
>> that most users prefer the current pre-populated combo box that allows them
>> to put anything they like in there, or that most don’t even use it.
>> 
>> Regards,
>> John Ralls
> 
> Agreed. I propose someone that cares to put up a feature request on userbase 
> and invite others to vote on it. That should give some indication of 
> perceived 
> user priority.

I think you mean UserVoice,  https://gnucash.uservoice.com 
. Bob, if you do that you’ll need to promote it 
on gnucash-users as well; there doesn’t seem to be much overlap between the two 
user sets. You should make it clear that this is something you propose to 
actually implement.

Regards,
John Ralls

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

[GNC-dev] Minor coding style discussion: C++ and comments

[Christian Stimming]

Dear developers,

some years ago we had a longer discussion about our coding style guide, 
especially as we started with more C++ parts in the project. Last time we 
discussed this a bit more was in 2014 [1], and the result was summarized in 
the wiki page  https://wiki.gnucash.org/wiki/CodingStandard

However, as C++ becomes more common for the actual work throughout gnucash, we 
might need to add or clarify a few points there. In my opinion this is really 
a minor issue, as everyone of us will be able to read and write any coding 
style, regardless which one we prefer. It is just nicer to read if there is a 
larger level of consistency. Having said that, one such thing is the way of 
writing multi-line comments in C++ code. Should this be:

// This is
// a multi-line comment (C++ style)

or rather in C style

/* This is
   a multi-line comment (C style) */

with additionaly variants of those? John and I discussed this question 
shortly. There used to be an advice on the wiki page but different from the 
other points this hasn't been discussed here on the mailing list [2]. Hence 
John and I agreed it should be raised on the mailing list.

My proposal is to use the C++ style option in the source code. In any case the 
style should be consistent throughout the source files, i.e. someone would 
need to transform the style that is different from the agreed one.

Also, the doxygen comments in the headers, should those stick to the doxygen 
proposal

/** Some doxygen
multi-line comment (C style, doxygen) */

or should we switch to something different? There are multiple options 
possible, including 

/// Some doxygen multi-line
/// comment (C++ style, doxygen)

but on the other hand we don't have many C++-only headers so far. I'd rather 
stick with the old style as long as we usually have headers used by the C code 
as well.

More ideas and voices?

Regards,

Christian


[1] 
https://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038027.html 
[2] John said: The only discussion about commenting style I found was 
https://lists.gnucash.org/pipermail/gnucash-devel/2008-January/thread.html#22321
 (the thread finishes in February, 
https://lists.gnucash.org/pipermail/gnucash-devel/2008-February/022375.html); 
before we considered C++; another discussion about C++ style begins at 
https://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038027.html 
but doesn’t mention comments
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Minor coding style discussion: C++ and comments

[John Ralls]

> On Jun 23, 2018, at 2:16 PM, Christian Stimming  
> wrote:
> 
> Dear developers,
> 
> some years ago we had a longer discussion about our coding style guide, 
> especially as we started with more C++ parts in the project. Last time we 
> discussed this a bit more was in 2014 [1], and the result was summarized in 
> the wiki page  https://wiki.gnucash.org/wiki/CodingStandard
> 
> However, as C++ becomes more common for the actual work throughout gnucash, 
> we 
> might need to add or clarify a few points there. In my opinion this is really 
> a minor issue, as everyone of us will be able to read and write any coding 
> style, regardless which one we prefer. It is just nicer to read if there is a 
> larger level of consistency. Having said that, one such thing is the way of 
> writing multi-line comments in C++ code. Should this be:
> 
> // This is
> // a multi-line comment (C++ style)
> 
> or rather in C style
> 
> /* This is
>   a multi-line comment (C style) */
> 
> with additionaly variants of those? John and I discussed this question 
> shortly. There used to be an advice on the wiki page but different from the 
> other points this hasn't been discussed here on the mailing list [2]. Hence 
> John and I agreed it should be raised on the mailing list.
> 
> My proposal is to use the C++ style option in the source code. In any case 
> the 
> style should be consistent throughout the source files, i.e. someone would 
> need to transform the style that is different from the agreed one.
> 
> Also, the doxygen comments in the headers, should those stick to the doxygen 
> proposal
> 
> /** Some doxygen
>multi-line comment (C style, doxygen) */
> 
> or should we switch to something different? There are multiple options 
> possible, including 
> 
> /// Some doxygen multi-line
> /// comment (C++ style, doxygen)
> 
> but on the other hand we don't have many C++-only headers so far. I'd rather 
> stick with the old style as long as we usually have headers used by the C 
> code 
> as well.
> 
> More ideas and voices?
> 
> Regards,
> 
> Christian
> 
> 
> [1] 
> https://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038027.html 
> [2] John said: The only discussion about commenting style I found was 
> https://lists.gnucash.org/pipermail/gnucash-devel/2008-January/thread.html#22321
>  (the thread finishes in February, 
> https://lists.gnucash.org/pipermail/gnucash-devel/2008-February/022375.html); 
> before we considered C++; another discussion about C++ style begins at 
> https://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038027.html 
> but doesn’t mention comments

A wee clarification: Reference 2 is a discussion of 6 possible commenting 
styles for C code; it occurred several years before we began to adopt C++. It’s 
worth reading both to see all 6 proposals and the various arguments for and 
against each. The argument about C compilers not supporting C++-style is now 
obsolete. The C99 spec allows that style of comments and any compiler that 
supports C++11 will also support C99, though we may need to set -std=C99 in 
CMAKE_C_FLAGS to avoid whining.

There are also a couple more ways to delineate doxygen comments described at 
http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html 
.

For the record, I don’t care as long as all comments in a file use the same 
style and a single commit is used to convert the comments in a particular file 
and that commit has no other changes.

Regards,
John Ralls




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

Re: [GNC-dev] Transaction / Split Action List

[Paul Dest]

My 2 cents from from the user perspective:
Being able to put user-defined strings into a record field is of very
limited value if you are not able to search/find/analyze this data.

That's why, as I recently had built a GnuCash with my own split action
list for myself, I additionally extended the transaction report to
filter for specific split action values.

(Still on my to-do-list: extending wiki with the description how to
create lists of user defined strings, bind them to arbitrary key strokes
or to a GUI menu in order to insert them into arbitrary input fields in
arbitrary applications, e.g. in the split action field of GnuCash.)

Best regards,
Paul

On 23.06.2018 18:12, John Ralls wrote:
>
>> On Jun 23, 2018, at 4:58 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>>
>> There have been some enquiries about customising this list so I thought I
>> would propose a possible solution that I may work.
>> At the moment the static lists are based on register type in
>> split-register.c and it looks to me there are two possible options.
>>
>> 1, Dynamicaly add to these lists based on past entries, probably there
>> would be an overhead do so.
>> 2, Allow the lists to be customised in some sort of config file.
>>
>> I think 2, is the better option and in the source it mentions about using a
>> config file so I was thinking along those lines to basicly do...
>>
>> Create a new user key file probably in .config/gnucash called
>> user-config.gcm
>>
>> On gnucash load, test for the file and if not present create it with the
>> default list content of split-register.c, I assume this would populate the
>> file with the translated entries.
>>
>> A section name would then have list keys for the entries, something like...
>>
>> [Action List]
>> cash_register=Increase;Decrease;Buy;Sell
>> asset_register=Buy;Sell;Fee
>>
>> Change gnc_split_register_config_action to read the key file content to
>> populate the appropriate list.
>>
>> A missing register key would get a list of one entry with "Empty".
>>
>> This would allow the users, once the file is created to add or remove
>> entries as required.
>>
>> Any thoughts, wrong approach ?
>>
>> This would probably be a master project.
> Bob,
>
> User-edited “ini” files are so 1980s. Anything like this should have a GUI 
> interface.
>
> I suspect at least some users would want to be able to set this per-account, 
> but I think it more important to find out how many care at all and where it 
> fits in most users’ list of priorities for improvements. It might even be 
> that most users prefer the current pre-populated combo box that allows them 
> to put anything they like in there, or that most don’t even use it.
>
> Regards,
> John Ralls
>
> ___
> 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