Are There Plans For A GUI Overhaul?

Ted Creedon tcreedon at
Wed Oct 5 14:13:17 EDT 2016

If you read and understand Scott Meyers books you're good to go.
From: rhymeswithdave at <rhymeswithdave at> on behalf of Dave <linuxluser at>
Sent: Wednesday, October 5, 2016 8:44 AM
To: Ted Creedon
Cc: John Ralls; gnucash-devel at
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 <tcreedon at<mailto:tcreedon at>> 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 < at< at>> on behalf of John Ralls <jralls at<mailto:jralls at>>
Sent: Wednesday, October 5, 2016 12:12:59 AM
To: Dave
Cc: gnucash-devel at<mailto:gnucash-devel at>
Subject: Re: Are There Plans For A GUI Overhaul?

> On Oct 5, 2016, at 6:34 AM, Dave <linuxluser at<mailto:linuxluser at>> 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 and browse the code at

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, in particular

John Ralls

gnucash-devel mailing list
gnucash-devel at<mailto:gnucash-devel at>


"The reasonable man adapts himself to the conditions that surround him... The unreasonable man adapts surrounding conditions to himself... All progress depends on the unreasonable man." Bernard Shaw

More information about the gnucash-devel mailing list