Month: March 2017

Back in Summer 2014 we realized that Goldenseal needed a major overhaul. Apple stopped updating the Carbon and QuickTime frameworks that we used, so it was just a matter of time until it stopped working.  We searched for and tried out several different subcontractors to rewrite the GUI (graphic user interface).

Meanwhile, our staff finished one additional update to Goldenseal, but then started to refactor the existing code. The first thing was to remove old crud left over from 68K Macs. Then we converted 32-bit code to 64-bit, removed anything dependent on the doomed Carbon and QuickTime, replaced the NeoAccess database, and eliminated most of the old PowerPlant framework.

Last September we gave up on subcontractors, and started GUI programming in-house. For that we use the Cocoa and MFC frameworks for Mac & Windows, respectively. However, we probably still spend half our time refactoring the existing code.

Refactoring is a lot like remodeling an old house. Some things we tear out and replace. Some, we scrape off the crud and leave them. Our rule of thumb for refactoring was expressed very clearly this week in The Daily WTF: “Thinking is hard, and I’m not very good at it. Every block of code should be simple and obvious, because if it makes me think, I’ll probably screw it up and break something.”

This week we are replacing the PowerPlant array classes. The analogy for that is more like tearing out the main beams, because they are used everywhere. We wrote a replacement more than a year ago, and have used it in new code long enough that it’s well-tested.  Now it’s time to shift over entirely.

Refactoring is also a chance to make design changes. The maximum array length is currently a 32-bit number (4 billion max) but we probably will make it 64-bit (9 quintillion).  Nobody will ever need the extra space, but it may help us stay compatible with future CPUs.

Meanwhile, we’ve finished about half of of the Mac data entry interface. It now allows a main window and/or separate windows, and shows almost all of the fields.  The only hard things left are the tables, used in itemized estimates etc. One is starting to work, and we’re gaining on the others.  Best guess is a few more weeks until we release an ‘alpha’ version for folks to try out.

Dennis Kolva
Programming Director
TurtleSoft.com

In movies, programmers usually sit at a terminal and type pages of dense computer code, at breakneck speed.

In reality, programming new GUI code tends to go more like this:

1. Try a few Google searches to see if someone has written a tutorial on how to make the new thing.  If not, search Stack Overflow for related questions.
2.  If that is not enough, look through the list of Cocoa or MFC classes for anything already designed to do the new thing.  Search again for tutorials on how to use those.
3. If desperate, check the indexes of a few reference books. Try more searches with slightly different words.  Or give up, and try a completely different approach.
4. After getting a vague idea of how to proceed, search Google and GitHub for sample code.  Apple and Microsoft both have tons.
5. If there are sample projects, run them and see if they do the job.  If so, step through the code in the debugger and try to understand it.
6. If no samples, search.  Probably some smaller code samples, somewhere.
7. Copy/paste the likeliest code into the actual project.  Tweak as necessary.  If totally desperate, write a few lines of brand new code. It rarely takes more than 5 or 6 lines to do the job. Often it’s just 1 or 2.
8. Run it and see if it works.  If not, step through the code in the debugger and find where it breaks.
9. Test it, tweak it, test some more, tweak some more.  This requires a small amount of typing, but most of the time is spent running the program, dozens or hundreds of times per day.
10. In some cases, throw it all out and try a different approach. Repeat steps 1 to 9.

If it weren’t for debuggers, it would be nearly impossible to write complex software. “Debugger” sounds like something you can wave at bugs to kill them, but unfortunately it’s not that easy.  Instead, you set a “break point”, then run the program. When it gets to the break, you step through one line at a time, and see exactly what changes when.  Sometimes the problem is obvious, and sometimes it takes many trials.

Dennis Kolva
Programming Director
TurtleSoft.com

We are making gradual progress on the new Macintosh interface. Here’s a screen shot link showing what it looks like now:

http://www.turtlesoft.com/GS-Pro-Window.png

There is an outline view on the left that replaces all the old pull-down menus. There’s a “book” to navigate through records, and tabs at the bottom to switch between what used to be separate windows.  We will still let you open multiple windows, but they will be optional.

When we first started the Pro update, the plan was to have subcontractors rewrite Carbon to Cocoa (Mac) and QuickTime to MFC (Windows), keeping the same appearance.   That way the contract specs were easy, since it just had to match what we already had.  The plan was to start redesign work after the conversion was finished.

Now that we’re doing the work in-house, it makes more sense to combine the redesign with the general code updating.  So far we have made many more changes than first expected, but it’s also looking much better than expected.

Cocoa is not easy to master, and it probably will take us at least another month before all the basics are working on the Mac version.  No insurmountable problems, but there are many details that each take a day or two to finish.  Fortunately, we only have to do this once.  It’s going to be a real pleasure when we can get back to writing plain old C++ business code.

Dennis Kolva
Programming Director
Turtle Creek Software

Last week we added top controls to the Mac version, so it looked sort of like a Windows ribbon. It didn’t take long to find that it was too cluttered, and not all that useful.  So the main window got one more redesign, and we are quite happy with the final product.  It’s possible we will remove ribbons from the Windows app also, but we’ll get the Mac interface further along before we go back and decide on the final Windows appearance.  It’s kind of a leap-frog process, jumping between platforms every few weeks.

There is still one big design issue left, which is the breakdown tables for itemizing smaller details in Estimates and other records. 

When we first wrote Goldenseal estimating/accounting software, none of the C++ libraries had good tables. We had to write that interface from scratch, and probably spent a programmer-year or two on it.  Tables have complicated code that has not aged well. Fortunately, both Cocoa and MFC have mature table classes.  We can get reliable appearance, scroll-wheel support, column sorting, and other pleasant features for much less work than the original.

The big design question is, where to put them?  Currently, Goldenseal switches between entirely different layouts when you click the Breakdown popup on the left side of the screen. There are at least two different types of tables that can sit below the other fields, plus a no-table view.

Many users have found that system confusing, so we probably will simplify to a single layout, with just one type of breakdown table. Cocoa has “drawers” that can open out to the right, and that seems like a great place to put the (optional) breakdowns.  It fits particularly well with the new single-window setup, and today’s wider screens.

Dennis Kolva
Programming Director
Turtlesoft.com