Re: Are There Plans For A GUI Overhaul?

[Christian Stimming]

On Dienstag, 4. Oktober 2016 21:34:51 CEST Dave wrote:
> Thanks for the great responses! It does clarify quite a bit.
> 
> 
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

Some more pointers for learning about the internal C API: I wrote this wiki 
page http://wiki.gnucash.org/wiki/C_API in 2011 as a Summe of Code student had 
the same question. To me the explanation still seems valid. Maybe this is of 
some help here.

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

Re: Are There Plans For A GUI Overhaul?

[Christian Stimming]

Dear Dave,

some additional voice on this topic: I'm the author who wrote the alternative 
C++/Qt GUI program "cutecash" on top of the internal gnucash "engine" code. 
That was in 2010. To my surprise, the code (with some minor fixes that I 
committed today) still compiles, links, and runs. Just use cmake, set 
WITH_CUTECASH=on (requires libglibmm-dev ), and make. One can open a gnucash 
data file, browse through the accounts, edit a transaction and even undo the 
edit (heh!). It will crash sooner or later due to various code changes in the 
underlying object ownerships, but IMHO it might again be worth a look.

My take on the long term plans is that there are multiple plans around here. 
Even a "migration to C++" can be done on various different levels, with 
different strategies. For the cutecash experiment, I tested using the glibmm 
wrappers, which map the glib stuff to C++ sufficiently well. If asked, I would 
suggest to prefer glibmm usage over complete rewriting, and replacing glibmm-
wrapped objects by std c++ as a subsequent step. This would enable a switch to 
C++ on the GUI side somewhat earlier than requiring a complete C++ rewrite 
first. Then again, I probably won't be doing any of these work as I spend only 
very little time on gnucash currently, and those decisions typically are done 
by those people who actually invest their time in coding here. So don't take 
my advice too seriously :-)

However, a new GUI layer will for sure have to start with a very small subset 
of features. It might be a good path into more future-proof coding technology, 
but it will for sure have only a small part of the current gnucash's features. 
Maybe one can find a set of features with some small new additions that 
attracts enough attention... but I don't know how this set of features would 
have to look like.

If some people around here are looking into further GUI coding in C++, 
preferrably using Qt toolkit, I would be interested to help out every now and 
then. Feel free to contact me directly if interested.

Regards,

Christian






On Mittwoch, 5. Oktober 2016 08:44:44 CEST Dave wrote:
> Thanks, Jon and Ted.
> 
> John, you inspired my optimism. Ted, you gave me a healthy dose of caution.
> 
> :)
> 
> So, I've done SysAdmin work for a living. In this field, lines of code are
> thought of as liabilities. If I can get something done with 10 lines of
> BASH code, I'll probably do it. Almost always, there needs to be a tangible
> result to efforts within 1-2 weeks of starting. So I'm used to being ruled
> more by economy and less by elegance. If I have an elegant solution, but it
> will take time to write, I have to essentially work in secret, burning the
> midnight oil. And even then, the idea may have actually been a bad one and
> I just wasted all that time that I didn't get paid or praised for. :(
> 
> This is why I've by a Pythonista for some time. I use OOP when it makes
> sense, and don't when it doesn't. I write a working solution today, and can
> easily come back tomorrow to abstract this or that and make it maintainable
> for my future self and others. So I've learned a little about evolving a
> project, but only really in Python.
> 
> I've wanted to get back to C/C++ for some time. My main motivation was AVR
> programming, which I've done a little bit of recently. However, none of my
> background has been in larger application design and programming. It seems
> that C++ has matured quite a bit since I touched it almost a decade ago.
> When I learned it, I got as far as the STL, which seemed very advanced to
> me at the time, but very interesting at the same time as I was finishing up
> a mathematics degree and the STL seemed like a great way to create the sort
> of abstractions that would help me begin writing programs to do
> computational analysis. I probably would have gone that direction too, but
> life took a turn for me and I got into managing Linux systems and hardware
> and data centers.
> 
> 
> Ted, I promise I'll give it some time. :)  I'm not in any particular rush.
> I learn best by doing and it would be a pleasure if I could get up to speed
> in C++ again and help out GnuCash at the same time. I really just need to
> dive into C++ again. If I can't swim, then I can't swim and I'll have to
> move on. From what I've read about it, though, things like "shallow
> hierarchies" are practices I've already conceptually learned in the Python
> world. When I learned Python, I began writing it like a Java programmer. I
> have since been coaches completely away from that and classes are mostly
> used for a type of namespacing, easier testing or the like. I've also found
> that more and more, my programs are made up of generic computation over
> data. So most of what's happening is that the application gets directed by
> dictionaries that get processed to produce results. Basically, the Python
> becomes more akin to a scheme program. I've found that this produces a
> great amount of flexibility.

Re: Are There Plans For A GUI Overhaul?

[John Ralls]

> On Oct 5, 2016, at 5:44 PM, Dave  wrote:
> 
> Thanks, Jon and Ted.
> 
> John, you inspired my optimism. Ted, you gave me a healthy dose of caution. :)
> 
> So, I've done SysAdmin work for a living. In this field, lines of code are 
> thought of as liabilities. If I can get something done with 10 lines of BASH 
> code, I'll probably do it. Almost always, there needs to be a tangible result 
> to efforts within 1-2 weeks of starting. So I'm used to being ruled more by 
> economy and less by elegance. If I have an elegant solution, but it will take 
> time to write, I have to essentially work in secret, burning the midnight 
> oil. And even then, the idea may have actually been a bad one and I just 
> wasted all that time that I didn't get paid or praised for. :(
> 
> This is why I've by a Pythonista for some time. I use OOP when it makes 
> sense, and don't when it doesn't. I write a working solution today, and can 
> easily come back tomorrow to abstract this or that and make it maintainable 
> for my future self and others. So I've learned a little about evolving a 
> project, but only really in Python.

Dave,

I've also done sysadmin on and off for 30 years or so, and I do understand the 
need for quick-and-dirty in that environment.

Development is different. Elegant isn't necessarily required, but intelligible 
is. It's *really* important that what you write is clear and concise so that 
when it needs changing a  year or 10 down the road whoever ends up with the job 
(which might be you! never overestimate how much you'll remember about what you 
wrote 6 weeks ago, never mind 6 years ago) must be able to quickly understand 
what the code does so that it's not too hard to figure out the required mods. 
Code that clearly and concisely gets the job done while expressing the intent 
without requiring a lot of comments is the ultimate goal. The goal for a C++ 
core is the major release after next, expected around the end of 2020. By Ted's 
metric a full-time programmer (working only 5 days a week with 2 off rather 
than the 365 he wanted--typical project manager) would produce 800,000 lines of 
code and (if he's well disciplined and keeps his functions to between 20 and 50 
lines each) 25,000 functions. Since C++ is a l!
 ot more expressive than C or Scheme, that's
pretty much a complete rewrite of GnuCash.

OTOH, Ted left off a crucial step: Write tests. Lots of tests. That takes time 
too, so our notional full-time programmer will rewrite only *half* of GnuCash 
in 4 years.

Regards,
John Ralls


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

Re: Are There Plans For A GUI Overhaul?

[Ted Creedon]

If you read and understand Scott Meyers books you're good to go.

From: rhymeswithd...@gmail.com  on behalf of Dave 

Sent: Wednesday, October 5, 2016 8:44 AM
To: Ted Creedon
Cc: John Ralls; gnucash-devel@gnucash.org
Subject: Re: Are There Plans For A GUI Overhaul?

Thanks, Jon and Ted.

John, you inspired my optimism. Ted, you gave me a healthy dose of caution. :)

So, I've done SysAdmin work for a living. In this field, lines of code are 
thought of as liabilities. If I can get something done with 10 lines of BASH 
code, I'll probably do it. Almost always, there needs to be a tangible result 
to efforts within 1-2 weeks of starting. So I'm used to being ruled more by 
economy and less by elegance. If I have an elegant solution, but it will take 
time to write, I have to essentially work in secret, burning the midnight oil. 
And even then, the idea may have actually been a bad one and I just wasted all 
that time that I didn't get paid or praised for. :(

This is why I've by a Pythonista for some time. I use OOP when it makes sense, 
and don't when it doesn't. I write a working solution today, and can easily 
come back tomorrow to abstract this or that and make it maintainable for my 
future self and others. So I've learned a little about evolving a project, but 
only really in Python.

I've wanted to get back to C/C++ for some time. My main motivation was AVR 
programming, which I've done a little bit of recently. However, none of my 
background has been in larger application design and programming. It seems that 
C++ has matured quite a bit since I touched it almost a decade ago. When I 
learned it, I got as far as the STL, which seemed very advanced to me at the 
time, but very interesting at the same time as I was finishing up a mathematics 
degree and the STL seemed like a great way to create the sort of abstractions 
that would help me begin writing programs to do computational analysis. I 
probably would have gone that direction too, but life took a turn for me and I 
got into managing Linux systems and hardware and data centers.


Ted, I promise I'll give it some time. :)  I'm not in any particular rush. I 
learn best by doing and it would be a pleasure if I could get up to speed in 
C++ again and help out GnuCash at the same time. I really just need to dive 
into C++ again. If I can't swim, then I can't swim and I'll have to move on. 
From what I've read about it, though, things like "shallow hierarchies" are 
practices I've already conceptually learned in the Python world. When I learned 
Python, I began writing it like a Java programmer. I have since been coaches 
completely away from that and classes are mostly used for a type of 
namespacing, easier testing or the like. I've also found that more and more, my 
programs are made up of generic computation over data. So most of what's 
happening is that the application gets directed by dictionaries that get 
processed to produce results. Basically, the Python becomes more akin to a 
scheme program. I've found that this produces a great amount of flexibility.


Thanks again for the pointers, warnings and generally good discussion. I will 
look at the resources given. I've also found 
this, which I'm hoping is also a 
good place to start educating myself.

On Wed, Oct 5, 2016 at 5:09 AM, Ted Creedon 
> wrote:
As a retired Senior Project Manager responsible for maintaining many million 
lines of code I offer the following advice:

1. Stop and think.
2. Mark up the existing GUI's to indicate changes.
3. Write the New User's Manual and the System Adminstrator's Guide and 
Reference manual (tedious)
4.  Select an IDE and non make build system (CMake,Scons, etc.)
4. Write subroutine headers that compile and link
5. Complete coding (very boring)

If you doubt my wisdom, ask Scott Meyers to confirm Ted Creedon's advice.

Stay away from C++ unless you have significant decades of experience.

ROM effort for 1,000,000 lines of code / 100 lines per sub /per day = 10,000 
subroutines /365= more time than we have..

=> We're prisoners of the existing code.

Ted Creedon, P.E.

From: gnucash-devel 
>
 on behalf of John Ralls >
Sent: Wednesday, October 5, 2016 12:12:59 AM
To: Dave
Cc: gnucash-devel@gnucash.org
Subject: Re: Are There Plans For A GUI Overhaul?

> On Oct 5, 2016, at 6:34 AM, Dave 
> > wrote:
>
> Thanks for the great responses! It does clarify quite a bit.
>
>
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ 

Re: Are There Plans For A GUI Overhaul?

[Dave]

Thanks, Jon and Ted.

John, you inspired my optimism. Ted, you gave me a healthy dose of caution.
:)

So, I've done SysAdmin work for a living. In this field, lines of code are
thought of as liabilities. If I can get something done with 10 lines of
BASH code, I'll probably do it. Almost always, there needs to be a tangible
result to efforts within 1-2 weeks of starting. So I'm used to being ruled
more by economy and less by elegance. If I have an elegant solution, but it
will take time to write, I have to essentially work in secret, burning the
midnight oil. And even then, the idea may have actually been a bad one and
I just wasted all that time that I didn't get paid or praised for. :(

This is why I've by a Pythonista for some time. I use OOP when it makes
sense, and don't when it doesn't. I write a working solution today, and can
easily come back tomorrow to abstract this or that and make it maintainable
for my future self and others. So I've learned a little about evolving a
project, but only really in Python.

I've wanted to get back to C/C++ for some time. My main motivation was AVR
programming, which I've done a little bit of recently. However, none of my
background has been in larger application design and programming. It seems
that C++ has matured quite a bit since I touched it almost a decade ago.
When I learned it, I got as far as the STL, which seemed very advanced to
me at the time, but very interesting at the same time as I was finishing up
a mathematics degree and the STL seemed like a great way to create the sort
of abstractions that would help me begin writing programs to do
computational analysis. I probably would have gone that direction too, but
life took a turn for me and I got into managing Linux systems and hardware
and data centers.


Ted, I promise I'll give it some time. :)  I'm not in any particular rush.
I learn best by doing and it would be a pleasure if I could get up to speed
in C++ again and help out GnuCash at the same time. I really just need to
dive into C++ again. If I can't swim, then I can't swim and I'll have to
move on. From what I've read about it, though, things like "shallow
hierarchies" are practices I've already conceptually learned in the Python
world. When I learned Python, I began writing it like a Java programmer. I
have since been coaches completely away from that and classes are mostly
used for a type of namespacing, easier testing or the like. I've also found
that more and more, my programs are made up of generic computation over
data. So most of what's happening is that the application gets directed by
dictionaries that get processed to produce results. Basically, the Python
becomes more akin to a scheme program. I've found that this produces a
great amount of flexibility.


Thanks again for the pointers, warnings and generally good discussion. I
will look at the resources given. I've also found this
, which I'm hoping is also a
good place to start educating myself.

On Wed, Oct 5, 2016 at 5:09 AM, Ted Creedon  wrote:

> As a retired Senior Project Manager responsible for maintaining many
> million lines of code I offer the following advice:
>
> 1. Stop and think.
> 2. Mark up the existing GUI's to indicate changes.
> 3. Write the New User's Manual and the System Adminstrator's Guide and
> Reference manual (tedious)
> 4.  Select an IDE and non make build system (CMake,Scons, etc.)
> 4. Write subroutine headers that compile and link
> 5. Complete coding (very boring)
>
> If you doubt my wisdom, ask Scott Meyers to confirm Ted Creedon's advice.
>
> Stay away from C++ unless you have significant decades of experience.
>
> ROM effort for 1,000,000 lines of code / 100 lines per sub /per day =
> 10,000 subroutines /365= more time than we have..
>
> => We're prisoners of the existing code.
>
> Ted Creedon, P.E.
> 
> From: gnucash-devel  gnucash.org> on behalf of John Ralls 
> Sent: Wednesday, October 5, 2016 12:12:59 AM
> To: Dave
> Cc: gnucash-devel@gnucash.org
> Subject: Re: Are There Plans For A GUI Overhaul?
>
> > On Oct 5, 2016, at 6:34 AM, Dave  wrote:
> >
> > Thanks for the great responses! It does clarify quite a bit.
> >
> >
> > From the looks of things, it seems that the C -- C++ port would have the
> > most impact right now. It would take me awhile to get my C/C++ abilities
> > ramped up again. Where's the best place to start learning about gnucash
> > code? I don't know when I'd be able to start helping, but I'd at least
> want
> > to learn what I could.
>
> I think the best leverage for an additional developer at this point would
> be to work on extracting the business logic from the GUI code. That work
> could be in C since it's mostly extract function refactors and the
> extracted functions have to be callable by the C GUI.
>
> Part of that same 

Re: GnuCash additional capability Translation

[John Ralls]

> On Oct 5, 2016, at 10:39 AM, Mohamed Yassin  wrote:
> 
> Hello Dears GnuCash,
> 
> 
> I really appreciate your effort in free open source software, i came here now 
> just today :)
> 
> 
> and i see that there under feature:
> 
> GnuCash handles internationalized dates and currencies. The application's 
> menus and popups have been translated to 21 languages, including Chinese, 
> Danish, French, German, Hungarian, Italian, Japanese, Norwegian, Polish, 
> Portuguese, Russian, Spanish, Swedish, Turkish, Ukrainian, and British 
> English. Documentation is available in English, French, Portuguese and 
> Spanish.
> 
> 
> and i didn't find my language; Arabic language , So, i came want to 
> contribute in Translation
> 
> i have a business and accounting background and working in IT field
> 
> and now if you like, from where i can start

Mohamaed,

We do indeed have an Arabic translation contributed about a year ago by 
Abdulsalam ALshilash. If you'd like to help improve it, please coordinate with 
him; you'll find his email address in the header of 
https://github.com/Gnucash/gnucash/blob/master/po/ar.po.

Regards,
John Ralls



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

Re: Are There Plans For A GUI Overhaul?

[Ted Creedon]

As a retired Senior Project Manager responsible for maintaining many million 
lines of code I offer the following advice:

1. Stop and think.
2. Mark up the existing GUI's to indicate changes.
3. Write the New User's Manual and the System Adminstrator's Guide and 
Reference manual (tedious)
4.  Select an IDE and non make build system (CMake,Scons, etc.)
4. Write subroutine headers that compile and link
5. Complete coding (very boring)

If you doubt my wisdom, ask Scott Meyers to confirm Ted Creedon's advice.

Stay away from C++ unless you have significant decades of experience.

ROM effort for 1,000,000 lines of code / 100 lines per sub /per day = 10,000 
subroutines /365= more time than we have..

=> We're prisoners of the existing code.

Ted Creedon, P.E.

From: gnucash-devel  
on behalf of John Ralls 
Sent: Wednesday, October 5, 2016 12:12:59 AM
To: Dave
Cc: gnucash-devel@gnucash.org
Subject: Re: Are There Plans For A GUI Overhaul?

> On Oct 5, 2016, at 6:34 AM, Dave  wrote:
>
> Thanks for the great responses! It does clarify quite a bit.
>
>
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

I think the best leverage for an additional developer at this point would be to 
work on extracting the business logic from the GUI code. That work could be in 
C since it's mostly extract function refactors and the extracted functions have 
to be callable by the C GUI.

Part of that same job is to extract and combine the common code from Register 
and Register2; when Bob wrote it his vision was that the Reg2 stuff would work 
well enough that we could just drop Register, so he just copied the Register 
code and modified it. It didn't work out that way and it's become something of 
a maintenance headache because whenever we touch the guts of Register we have 
to remember to make the same changes in Register2. That hasn't always happened, 
so there are probably bugs that have been fixed in Register that still exist in 
Register2.

To start learning the code read through the Doxygen documentation at 
http://code.gnucash.org/docs/MASTER and browse the code at 
https://github.com/gnucash/gnucash.

For refreshing your C++ skills bear in mind that we're using C++11, templates, 
and shallow hierarchies (sometimes called "modern C++"). Have a look at 
http://wiki.gnucash.org/wiki/C%2B%2B, in particular 
http://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation.

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

GnuCash additional capability Translation

[Mohamed Yassin]

Hello Dears GnuCash,


I really appreciate your effort in free open source software, i came here now 
just today :)


and i see that there under feature:

GnuCash handles internationalized dates and currencies. The application's menus 
and popups have been translated to 21 languages, including Chinese, Danish, 
French, German, Hungarian, Italian, Japanese, Norwegian, Polish, Portuguese, 
Russian, Spanish, Swedish, Turkish, Ukrainian, and British English. 
Documentation is available in English, French, Portuguese and Spanish.


and i didn't find my language; Arabic language , So, i came want to contribute 
in Translation

i have a business and accounting background and working in IT field

and now if you like, from where i can start

Thank you . .

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

Re: Are There Plans For A GUI Overhaul?

[John Ralls]

> On Oct 5, 2016, at 6:34 AM, Dave  wrote:
> 
> Thanks for the great responses! It does clarify quite a bit.
> 
> 
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

I think the best leverage for an additional developer at this point would be to 
work on extracting the business logic from the GUI code. That work could be in 
C since it's mostly extract function refactors and the extracted functions have 
to be callable by the C GUI.

Part of that same job is to extract and combine the common code from Register 
and Register2; when Bob wrote it his vision was that the Reg2 stuff would work 
well enough that we could just drop Register, so he just copied the Register 
code and modified it. It didn't work out that way and it's become something of 
a maintenance headache because whenever we touch the guts of Register we have 
to remember to make the same changes in Register2. That hasn't always happened, 
so there are probably bugs that have been fixed in Register that still exist in 
Register2.

To start learning the code read through the Doxygen documentation at 
http://code.gnucash.org/docs/MASTER and browse the code at 
https://github.com/gnucash/gnucash.

For refreshing your C++ skills bear in mind that we're using C++11, templates, 
and shallow hierarchies (sometimes called "modern C++"). Have a look at 
http://wiki.gnucash.org/wiki/C%2B%2B, in particular 
http://wiki.gnucash.org/wiki/C%2B%2B#Developer_Preparation.

Regards,
John Ralls



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

Re: Custom .scm script: Query account balance

[John Ralls]

> On Oct 5, 2016, at 1:35 AM, Eric Wheeler  
> wrote:
> 
> On Tue, 4 Oct 2016, Derek Atkins wrote:
> 
>> Hi,
>> 
>> Eric Wheeler  writes:
>> 
>>> Hello all,
>>> 
>>> I would like to update our invoice .scm template to include a balance from 
>>> an account containing the customer's name (this is separate from any 
>>> accounts receivable, it is a retainer liability account).
>>> 
>>> I tried digging through the account piechart.scm and the taxinvoice.scm to 
>>> see if I can come up with a way to query the account something like this:
>>> 
>>> gnc:account-get-comm-balance-at-date append("Liabilities::Retainers::" 
>>> coyname)
>> 
>> First, you probably don't need the double-colons.
>> 
>>> But I'm not sure how to pass today's date. It's been years since I've 
>>> written scheme so any help would be greatly appreciated!
>> 
>> (current-time) ??   Or perhaps (localtime (current-time)) -- depending
>> on what you need.
> 
> I'm still trying to get to the point where I can specify an account 
> (hard-coded) by name in my report to get that account's balance.
> 
> I can map all of numerical values for balanaces, but they report all 0s 
> for all accounts. This makes me think that "current-time" is being 
> evaluated as the epoch, perhaps because it is an invalid data type for the 
> gnc:account-get-balance-at-date function.
> 
> Do you know how the gnc:account-get-balance-at-date function expects date 
> to be represented?
> 
> (display (append
>(map
>(lambda (x) (gnc:gnc-numeric-num (gnc:account-get-balance-at-date x 
> (current-time) 0)))
>(gnc-account-get-descendants-sorted (gnc-get-current-root-account))
>))
> )
> 


It's calling gnc:account-get-comm-balance-at-date 
(src/report/report-system/report-utilities.scm:462) which in turn sets the date 
in the query with xaccQueryAddDateMatchTS (ibid:489). That "TS" on the end 
means it's looking for a timespec, a struct containing an int64_t of seconds 
since the epoch and an int32_t of nanoseconds (always 0 in GnuCash, so we're 
working slowly on replacing timespecs with just an int64_t of seconds). You'll 
find functions for creating timespecs in src/app-utils/date-utilities.scm.

Regards,
John Ralls


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