Goldenseal Pro Progress (Oct 5)

Our staff has made some progress on Goldenseal Pro: text fields now fill in values, and popup fields get menus. QT is still working well, and I’m very optimistic that we’ll be successful with it.

However, our staff has mostly been busy with other things, the past couple weeks. The rest of October will be similar, before we get back on track.

First of all, TurtleSoft is moving to a less Covid-risky office. At the moment everything is boxes and disassembled shelving. The chaos will get worse before it gets better.

I also finished re-roofing my house last week. It was a big project that started in late May: removing 3 layers of ancient asphalt shingle from a 12:12 pitch, then installing new metal panels. I also added a couple of skylights in the attic. There’s still a small shed roof to finish on the rear, but that should only take a few days. It’s the first roofing project I’ve done with scaffolding rather than ladders, and the process was so much safer and more pleasant. Well worth the extra setup and take-down time.

Getting back into major construction work was satisfying. 20 to 25 hours a week of physical work seems like the sweet spot: enough to get very fit, but not enough for serious back and joint pains. So, I’m planning to finish some interior work over the next few months, then sell the place and buy another fixer-upper. Then repeat the process every five years or so.

For most of its lifetime, TurtleSoft has been a part-time operation. This really isn’t a change from how it’s always been here. Sometimes there are spurts, and sometimes gaps. Goldenseal Pro will be spurting again soon enough.

Dennis Kolva
Programming Director

Goldenseal Pro Progress (Sept 14)

Our staff is gradually getting Goldenseal Pro to run, using the QT framework. Right now the app launches, opens files, and fills in a list of accounts and transaction types on the left side of the main window. Next step is to get it to load layouts into tabs on the right. That’s the most important part of the interface for Goldenseal Pro.

Back when we attempted to use Apple’s Cocoa framework, it took two or three months to get this far. So far, progress seems faster with QT, despite spending fewer hours per week. Some of speed increase is because we can reuse previous programming, or at least the logic behind it. Some is because we don’t have to futz with two different programming languages.

We currently are working mostly on Macs, but the same code also runs on Windows. Most likely we will alternate between them.

People warned us that QT is bloated, and they weren’t kidding. I found a list of all the QT classes: there are 1,718 of them. In comparison, Apple’s Cocoa has 654 classes, and Microsoft’s MFC has 475. I put all the QT stuff into a spreadsheet and narrowed it down to things that we might actually use. That gets it to a couple hundred.

In the past few years we used both Cocoa and MFC to build Goldenseal Pro, and failed completely. Not the first time we’ve had to toss months or years of work. Since 1987, our staff has tried about 20 different frameworks for building desktop apps. Only three resulted in actual apps: Microsoft Excel (MacNail), Apple HyperCard (BidMagic), and Metrowerks PowerPlant (the current Goldenseal). All three of them were productive right from the start. So far, QT feels the same way. Despite the bloat, it works. It’s not painful to use. Success is not guaranteed, but I’m more optimistic that we will finish this time.

The real test will be breakdown tables. If necessary we can use the work-arounds already developed for Cocoa, but it would be better if we can have something closer to the current interface. It probably will be 2 or 3 months until we get that far.

Dennis Kolva
Programming Director

Goldenseal Pro: QT Creator (Aug 24)

In the movies, programmers type hundreds of code lines at a furious pace. Then they hit a button, and it saves the world/hacks into the FBI/some other dramatic theme.

There may be non-movie programmers who can program like that, but I’m not one of them. I’ve never met anyone who can do it in real life, either. We mortals spend 10% of our time writing a few lines of code (slowly). Then 90% figuring out why it doesn’t work. To help with that, we use an IDE (Integrated Development Environment). It’s a text editor that also runs the software, with tools for debugging.

A productive day of programming might have 100 cycles of write/run/debug. Multiply that by 100s or 1000s of programmer-days, and it’s almost like being married to the IDE. It’s as big a choice as which programming language to use.

For Macintosh, almost everyone uses Xcode: free software from Apple. For Windows, the main IDE is Visual Studio: free software from Microsoft. Both are OK but not great. I think a competitive environment would produce better quality IDEs, but nobody can compete against big-company and free.

QT comes with its own IDE: QT Creator. This past couple weeks, our staff has been migrating Goldenseal Pro into it. I have been cautiously skeptical about QT Creator, mostly because QT itself is a confused mishmash. There is a free, open source project, and also a company making a living from a commercial version. It’s an odd combination that could end up better then having huge corporate overlords, or it could be worse. Still too early to tell which it is.

Running code in an IDE is a three step process. First there’s a compiler, which checks everything for errors, and gives warnings for code that is suspicious but not deadly. If no fatal errors turn up in the compile step, the IDE then links everything into an app, and runs it. For step three you use the app, and see if it works right. If not, the debugger will step through the code bit by bit, so you can see if it’s working as expected. A fix might take minutes, or days.

Today we just finished getting Goldenseal Pro to compile. It meant eliminating about a thousand errors, mostly caused by old, obsolete code. Some could simply be tossed. Some could be rewritten immediately, with minor changes. The rest is just bypassed for now, until we see whether it’s needed or not.

The next step is pretty quick: fixing link errors probably won’t take more than a day or two. Then we start the long process of getting it all to run properly. For MFC my first guess was a year for that. It’s also a reasonable guess for the QT version.

Overall, QT Creator has its quirks, but it seems to function OK. I think our staff will get used to it.

Dennis Kolva
Programming Director

Goldenseal Pro & QT (Aug 10)

Our staff planned to spend the summer learning QT, but we soon discovered that it is very similar to other GUI frameworks we’ve already used. Much less to learn than expected. It’s time to jump right in.

To make the first steps easier, we cheated. Last week a subcontractor coded up the basic windows, using screen shots from the Cocoa version that we abandoned last year. He is a QT expert, so it only took a few days. The app runs on both Mac and Windows, and it looks pretty decent.

It’s nice to work with a framework that is based on modern C++. Apple’s Cocoa and Objective-C were just too quirky and weird. Microsoft’s MFC was far too old, and their new WinUI is still just vapor.

Right now we are checking the code, and deciding how to link in our existing accounting and estimating. The biggest challenge is figuring when & where to work on Goldenseal Pro. We definitely can’t subcontract the whole thing. Tried that once and it went nowhere. We know our own business software better than anyone, so it makes sense for our own programmers to do the work.

Problem is, Cornell and Ithaca College both decided to open in-person this Fall. Students are already starting to move in. Many are walking around without masks. Their parents are even worse. Some have come from states with many active infections. It makes life challenging for those of us over 60.

Even worse, the TurtleSoft office is in the densest part of town, sharing a four-story wooden stairway with nine other offices. Everyone shut down in March, but most are reopening gradually. People walk the halls and use the shared bathrooms without masks. The building dates from about 1890, so there is zero ventilation inside. I’m still trying to figure how to cope.

Personally, I maintain work/life balance by not having computers or Internet at home. That may need to change.

Meanwhile, I’m in a re-roofing groove. Just moved the scaffolding to finish the last bit on the east side of my house. The west side is more complicated because it has pipe flashings, rusted-out gutters, plus plans to add a couple skylights. The construction project will finish some time in September.

This early phase of software development requires plenty of head-scratching, design thought and planning. It probably won’t suffer much if it gets limited attention over the next month or so. As days get shorter and the weather grows worse, it will be easier to slither into a coding frenzy. Somewhere or another.

It’s still far too early to even guess at how long this software project will take. It’s the third attempt. Maybe we are getting better at it.

Dennis Kolva
Programming Director

Goldenseal Pro & QT: First Look (July 20)

Over the past few weeks, our staff has been learning the QT framework. It’s still too early to tell for sure if it will work for the new Goldenseal Pro accounting software, but at least it hasn’t been a disaster like Microsoft’s WinUI 2.4.

In 2015 we hired a contractor to build Goldenseal Pro with QT. He started with the C++ source code for the current Goldenseal, and gradually added QT interface code. With hindsight, that approach probably was a mistake. The project became too complicated, and I think he was soon overwhelmed. We paid him for the first draw, but the project stalled out soon after that.

What we will do instead is ignore our current code, and build the new interface completely in QT. If and when that looks good and works well, then it’s time to link in our existing code.

With that approach, we’ll waste less time if QT turns out to be a total dud. And we’ll have a better idea of its limitations, before we design the links between our code and the GUI human interface. I suspect that if we had done that with Apple’s Cocoa framework, we would have discovered its fatal flaws six months or a year more quickly.

QT does some weird stuff with the C++ language: that is one reason we decided not to continue with it, back in 2015. But since then we’ve dealt with even worse stuff in Apple’s Cocoa framework, and Microsoft’s MFC. Now the programming quirks in QT seem downright tame. We can get used to them. Five years of upgrades also helps.

I’m cautiously excited about the prospects of actually getting QT to work. It creates versions for both Mac and Windows, which is a big improvement from where we were ten months ago.

Of course, it will take at least another month or two before we’ve mastered QT enough to actually start using it. There are a couple more books to work through first.


There was a spell in the 1990s when TurtleSoft seriously considered selling out to a bigger competitor, and moving on to something new. One possibility was Timberline Software (the biggest construction software at the time). Discussions with them went in circles, and ended up nowhere. A couple years later I talked with one of their ex-salesmen at a trade show. He described them like this: “Timberline grew too fast. It created a vacuum in the middle, which sucked in layers upon layers of assholes.”

I suspect that same history may apply to Apple and Microsoft. They were young and feisty underdogs in the late 1980s. Our first products used their tools, which were productive and sometimes even fun to use. Now both companies are fat and arrogant monopolies, with too many layers in the middle.

QT is much smaller. We’ll soon find out if that helps.

Dennis Kolva
Programming Director

Goldenseal Pro Progress- Shifting Gears #2 (Jun 22)

A couple weeks ago we decided to switch gears, and use a very new framework (Windows UI 2.4) to build Goldenseal Pro for Windows, rather than a very old one (MFC).

When learning a new system, it always helps to start with sample apps. In fact, the ideal way to create a new app is to start with something that already works, and then add to it one step at a time.

So we downloaded a few samples and tried to build them. They needed other Microsoft libraries to run, so we downloaded and installed those. Then they needed even more libraries, using something called NuGet. Running it just gave mystery error messages: probably because it couldn’t find the necessary files on Microsoft’s servers. We searched the web for answers, tried a half dozen suggestions, and got nowhere. Dead in the water.

It’s a really bad sign when you spend 10 or 20 hours on something and can’t even get started.

These days, neither Microsoft nor Apple do a very good job with their programming tools. Fortunately, most frameworks have an ecosystem of books, websites, videos and Stack Overflow answers to assist us developers. Very few of those exist for Win UI 2.4. It is just not ready for prime time. Since it’s sort of a temporary filler, it probably never will be ready. My first impression was that it seemed half-baked, and now that suspicion is confirmed.

I think we will be better off waiting for Win UI 3.0. It is a bigger update and hopefully will have better support.

Win UI 3.0 is promised for some time later in 2020, which probably means 2021. It may not be fully usable until 2022. That’s still quicker than we probably can manage using MFC, so the most logical course is to just wait it out. There really isn’t anything we can do right now to make Goldenseal Pro happen for Windows, at least not by using Microsoft frameworks.

Fortunately, there is another alternative: QT. Way back in 2015 we hired a subcontractor who specialized in QT, to build Goldenseal Pro for both Mac and Windows. He finished enough to receive one draw payment, then stalled out. But, maybe we can figure out how to make it work. Worst case, our staff gives up in disgust and we still wait for Win UI 3.0.

In theory, QT lets us write one batch of code that runs on Macintosh, Windows, and even Linux. QT is open source, and its volunteer programmers did the heavy lifting to convert from 32-bit to 64-bit on the Mac. Odds are good they’ll also make it run on the upcoming ARM chips. So QT is worth the try.

As with our original plan, it probably will take most of the summer to get the gears fully shifted. Run some samples, read some books, work through the tutorials.

Based on a quick look, QT seems like it’s a complex, confusing mess. Unfortunately, that is the state of all the other options, too. These days, all programming requires layers upon layers of other people’s code. It tends to be fragile, poorly maintained, and poorly documented. But having a support ecosystem helps a lot, and it does already exist for QT. Whether that is enough to make it usable, we will soon find out.

Dennis Kolva
Programming Director

Goldenseal Pro Progress- Shifting Gears (June 1)

We have not made much progress on Goldenseal Pro for Windows, ever since we closed as a non-essential business on March 23. Stepping back for a while made it clear that it’s time to shift gears.

Our original plan was to use MFC (Microsoft Foundation Classes) to build Goldenseal Pro for Windows. Best guess at that time was a year to finish. MFC dates from 1992, which is ancient in computer years. On the other hand, we already use some parts of it. Adding the rest seemed like it might be relatively easy.

Unfortunately, MFC really is just too darned old. Just about everything is awkward and painful. Just one example: for text, it may use LPSTR, LPCSTR, LPWSTR, LPCWSTR, LPTSTR, LPTCSTR, WCHAR or TCHAR, depending on the function. Choose the wrong one and the app shows garbage text, or crashes. It’s constantly frustrating, even with a cheat sheet.

Based on progress to date, it now looks like it will take 2 or 3 years to finish Goldenseal Pro, by using MFC. Maybe longer, since Covid-19 is likely to cause more delays.

Microsoft has other frameworks and programming tools that are newer than MFC. Most use C# or Visual Basic (their in-house programming languages). Last week I put all the options into a spreadsheet: 56 of them, and I probably missed a few. Everything from ADO to XAML. They have WCF, WPF and WF, but no WTF (though it ought to be there). Nothing has ever been retired: it’s the tech equivalent of a hoarder’s house.

The Windows team seems to be aware of the problem. WinUI 3 is their blueprint for a more orderly set of development tools. In theory, it will unite all the options into one flexible system, with much better support for C++ code such as ours. WinUI 3 just moved from ‘alpha’ to ‘preview’, whatever that means.

Originally, we planned to whip something out in MFC, and then gradually convert it to WinUI 3. Now it looks like it will be better to jump right into WinUI. We might as well experience the growing pains of a young platform, rather than the arthritis of a very old one.

Full release of WinUI 3 is probably still a year off, but there’s a half-baked WinUI 2.4 which we probably can start with.

It will take most of the summer for our staff to come to grips with the new plan. We will play around with sample projects, read books and online info, and then start on a prototype. We may need to learn C#. We may need to shift gears again, if Microsoft shifts theirs. We probably will need to make a few changes in Goldenseal’s interface, so it fits into their system.

Our lives would sure be easier if we could just write code once, and have it run on all desktops. So, I went back and looked again at cross-platform development tools, for the 4th or 5th time. QT and Wxwidgets are the best known, but there are a few others. This post sums up their problems in great detail. Somewhat cynical, but it’s the truth. Likewise for its picture of the fishes.

Dennis Kolva
Programming Director

Macintosh & ARM (Apr 23)

Bloomberg News reported today that Apple will start using their own A14 ARM chips in new Macintosh models. It will be a gradual transition away from Intel, starting in 2021.  This chip switch has been rumored for years.

Apple is “working on” a way to run current apps on the new chips. It’s almost certain to be similar to previous pivots (68000 to PPC, then PPC to Intel). First, there will be an emulator with mediocre performance. It gradually will get worse, then end after 5 to 7 years.

The future ARM Macs will be better at running iOS apps. That’s great if you want a big-screen, more powerful version of your iPhone or iPad. It’s not so great if you are running current Mac software.

Whether Goldenseal Pro will run on ARM Macs depends on Apple.

      • If they continue long-term support for Cocoa and Objective-C, then we can make it work with another year or two of effort. We’d start that when sure of Apple’s plans, and after the Windows version is done.
      • If Apple unveils something new for developers, then it depends on the details. Could be better, could be worse.
      • If Apple switches entirely to Swift and SwiftUI, there’s no way we can convert our code. After 33 years, it’ll be end of the line for our Mac version.
      • Ditto if Apple sorta supports Cocoa, but are half-assed about it. Cocoa is already a nightmare, and our staff is not eager to go back there. Since this is the likeliest case and Swift-only is 2nd, I’m glad we stopped work when we did. A waste of only 3 years instead of 4 or 5.

To keep current Mac users, Apple will need to support Microsoft Office and Adobe products for sure. Everyone else doesn’t matter very much. Specialty apps like ours don’t matter at all.

So, we just have to wait and see.

Dennis Kolva
Programming Director


Coronavirus & Table Clicks (Mar 24)

Here in New York, the Coronavirus storm is upon us. 20,875 cases with 15 locally, and growing. Ithaca is almost a ghost town. Hopefully it won’t get as bad here as in New York City.

The John Hopkins Covid-19 Tracker has gone back to tracking US cases for each county. It gives a clearer picture of where we all stand right now. Keeping that site updated must be a ton of work, and I really admire them for it. Last week it stalled out a lot, but they seem to have added servers to cope with the load.

The bad news is, confirmed cases are distributed throughout the entire US: big city, small city, suburban and rural. Right now it’s worst in NYC, then Seattle. However, everywhere else is only a week or two behind. Most of the regional differences are from lack of testing, rather than lack of infections.

The graph of the infection count keeps getting steeper. If you click to see the daily increase, it’s the same curve. The rate of increase in that one is also the same curve. Exponential growth works that way. The rate it gets faster keeps getting faster.

The way this pandemic plays out in each part of the US will depend a lot on the actions of state Governors and state/local health departments now. Balancing physical distancing with the need to get groceries and pay bills is going to be extremely challenging. We’re all in for some big changes.

Meanwhile, our staff has settled in to the new normal: isolated and ultra-cautious. We are back to programming, again.

A few weeks ago, two different types of tables were filling in data and looking pretty good. Then we clicked on one, and it crashed immediately, somewhere deep inside the MFC library.

It used to be possible to step through MFC source code to figure out problems like this. Unfortunately, that has become more difficult with newer versions of Windows. One option gave thousands of error messages in the compiler. The other option took hours to load up. Frustrating.

Luckily, taking a break from problems is often a good thing. Coming back afresh, we quickly found a nice CodeGuru explanation for the fix.  It only took a few minutes in the Class Wizard to get it working properly.

MFC is old and complicated. It’s going to be a slog. But we are making progress.

Dennis Kolva
Programming Director


Goldenseal Pro Progress- Tables & Beyond (Mar 2)

As of last week, breakdown tables are looking good in Goldenseal Pro for Windows. The code is clean and orderly. The appearance is pretty much as we’d like. It’s just a grid of little rectangles with text in them, but making that happen requires a surprising amount of code.

Many details are still unfinished, but our staff has moved on to other things for a while. There are several other types of tables in Goldenseal, and we might as well get them all working at the same time. We’ll come back to them after the entire interface is in place.

Table grids have a basic design issue: how do you enter data into the little boxes? Over the years, Microsoft Excel has approached it in two different ways: with a separate formula bar, and with an edit box that pops up when you click in a cell. Mac Finder and Windows Explorer edit in place after a delay, though it’s often easier to right-click and choose Rename.

The current version of Goldenseal also uses edit boxes that appear when you click. However, our tables are more complicated. Some cells are just text; some show a popup button and a menu list; some are check boxes or padlocks. It took a lot of programming time to get them working properly, and they still aren’t perfect.

When we worked on the Mac version last year, it was very hard to get edit-in-place fields working (especially for the smart fields that pop up a list of items). We finally gave up and tried a third approach: a separate window that pops up when you double-click in a row. Kinda like a little data entry window for a single breakdown item. It seemed like a big improvement over the current approach. Less cluttered, better use of space, easier to modify in the future. Most likely we will do the same thing for breakdown tables in the Windows version.

Right now we are working on Preferences, and the little windows that manage lists of payroll tax tables, cost categories, and many other details.

In the Mac version, there was a worrisome database bug that appeared when a breakdown table opened for the second time. Fortunately, it happened in the Windows version also, and it was easier to debug there. Working with code that is all in the same programming language really is easier. The bug wasn’t in the database code, after all. That was reassuring.

Dennis Kolva
Programming Director