Category: Goldenseal news

Deposit Funds now works properly. Another task done in the big accounting software rewrite. The action commands seem to take about a week apiece. There are five left to do, so they probably will take another month to finish.

The original Deposit Funds code dates from the late 1990s. It’s complicated. Deposits can come from projects, cash sales or billed sales. Later we added rental transactions. Still later we added events (used for our training classes). Sales branches also play a part.

Deposit Funds has a big data structure that gets passed around to each of those classes. It includes a list of accounts, each with their own list of details. Afterwards, the whole mess travels to a bank transaction to actually create a deposit. The code is scattered all over the place.

Bach then, our staff figured things out as we went along. Several people worked on Deposit Funds, spread out over several years. The code ended up as a bit of a Frankenstein. Revisiting it twenty years later, it was baffling. Construction accounting software will always be complicated, but this was much worse.

On top of all that, for the first few years Goldenseal had Payment Receipts. They were intermediate transactions in between sales or project bills, and deposits. Having them made everything twice as complicated and twice as confusing. We finally removed them, and used printed forms instead. Sadly, the code still lived on inside Deposit Funds. Payment Receipts were a bad idea, and it’s time to escape them.

One way to improve software is something called refactoring. Its goal is to make code less confusing and more reliable. To refactor you first break things, then fix them. It’s kinda like doing a gut/rehab construction project, except that the gutting part has to be gradual.

Step one is to remove one bit of code that doesn’t make sense. The compiler then complains, with a list of other code that it breaks. Step two, our staff looks at each error to figure out where and how the mystery code is used. Sometimes it isn’t even needed, so we can delete it. If not, step three is to rename the data and methods to make more sense. Maybe add some comments to explain the quirks. Get the compiler happy again. Then repeat for the next bit that’s confusing.

After a few days of refactoring, the Deposit Funds data structure was about half as big, and the code explained itself. It also was more similar to Pay Bills and Reconcile. That made it easier to connect to the Qt interface.

Sometimes refactoring fixes bugs. Sometimes it adds new ones. Ditto for a major rewrite like TurtleSoft Pro. So, we still need to test everything with real-world data. That phase is coming up soon.

The best way to alpha-test TurtleSoft Pro will be to run the TurtleSoft business with it. Right now is too early to switch over completely, but we’ll run the new code in parallel with the current Goldenseal for a while, and make sure they both act the same. Or in some cases, similar but improved.

It’s ready for that kind of testing now. But the process will work best by having two monitors and two mice/keyboards side by side. To accomplish that requires serious desk de-cluttering, or maybe another desk. Still figuring that out. It may mean moving some file cabinets.

Meanwhile, our programmers have moved on to Project Billing. In Goldenseal that is split up into five different menu commands. We probably can merge them in TurtleSoft Pro.

Dennis Kolva
Programming Director
TurtleSoft.com

Our accounting app has tons of C++ programming code for the business logic, data storage and human interface. However, there are places where C++ is the wrong tool for the job.

For example, it takes specialized apps to make sounds and pictures. Screen layouts are possible to build in code, but it’s much easier to design them in a drawing environment. Likewise, the text for menus, buttons and messages is better to store outside the source code. That way it’s easier to tweak them later, or translate them into other languages. All those extra details need to be attached to the software somehow.

During the first few years of Goldenseal development, I didn’t write any C++ code. It was a full-time job designing the estimating/accounting software, and creating icons, layouts, text, etc. At the time, Mac OS used an app called ResEdit to manage non-code resources. They were stored in a separate “resource fork” inside the app.

Mac users could change some details in Goldenseal with the help of ResEdit. It was a way to fix small bugs or customize features. One user translated all the Goldenseal text into Spanish with it. ResEdit died along with OS 9, but there is a free 32-bit app called Rezilla that also can modify Goldenseal resources. Use it at your own risk, and be sure to work on a copy of the app!

These days, software still has resources. Usually they are stored in many little files buried inside the app. Part of our work over the past five years has been converting old resources to new formats. A lot of them migrated into plain text files. We used XML for a while because that’s the current data fad, but simple tabbed text turned out to be easier to maintain, and faster to load.

The past few weeks our staff tackled the last few resource stragglers.

Many Goldenseal layouts have icon buttons. I drew some of them, pixel by pixel. Others were scanned in from a local artist’s ink sketches. They were “icon families” with 2 sizes and 3 color depths (1-bit, 4-bit and 8-bit). It was a relic of the early transition from black & white to color. There also were a few bigger graphics stored as PICT. Both those formats are long gone.

For Turtlesoft Pro, we converted the icons and other graphics via screen shots, cropped in Preview. They now are a couple hundred named files embedded inside the app. When we finish Custom Layouts, there will be an Icon Chooser so folks can add them to screen layouts.

The various clunk and bip and boop sounds were SND resources, also a dead format. There were how-to instructions for the conversion online. It required three different apps: one to read the raw data, one to move it to an in-between format, then a third to edit it into final form. Most survived the update, but a couple will need to be re-recorded.

Screen layouts for Reconcile, Pay Bills and other action commands were stored in yet another format. It was exclusive to CodeWarrior, the app first used to build Goldenseal. It also died twenty years ago. Our staff added code to Goldenseal so it would export layout specs into a text file. Then we edited it down to just table info: column widths, titles and other details. Now it’s much easier to maintain than the old system.

Will users be able to edit the new resources and customize Turtlesoft Pro? Maybe. There are two problems.

First of all, Qt has its own resource manager. It will be a while before we know whether it allows user access. Their final build system is very complicated, and we probably will hire a Qt expert to set it up.

Even worse, both Apple and Microsoft have increased app security. To run on newer OS versions, apps must be authorized and signed, or they won’t even run. Any user changes to the app would probably look like hacking, and be blocked as a security risk. We’ll know more about that after we start making release versions.

Meanwhile, Reconcile and Pay Bills look pretty good. We’re working on Deposit Funds now.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff has gradually been getting the Reconcile and Pay Bills commands to work. It has taken us down many different rabbit holes. Working on very old parts of the accounting software code.

When we started to program Goldenseal, the C++ language was young. Things like dates, time, currency and text required long stretches of home-made code to function. They are not simple.

Take money, for example. First of all, it’s important how you store it. Computers have “float” values for decimals, but they are dangerous for money amounts. The problem is, floats can’t store cents and other fractions precisely. It’s a basic number problem. 1/100 is not an even number of binary bits, so you can only get close to it, never exact. If you ever see something like $99.999999997 or $100.0000000013 on a website, their programmers used floats for money and forgot to round them.

For Goldenseal accounting, we wrote a CMoney class that stores dollars in 32-bit integers, and pennies in 16-bits. That way it’s exact. CMoney can handle up to $4 billion, and down to 1/100th of a penny. No risk of weird rounding errors. Some day we probably will switch to 64-bit integers and extend the ranges, but it will mean a ton of rewriting and testing, for not much gain.

Money has more quirks. There are dozens of currency symbols. Some are on the left, and some on the right. The decimal point may be a period, or a comma. The thousands separator may be a comma, period, something else, or nothing. In some countries the separators aren’t every 3 digits.

Back in the early 90s, we wrote a lot of raw C++ code to handle all that. Then Apple released easier ways to localize for different countries- money, dates, other stuff. We rewrote some of the interface to use that. Then rewrote it again for Cocoa. Now we are rewriting yet again to use Qt.

Each framework does basically the same stuff, but always with quirks and gotchas. For example, Qt has built-in currency formatting, but it only accepts floats. No option for integer dollars and pennies. It probably has built-in rounding to avoid the $99.999999997 problem, but maybe it doesn’t. We’ll have to test it to find out.

It’s also time to redo progress bars. When tasks take a long time, the current Goldenseal puts up a small window with a moving bar. Sometimes it has a Stop button. Everything runs faster now, so TurtleSoft Pro will just have a small built-in progress bar at the bottom of the window. Most of the time it will just flash by, and a pop-up box would be annoying. The new method is simpler, but it means rewriting about 100 different places that show the bar.

For the actual accounting work, the new interface connects with Reconcile and Pay Bills business logic that is 20 years old. To understand how those work, we use the debugger to step through the current Goldenseal source code. 32-bit Goldenseal runs on anything pre-2019, but the Xcode project that builds it requires pre-2009.

We were down to just two older Macs able to build the app, then one of those died. It’s getting too risky. Fortunately, there is plenty of older hardware on eBay. The challenge is to set them up with MacOS Leopard. Or else figure how to update the project so it runs on Snow Leopard, which is easier to find and install.

Fun trips down memory lane…

Dennis Kolva
Programming Director
TurtleSoft.com

This week our staff shifted gears again, and started work on Estimates. They have the most complicated interface in our estimating/accounting software, so it makes sense to tackle them now. Most likely it will take a few passes to get all the details finished.

The main estimating window has a row of buttons for dimensions, each with a small picture/icon. The first task was to get the icons to appear onscreen.

For 32-bit apps like the current Goldenseal, Macs store icons as resources inside the application. Our Windows version does the same, with the help of Apple QuickTime. Newer 64-bit frameworks take a totally different approach. Icons are now in regular graphics files, accessed with a URL. It’s just some text than can point to a web page, a file on the hard drive, or a resource file that’s buried inside the app.

Years ago, our staff used ResEdit to draw the Goldenseal icons, pixel by pixel. It took a few months, so we definitely don’t want to do them again. Fortunately, it wasn’t too hard to convert icons into the new URL format. We took screen shots, cropped them, then saved them into a couple hundred individual files.

There’s also another change: every resource used to have a ID number, but now it needs a file name and path. To handle that, we wrote a translator that links the old resource IDs to the new URLs. The icons now show up properly.

Larger pictures are more complicated. Right now, Goldenseal stores them inside the layouts as a PICT image. PICT used to be one of the most popular graphics formats, but now it’s totally defunct. Modern programming frameworks use .png, .jpg, .gif or .pdf files instead.

The only layouts with PICT images are in estimate dimensions. We’ll have to cheat and write one-time C++ code to place those correctly. Eventually we’ll add interface so users can paste in new images and move them around.

There’s one more place where the loss of PICT is an problem. Goldenseal lets users paste images into optional picture fields in some records. They are stored inside the company file as PICT data. So far we have not found any way to use them in Goldenseal Pro. Those images are in a dead, foreign language.

In the future, Goldenseal Pro probably will store user images as files in a folder somewhere. It’s more future-proof than adding raw data to the company file. Also, it will allow users to store scanned images and other big files, without making the company file enormous. The downside is that separate files can get lost more easily. URLs are great if nothing ever moves, but that’s asking a lot.

Updating our code to the 2020s takes effort, but it does have benefits. The URL system makes it much easier for us to open and save files. Not just the main company file: there’s also contracts, imports, exports, Save As Text. In the current Goldenseal, doing anything with files requires many lines of code and weird data structures that change every few years. Now it’s just a line or two and a simple URL.

We haven’t investigated the networking features in Qt yet, but the URL system probably will make that easier, too. It may help us create the ideal multi-user version: enter an IP address, and log into your company file over the web from any device.

Dennis Kolva
Programming Director
TurtleSoft.com

Since the last post, our staff has worked on the Layouts panel. It’s the successor to the Custom Layouts command in the current Goldenseal.

Last week, it took a day to get fields to move around when you click and drag, and to move in groups after shift-clicks.

Getting fields to show little black resizing squares took a few days. Then, two more days to draw the black squares in the right places during a move. The code has to check the mouse position many times a second, and redraw all the boxes in slightly different places. A lot of CPU just to move some dots around.

It took a day to figure how to right-align text, then a couple more days to get drags to resize the boxes properly. Drags were doing some crazy stuff until we fixed all the bad logic.

Spending a week on little dots may sound like excruciatingly slow progress, but actually it’s going quite well. Custom Layouts in the original Goldenseal consumed about two programmer-years. So far the pace is much faster with Qt. It probably only needs another month or two.

I think we can get Layouts functional by the first release. That’s a good thing, because most of the current windows will need tweaking to look good on bigger screens.

Different types of programming work seem to burn out different brain areas. It’s probably time to get away from Layouts, and move on to something else for a while. There are plenty of choices.

Meanwhile, active Covid-19 cases in the county suddenly jumped from 3 last week, to 57 yesterday. That’s worse than anything during summer 2020. It’s a junior version of what’s happening in many other parts of the US. Alas.

Dennis Kolva
Programming Director
TurtleSoft.com

As you run Goldenseal accounting software, the app creates all sorts of things that sit around in RAM. Some last a long time, and some are just temporary.

If we don’t delete temporary items when they are done, the app will gradually consume more and more RAM. It’s called a memory leak. Eventually the computer will get low on memory, and slow down. It may run out entirely, and crash.

If we delete too soon, the app may try to use something that doesn’t exist. That causes an instant crash.

Our code sends thousands of little things flying around on your CPU every second. Keeping them from leaking or crashing is one of the biggest challenges for programmers.

The C++ language does not manage memory automatically. Fortunately, there are ways to do it without much fuss. Thanks to careful programming, the current Goldenseal rarely crashes. It does leak 40 bytes of memory whenever you open a new window, but it will take months of constant use for that to become a problem. That’s an old PowerPlant bug that we’ll lose in Goldenseal Pro.

Qt manages memory by giving a parent to everything but top-level windows. When you quit or close the window, the parent deletes all its children. Those delete their children, and so on down the chain. The system works well. If we forget to give something a parent, it floats all by itself on the screen. Hard to miss.

Newer languages like Java, Python, Swift and Objective-C manage memory automatically. The problem is, there is no guaranteed way to do that unbreakably.

Most languages use some form of reference counting. When something else links to an object, it adds 1 to the count. When they are finished, the count decreases by 1. When there are zero references, it’s time to delete the object. Most languages wait for a while then delete everything at once: it’s called garbage collection. When an app suddenly stalls out for a second or two, it’s probably emptying its trash.

The biggest problem with reference counting is that it can’t handle circles. If two objects reference each other, deleting one of them will leave a dangling reference in the other. It won’t die when it should, which causes a leak.

In Python, you are just supposed to never make circular references. That’s not easy, because often it helps to have a two-way link. We use them all the time.

Cocoa has strong and weak references to handle the problem. We found it to be hard to set up, and even harder to debug. We spent several months tracking down weird memory problems when we used Cocoa, 2016 to 2019. Sometimes ‘easy’ really isn’t any easier.

Qt is completely C++. It’s kind of like going from an automatic transmission back to manual. No need to guess what the gearbox will decide to do.

Meanwhile, our staff took a break from breakdown tables this week, and switched over to Custom Layouts for a while. It’s a nice change of pace. There are plenty of tasks left to do, and no reason to finish them in any specific order.

Dennis Kolva
Programming Director
TurtleSoft.com

From 1989 until 2007, I taught classes for our estimating and accounting software. It was a good excuse to visit most parts of the US and Canada. The classes covered the Excel-based MacNail, then the current Goldenseal. Over 1000 users attended, and learned how to improve their businesses. I also learned first-hand what people found most confusing.

One problem area in Goldenseal was the two different ways you can itemize things in estimate and expense breakdowns. There are category breakdowns, where you just type stuff in. Also item breakdowns, where each line pops up a list of unit costs (Assemblies or Cost Items).

With hindsight, the split isn’t as useful as we first thought it would be. There still has to be a way to type unlisted things into a item breakdown. And category breakdowns still have to reference items like Bids and Allowances. They really aren’t different enough to be worth the extra fuss. Even worse, the names are rather confusing.

With Goldenseal Pro, we have a chance to fix some of the design flaws in the original Goldenseal. The category/item split is one of the worst. Goldenseal Pro will have just one type of breakdowns for estimates, expenses and sales. That’s one less thing to think about. One less thing to explain.

In Goldenseal Pro, if you want to pop up a material cost item, you’ll use a Material Item. If you want to type in a material, it’s Material Text. Ditto for labor, subcontractors, equipment or other costs. The names are revised from the current version, but they act the same otherwise.

This week we finished the code that converts old-style breakdowns to the new format. That way old data will still be usable. It probably will take a few more weeks to get all the little quirks working for breakdown tables. We can link into existing code for some of them, but some will be easier to just redo in Qt.

At first, testing showed weird errors. Eventually our staff discovered that for expenses, the menu doesn’t include the option to type in materials. For 20 years our testers never noticed it, and nobody ever reported it as a bug. I suspect it was because the whole category/item thing is so confusing. Nobody ever realized it was just a bug with an easy fix. Anyhow, it works properly now for Goldenseal Pro.

Breakdown tables are already further along than we ever got in our previous efforts with Cocoa and MFC. Progress is looking good. It’s just a matter of time.

BTW right now is the perfect time for users to tell us about any other frustrations with Goldenseal. It’s not too late for us to make design changes to improve it.

Dennis Kolva
Programming Director
TurtleSoft.com