Author: Dennis Kolva

In December our staff discovered a batch of C++ code online that makes spreadsheet-like tables for Windows. It didn’t take long to add their sample code to Goldenseal, and get it displaying a spreadsheet on the screen. It looked a lot like Excel for Windows 95, without the formulas. Not surprising, since the code was written back then.

Getting their code to be fully usable for our needs has been more challenging. Fortunately, we’re making steady progress on that. It really helps to see all the source files, and be able to change it.

First step was to remove unnecessary features. The ideal way to do that is to remove them one at a time, and test the code to make sure it still works after each removal.  Sadly, everything was too interconnected for that. So we hacked away and deleted everything all at once. Then spent a week fixing hundreds of error messages, until it worked again. Very similar to the demolition phase in a gut/rehab project.

With the raw framing exposed, we are now adapting the code to better suit Goldenseal’s needs. By the time it’s done, I suspect almost all will be rewritten. Some of the work is updating 90s code to modern standards. Some is plain old refactoring and redesign. For example, they store cells in columns then rows, but Goldenseal works better if they are in rows then columns. They use 0 for the first row, and we’d rather start with 1 like normal humans.

When we worked on the Mac version, Apple’s NSTableView class did have better overall design than the original Goldenseal. As we revise the Windows tables, it’s a chance to work in some of those improvements. This is the third batch of table code our staff has created, and each one is slightly better.

20 years ago, we thought Goldenseal would last for decades without big rewrites. Now we are more cynical realistic. The goal now is code that works well for the moment, and isn’t too difficult to adapt in the future.

Dennis Kolva
Programming Director
TurtleSoft.com

2020 has been a double whammy year for payroll tax calculations.

IRS changed the W-4 form. Instead of the number of exemptions, it now uses a complex calculation that involves dependents, student loans, multiple jobs and gross income. The only good news is that you won’t have to deal with any of it until the first time you hire someone in 2020. Then it’s just a one-time setup hassle.

We had to add a second set of tax tables to support the new forms: instructions here. Payroll will be more complicated for the next 5 or 10 years, until the day when IRS stops allowing the old forms. Then we can delete the old tables, and it will be simpler again.

Meanwhile, Canada also made a big change, replacing the personal deduction with a step table. We had to create a custom option in 2002 just to calculate Canadian withholding, and this change breaks it.

Revenue Canada has an insanely complex system to calculate withholding. The formulas use almost every letter in the alphabet, plus K1 to K4, T1 to T4, and 20 multi-letter codes. Ten different TurtleSoft employees worked on it and failed, before one finally figured it out. We are still slogging through the instructions to see how to make the new setup work. One of the calculation options for US states looks promising as a substitute.

As math nerds, we get especially frustrated by complexities like this, because it’s totally unnecessary. Tax dudes, you only need a few numbers to make it work!

Six US states have a simple flat tax rate for everyone. Most have a deductible, so taxation starts at some income greater than zero.  If you graph tax withheld vs income, it will be a straight line. Two numbers are enough to define that: one for the zero point, and one for the slope. In algebra, it’s y = a + bx.

Sales tax, gasoline tax and most other taxes are regressive. Poor people pay a higher percentage of their income on them, because rich people spend more on non-taxable stuff like school tuition and tax shelters. To compensate, it’s reasonable to have a progressive income tax. That means higher earners pay a higher percentage. If you graph tax withheld vs income, it will be a curve.

Mathematically, you can define progressive tax curves with three numbers: zero point, slope, and curvature. In algebra, it’s y = a + bx + cx^2 (the ^2 means x squared).

However, using exponents makes it too scary for most people. The easiest alternative is a step table, with different rates for each range of extra income. If you graph payroll tax vs income, it will be a series of straight lines that approximate the desired curve. Data-wise, it only needs two numbers for each step: start point and slope.

For any desired ‘tax curve’, it’s possible to make a series of steps that are accurate enough for tax policy. Most US states do exactly that, using anywhere from 2 to 12 steps.

Unfortunately, a few states add all sorts of weird stuff to make it more complex. Connecticut is an extreme example, with 13 different step tables arranged 6 layers deep. Presumably the tax committee was stoned when they created the Table C 3% Tax Rate Phase-Out Add-Back. Canada has a related problem: they really need some good tech writers to redo the tax guide, so humans can understand it.

Thankfully, we only spend a few days a year on payroll tax tables. Our staff will soon be back to more productive work, programming regular tables for Goldenseal Pro.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff is busy updating payroll tax tables for 2020. Sadly, US Federal income tax withholding has become much more complicated, due to a fairly small change.

New employees hired in 2020 or after will use a revised W-4 form. Their federal withholding then uses a different calculation method for gross income. Employees hired before 2020 will still use their original, old-style W-4 forms, unless they prefer to update.

To handle the change, we need to add a second US Federal Tax Item for the 2020 method. It also requires 3 new Tax Tables, plus an extra set of Tax Packages. The 2020 payroll import will add them automatically.

For states that use multiple Tax Packages, it’s going to be especially complicated: if there used to be 3 of them, now there will be 6. Users who have set up extra Tax Packages for child support or other complications may also need to revise them, and/or create new ones.

In your Employee accounts, you’ll need to assign different Tax Packages, depending on whether they use the old or new W-4. For employees using the 2020 W-4 forms, you’ll also need to enter a federal adjustment amount from the W-4, rather than the number of federal exemptions.

On top of all that, the IRS booklet uses an annual step table for the new calculation method. We used weekly tables in the past, but switched both versions to annual for 2020.  It’s bigger numbers, but ends up with the same results.

Most states use the W-4 for their own payroll taxes. Presumably they will also need to add a second calculation method. Most have not done that yet, but stay tuned. The chaos will probably reverberate for years.

Dennis Kolva
Programming Director
TurtleSoft.com

To build Goldenseal Pro for Windows, we use MFC (Microsoft Foundation Classes).  It does not include any table classes, but several other developers have written code for spreadsheet-like grids of text. After a few days of review, we chose one of the simplest. It’s basic, but easy to understand. Right now, our staff is gradually adapting it for our breakdown tables.

Step-by-step is the most productive way to get stuff working, when working with a new code library. We add something small, make sure it works, then proceed to the next step. If something goes wrong, just revert and try again. Right now our app shows an empty table, and we’re gradually filling it in.

I must say, that kind of steady, incremental progress is much more satisfying than what we experienced on the Mac version. Their NSTableView class seemed great, with many built-in features. But the charm soon wore off as we bogged down in the process of actually using it. Too many dead ends and baffling errors.

Fortunately, there was one good thing that came from the Mac  work. Some of the table interface never worked correctly, so we had to redesign it entirely. Instead of actions inside the table cells, it now uses buttons to add and delete rows, and pop-up data entry windows instead of editable table cells. That approach is easier to use for beginners, so we probably will use it for the Windows version also.

Dennis Kolva
Programming Director
TurtleSoft.com

When we first created Goldenseal, about 1/4 of the work was for resources rather than code. That means window layouts, menus, icons, and other cosmetic details that make up a modern GUI (Graphic User Interface).

The original Goldenseal resources were set up in Mac OS 9 format, which is now obsolete. We already converted most resources to newer formats, but a couple of the more difficult types were still undone. So we spent the past couple weeks hacking the current version of Goldenseal, to export the rest.

The hardest were the layouts for the action commands- Reconcile, Pay Bills, Write Payroll and a few others. They were stored in a binary format that the PowerPlant library could read, but not humans. Fortunately, we found a way to cheat. Loading each window also converts the data into text temporarily, with one line for each field, button or table. We then saved it into files for future use.

Both of the platforms we use have their own GUI for setting up window layouts. However, Xcode’s Interface Builder and Visual Studio’s wizards have many quirks, so it takes at least a day or two to set up each window. With 35 windows total, we’ll save time in the long run by reading the existing data from text. It’s a change that we have been meaning to do for a very long time.

The biggest challenges over the past couple weeks were with hardware. Building the current Goldenseal app requires Mac OS 10.5 , which means 10+ year old hardware that is showing its age.

Interestingly, for many years Apple made it relatively easy for us to update our code gradually after each system update. However, that stopped soon after  the iPhone was introduced in 2007.  We tried the usual update process with Snow Leopard in 2009, but it required such a huge code rewrite that we never finished it.  I would say that Apple’s neglect for the Macintosh has only accelerated since then.

Meanwhile, on the Windows side we are still slogging through setup details for fields and tables. It has been slow to get up to speed on the Windows programming, but the onset of gloomy weather will help with that.

Dennis Kolva
Programming Director
TurtleSoft.com

Microsoft has five or six different platforms for writing Windows software. You might say they are software hoarders, who rarely throw anything out. We looked through the choices a month ago, and got so confusing that we gave up, and decided to stick with MFC (Microsoft Foundation Classes). It’s what we previously used for the current version of Goldenseal. MFC is old, but it works. It will get the job done.

There have been very active discussions on the Apple developer list, the past couple months. Last week someone posted a link to Microsoft’s roadmap for WinUI 3. It looks great. Microsoft must have realized that their developer choices were a mess, and decided to put everything into one box.  It’s due next year, which probably means 2021. The fact that they are so transparent about the whole process is very reassuring.

By their roadmap we can write code in MFC now, and ship Goldenseal Pro for Windows in a year or so. Then gradually update it with their new libraries over the next few years. Because of their transparency, we are very confident about the long term future of Goldenseal Pro for Windows.

On the Macintosh side, it’s Opposite Land. Apple is very secretive about their plans. They have a new SwiftUI in the works, which uses their relatively new Swift programming language. Their goal is to have one set of programming tools that builds apps for iPhone, iPad, Macintosh, Apple Watch, Apple TV and any other hardware they come up with. But details about it are few.

Based on what we do know, it is extremely unlikely that we can move Goldenseal onto SwiftUI. It appears to be designed mostly for small single-window phone apps, not for software as complex as ours. It uses a new language that probably would mean an enormous code rewrite, even worse than what we already have done for their Cocoa library.

Will Apple have a way to connect existing C++ code to it? Or can we finish the Cocoa version in Objective-C, and convert it easily?  Will Apple keep supporting Cocoa, so we don’t have to convert at all?  Maybe.  There is speculation on the list, but nobody knows for sure.

It usually takes us years to write software. Then it takes years to sell enough to pay for the programming time. That makes it just too risky to be working without better knowledge.

Right now the future of our Macintosh software is very much in limbo.  I’ll post details, as we find out more about Apple’s future plans.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff is making progress on Goldenseal Pro for Windows. However, it will still take some time to get back to full speed. It’s easy to forget stuff after being elsewhere for two years. At least it’s already less frustrating than Cocoa was. We’ll be up the learning curve soon.

Since tables were the hardest thing on Macintosh, it makes sense to start work on them right away. Windows does not have a built-in table class, but we probably can adapt our existing C++ table code. We also are checking out a couple of open source libraries for it.

Goldenseal has 30 or 40 action windows to handle Reconcile, Pay Bills, Write Payroll and a few other commands. We set up one of them for the Mac version, and started a second one. That’s when we realized they would take a week or more apiece to build, or a good fraction of a year total. That was the last straw that convinced us to delay work on the Mac update.

The Windows version has the same issue. Fortunately, we just figured out a way to convert the existing screen layouts from Goldenseal into text files. We can read those and build the windows with generic code, rather than redo each layout individually, twice. It’s the same approach we already use for data entry screens, reports and printed forms.

As for the Macintosh version, Apple likes to burn bridges. Rumors are they will switch from Intel to their own chips next year. When that happens, it’s very possible they will retire the Cocoa library that we used for Goldenseal Pro, and replace it with an entirely new framework called SwiftUI. Right now it only runs on iOS, but Apple wants a single OS for all machines.  If that happens, I don’t know if we will ever be able to write a Goldenseal for SwiftUI. From the specs it seems even less friendly than Cocoa.

I personally have used Macs since 1985, and prefer them to Windows. But the many bridge-burnings are annoying, for users as well as developers. When I bought my current house in the mid-90s I made detailed blueprints in MacDraw, with layers for electrical, plumbing, HVAC etc. It has been handy for permits and planning. Sadly, MacDraw didn’t even make it from OS 9 to OS X, and our last old Mac that can open that file just died.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff has been posting comments to Apple’s developer mailing list, detailing some of the problems we’ve had with the 64-bit update for Macintosh. Some folks there reported similar problems. Some think we are lazy slobs for only starting work on it 5 years ago, instead of 10.

We plan to forward comments to Apple soon. Hopefully it will inspire them to make improvements to Cocoa before we finish the Windows update and move back to Mac. However, as a small company trying to steer a trillion-dollar one, we aren’t very optimistic that it will change anything. We’ll see how things look in a year or so.

The MFC library we use for the Windows version is rather old. Before committing to it fully, we spent a few days exploring other, newer development tools from Microsoft. Most of them are based on C# instead of the C++ that we used for the rest of Goldenseal. Despite the similarity in names, the languages are quite different. C# is more like Java. Its main feature is ‘managed memory’, meaning that programmers have to worry a bit less about crashes and memory leaks.

After some poking, we finally decided that MFC is still the best choice. So we are now programming Goldenseal for Windows in earnest.

Before we switched to Mac-only programming two years ago, we already had many things working in the Windows version. So our staff is off to a running start.

We are now finishing up a top ribbon that is similar to the ones in MS Office. That and the outline view will replace all the current menu commands. Similar to many other Windows apps, Goldenseal Pro won’t need a top menu bar at all.

After banging heads against Cocoa for more than two years, it feels really, really good to make steady progress again.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff restarted work on Goldenseal Pro for Windows last week, and it’s moving right along.

There are two cross-platform libraries that use one code base to run for both Mac and Windows: QT and wxWidgets. We checked them 5 years ago, but eventually decided to write native code instead. Last week we revisited them, since they might be a way to get a Mac version out more quickly. Both have improved, but they still have a steep learning curve. Their end results still don’t look as good as native. So I think we are better off continuing with MFC for Windows, and then returning to using Cocoa for Mac after that is finished.

One of our staff members posted to Apple’s Cocoa Developer mailing list last week, explaining the problems we have had. Several other companies responded with their own complaints.  We are not alone.

Apple has earned many, many billions from the iPhone. They probably feel a bit of hubris because of that. But maybe they will respond to developer feedback, and make Cocoa easier to use before we return to programming the Mac version. It would sure be nice for the work to go faster.

At the moment, the estimated timetable for Goldenseal and Goldenseal Pro looks like this:

2019:
Macintosh– Goldenseal runs on Mojave (OS 10.15) and anything earlier. It does NOT run on Catalina (OS 10.16)
Windows– Goldenseal runs on any current or recent Windows OS (XP, Vista, 7, 8, 8.1, 10). Some annoying screen problems caused by QuickTime dependence.

2020:
Macintosh- no change.
Windows– Goldenseal Pro released for current 64-bit Windows 10. Maybe also for some recent Windows versions. Easy platform swaps for Mac users.

2021 ?????:
Macintosh- Goldenseal Pro released.

Dennis Kolva
Programming Director
TurtleSoft.com

I sat down with a spreadsheet this week, and tried to estimate how long it will take to finish the Mac version of Goldenseal Pro. It said 6 to 8 months of small details, plus whatever new problems arise with the Cocoa library. Based on past experience, that’s probably another 2 or 3 months. Plus whatever I forgot, which could easily double the time estimate.

I also checked our past sales data: 64% were Goldenseal for Windows. Only 36% Goldenseal for Mac. That surprised me. I though it was closer to 50/50.

Our staff has struggled with Apple’s Cocoa library for more than 3 years, under pressure to finish the Mac version of Goldenseal Pro before 32-bit support ends in OS 10.16 Catalina. For the past two years we abandoned work on the Windows version and focused exclusively on Mac, trying to meet that deadline.

We failed. It wasn’t even close.  There has been far too much time spent on weird Cocoa problems. Not enough time spent on actual Goldenseal stuff.

It’s time to stop short-changing our Windows users. Our staff is shifting gears. We just put the Mac version on hiatus, and will focus on Goldenseal Pro for Windows until it is finished.

The Windows MFC library is much more compatible with our code. It uses the same programming language (C++). Its basic design is more similar. MFC and Cocoa are both 30 years old, but Microsoft has done a very good job of updating their code. Probably better than Apple has done with their Cocoa library.

Even better, some of the prep work we’ve done on the Mac version also applies to Windows. I would not be surprised if we finish Goldenseal Pro for Windows in less than a year. With hindsight, we should have followed this path two or three years ago, or at least kept working on both in parallel.

Meanwhile, Apple is planning to switch from Intel chips to their own ARM chips in 2020 or 2021. They are also working on something called Marzipan that merges iOS (for iPhone and iPad) and Mac OS. Apple has not announced details for either project yet, but odds are good that the changes will make life more difficult for us. One way or another. Maybe even impossible. That is yet another reason to delay the Mac work for a year. Better to throw away 3 years of effort if we are doomed, rather than 4 or 5.

Unfortunately, this decision means that our Mac users will need to stick with existing hardware that can run 10.15 Mojave or earlier, at least for a while. Every model currently available is fine, but future Macintosh models probably won’t support 32-bit apps like the current Goldenseal. I’m sorry. Unfortunately, the best we can do is make it easy to switch to the Windows app when that is ready.

Dennis Kolva
Programming Director
TurtleSoft.com