Category: Goldenseal news

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

Running a business is complicated. A construction business is more complicated than most, with plenty of quirks. Because of that, writing construction accounting and estimating software is a challenge. There’s always one more weird thing that needs to be handled.

To help keep the programmers sane amidst all that complexity, Goldenseal uses OOP: object-oriented programming. It uses code that looks more or less like the real world. With luck, OOP makes everything a bit more logical and easier to understand.

For example, to handle change orders, there’s a CChangeOrder class. It stores data for change orders, and does math and other tricks for them.

Object classes can have parents and siblings. The parent of a CChangeOrder is a CBreakdownTransaction (also the parent for all other transactions that have a breakdown table). Allowances have change orders as their parent. They inherit most of the same behavior as change orders, but tweak a few things that are different.

Our staff spends plenty of time designing objects and their contents. If it’s done well, coming back years later isn’t be too painful. Stuff still makes sense. If OOP is done poorly, then it turns out to be a confusing mess.

As we hook up Qt with our existing code, we find some of each.

All the data classes like CChangeOrder are great. No need to touch them at all. So far the database code is also working well.

Breakdown tables are more challenging. We had to write them from scratch in the original Goldenseal, so they have thousands of code lines for screen drawing, mouse clicks, and other interface details. Most of that is handled automatically by Qt table classes. Our staff is still figuring out what can be deleted from our old code, and what has to stay. Fortunately, we don’t need to clear out all the clutter right now. Sometimes it’s better to wait and be sure it really can be tossed. Sorta like cleaning the garage.

The hardest kind of OOP in Goldenseal is the link between what you see on the screen, and what’s stored on disk. We have a DB_RecordViewer class that handles that: record loading, saving, and everything in between. Its children are specialized to manage specific types of records: for example, CChangeOrderViewer for change orders.

As with tables, there is plenty of excess code in there. Newer frameworks already handle much of the nitty-gritty of screen display. We still need record viewers to handle the quirks, but they talk with a Qt object for most things.

Last winter we got records loading from disk onto the screen, and last week we got data saving from the screen back to disk. It’s coming along.

Dennis Kolva
Programming Director
TurtleSoft.com

What amazes me most about the recent real estate sale efforts is how little time some folks spent on a such a big purchase decision.

One buyer sent her sister to look at houses. She viewed by phone, liked the first house they visited, and made an immediate offer. The contract was signed and accepted the same morning. My house was third on their list so they never got that far.

There is a saying: “don’t marry someone until you’ve summered and wintered with them”. That may be a general rule that can apply to all decisions. If so, it probably needs to be adjusted for decision size. That rule of thumb calculates out to between 1.75% and 5% of the final cost or investment, depending on how you figure seasons and marriage length.

If the logic is right, you should spend 30 to 90 seconds deciding where to eat lunch. A $100 tool deserves 4 to 10 minutes of thought. It’s worth 35 minutes to 1.5 hours of research for a $1000 computer setup, and 23 to 70 hours for a $40K truck. A $300K house purchase ought to get 170 to 500 hours of planning.

You can plug in your own numbers: the spreadsheet is at this link. My guess is that most people over-think small decisions, and under-think the big ones.

I’m still looking at Zillow and Realtor.com daily, in prep for a sale/purchase in March 2022. It will be a more educated decision then. The past few months I was busy finishing up construction work, and didn’t spend 170 hours on buying research. Maybe I can summer and winter with some of the fixer-uppers that are still unsold, and get a better sense of their flaws. Kinda like dating, with hunks of wood and masonry.

Meanwhile, our staff is back to making progress on Goldenseal Pro. Last week we hit a big milestone: smart fields now pop up a list of items when in a breakdown table. It’s a small bit of interface, but we never were able to make it work in Cocoa for Macintosh. MFC for Windows was even worse: we never got tables to work there at all.

Doing it in Qt took a few days of futzing, but that’s not bad. Most likely, everything that we need to do will be possible with Qt. Just a matter of time.

Dennis Kolva
Programming Director
TurtleSoft.com

Goldenseal estimating and accounting software is built from three components. There is C++ source code that runs business functions and the user interface. There’s construction accounting and estimating data in the starter files. And in between, there are resources: text, layouts, icons and other program details.

The source code is compiled into machine language, with no easy way to see it. The estimating data is totally visible and easy to change. Resources are in between.

In the original Goldenseal for Mac, resources were built into the app file. Anyone could use an app called ResEdit to change them. One user actually converted all the text to Spanish. Other changes were possible if you hacked the right resources. Sadly, ResEdit never made it out of Mac OS 9. It was still possible to hack Goldenseal while it ran on PPC Macs, but the switch to Intel zapped all user access to resources. Meanwhile, the Windows version never had resource access at all.

We are still trying to figure how best to handle resources in Goldenseal Pro.

These days, the Mac hides resources inside what’s called a package or bundle. You can see the resources for any app: just right-click on the icon and choose Show Package Contents from the menu. Early on we wrote temporary code that exported all the resources out of the current Goldenseal, and into the Pro version. Those resources were in the bundle, and user accessible.

Apple really likes XML as a way to store data (it’s similar to the HTML that builds web pages). We tried XML at first, but didn’t like it. The text is hard to read: stuff like <tag><anothertag>blahblahblah</anothertag></tag>. Just one wrong punctuation mark, and it crashes. So, we switched everything to plain text. It’s easy to edit in Excel or TextEdit, and reads are 10x to 100x faster.

Qt also manages resources. It wasn’t hard to re-use most of the existing stuff when we switched over. Unfortunately, Qt hides them somewhere. If you open the app bundle, they aren’t visible. There may be some way to make Qt resources act more like Cocoa, but so far we haven’t discovered the secret.

It may be a moot point. Apple has toughened its security: to run Goldenseal Pro on newer Macs we must jump through hoops to guarantee that the app comes from a legitimate source. That probably means that users can’t hack app resources any more. The changes will be considered a security threat and it just won’t run.

We could store resources and other data outside the app bundle, but that makes installation and updates more difficult. Having just two things to keep track of (app and company file) is simpler for everyone.

Aside from the Goldenseal app, there is also your own accounting data, stored in your company file. One of the first things we wrote was a translator which converts existing Goldenseal files into Goldenseal Pro format. It even makes a few improvements along the way.

There is one piece of data that gets lost in the move: pictures. The current Goldenseal stores them in an obsolete format (PICT) which neither Cocoa nor Qt support. Fortunately, there are websites that convert PICT files to .jpg, .png or whatever. When we launch the Pro version we’ll provide links and instructions so you can salvage any pictures you may have stashed away.

Dennis Kolva
Programming Director
TurtleSoft.com

After two weeks, Custom Layouts is starting to look like something. It loads fields. You can drag them around on the screen. Click a tool, and you can add a new field. The app is already further along than we ever got with the Cocoa version.

Unfortunately, there isn’t any Qt sample code for doing a MacDraw-like environment. We’ll have to create most of the interface from scratch. None of it is real hard to write, but there are many fussy details. Undo in particular is a PITA.

The original Custom Layouts command needed at least one programmer-year to finish. Qt will be faster, but most likely it will take 2 or 3 months to get everything working well.

This stage of programming is a bit like starting rehab work on an old house. Sometimes you have to knock a few holes in the walls, just to see what the guts are like. Then you can get a better estimate of what’s needed. We kinda just did that with Custom Layouts. Now there’s a clear scope of work, and we know it’s doable.

Speaking of knocking holes, I must share a construction tale from an Ithaca rehab project in the 1980s. It was a small, odd house that had been owned by a custodian who worked at Cornell. The new owner wanted to remove a non-bearing wall to combine two rooms. I tried knocking holes to check for wiring, but couldn’t. It was plaster over an old door, with concrete fill behind it, then wood scraps nailed together, then plaster on the other side. Demolition was like an archeology dig through all the random building materials that someone brought home from work. Bricks, putty, roofing tiles, wadded newspaper, grout, tar, woods of all sorts. Too bad YouTube didn’t exist back then, because the demo (or the construction process) would be an amazing time-lapse video.

Anyhow, next on the agenda for Goldenseal Pro is the final untouched mode: action commands (Reconcile, Pay Bills, Deposit Funds, Project Billing, Sales Billing, Write Payroll, Job Costs). It definitely will be hard, because the current code sucks. Giving a complete overhaul to the interface has been on the to-do list for more than a decade.

The rest of Goldenseal uses Custom Layouts to arrange fields on the screen. It makes setup easy for our staff. It also lets users make changes. Action screens currently use a different system that is awkward for us. Users can’t change anything there at all. Since we have to rewrite anyhow, now is the time to switch them over to the Custom Layouts system.

Our staff probably will be working on the two areas in parallel for a while. If it gets too frustrating, we’ll take a break and work on other, simpler loose ends.

Meanwhile, this winter I’ve been doing major interior work on my house. In 2 or 3 weeks it will be ready to list and sell. This area is in a seller’s market for single-family homes, so it probably will go fast. I’m already looking at fixer-uppers to replace it.

The current house was built in 1910, right after the chestnut blight came through. Chestnut lumber was cheap for a while, so they used it for all the trim work. I wouldn’t mind finding another house from the same era. Chestnut looks great, and it’s easy to work with. Too bad it’s now a fossil.

If the next house needs trim or flooring, I’ll put in ash. This century’s cheap hardwood caused by a major species loss.

Unfortunately, the whole selling, buying and moving process may cut into programming progress for a couple months. We’ll see.

Dennis Kolva
Programming Director
TurtleSoft.com

Our estimating and accounting software has five different modes. Three of them are now working: data entry, Find command, and reports.

That doesn’t mean the project is 60% finished. Our rule of thumb: this stage is the first 1/3 of the work. The second 1/3 is finishing all the little details. The final 1/3 is testing and debugging.

Building software is similar to building a house. We did foundation work last Fall. Now three wings out of five are framed up and closed in. The app is starting to look like the architect’s drawing, but it’s not too late to tweak the floor plan. There is still plenty of utility and finish work to do.

It took a couple months to get the basic app window set up. Data entry screens needed a couple more months. Find and reports only required a week or so apiece. The two remaining modes (layouts and action screens) will be somewhere in between.

While working on the new Qt code, we often step through the old, partly-finished Cocoa version to recall how it works. No sense in re-inventing any wheels. If there’s nothing useful in the Cocoa app, we can also go back and step through source code for the current Goldenseal.

Back when we stopped work on the Cocoa version, I estimated that it was 1/2 to 2/3 complete. However, stuff keeps turning up that was never even started. That estimate probably was too optimistic. While struggling with Cocoa every day, I guess it was hard to see what a morass it was. Not seeing the forest for the trees.

Last week our staff worked on Reports. To see a report in the current Goldenseal, you choose something from the Reports menu at the top of the screen. It’s way over on the far right, so people often miss it. In Goldenseal Pro, there is a Reports button right on the main window. It makes navigation easier. From then on, the interface is similar.

We just started on the 4th mode: Layouts. It lets you change the appearance of data entry screens, printed forms and reports. In the current Goldenseal you get there via Options–Custom Layouts. Another nifty feature that is tucked away and hard to find. In Goldenseal Pro, it also gets a button on the main screen.

Custom Layouts was one of the first components we built in the current Goldenseal, back in the mid-1990s. It allowed the project manager (me) to design the app, while the programmers were writing C++ code to make it work.

It would also be nice to have Custom Layouts right away in Goldenseal Pro. Then we can adjust the current layouts for bigger screens.

Apple has sample source code for a drawing app that is very similar. We had high hopes it would make the work easy for the Cocoa version. Unfortunately, the sample code was old and unusable. As the project bogged down, we finally decided to skip Layouts entirely for version 1.0.

Based on results so far, I am optimistic that Custom Layouts will be easier to create in Qt. We’ll know better about that in a few weeks.

Goldenseal’s layout mode is similar to the MacDraw program on early Macs. That app never made it to OS X. Too bad, since I had useful data in MacDraw files: house plans, travel maps, flow charts, ad layouts. There was never a great replacement.

If Qt is not too much of a struggle, it will be tempting to spin off a MacDraw clone some day.

Dennis Kolva
Programming Director
TurtleSoft.com

Accounting software is all about accounts: the people and companies you do business with. There may be hundreds or thousands of them. MacNail Accounting, our first attempt at job costing software, gave everyone a number. Data entry meant using a printed cheat sheet (or memorizing numbers). It was easy to make mistakes.

For Goldenseal, we found a better way: clairvoyant fields. They pop up a list of items when you start to type, so you can just use regular names for your accounts. Usually you type a few letters, and get what you want. Worst case, you scroll through a list or use a pop-up button.

Goldenseal Pro still has the same thing, but with a name change to smart fields. They are an important part of our estimating and accounting software.

For example, when you enter a Material Purchase, smart fields link it to a vendor account, sales tax rate, payment method and payment terms. They allocate job costs to a project, cost category and subcategory. Smart fields may also tie the expense to an allowance, bid, change order, room, unit or project phase.

Goldenseal does useful stuff with all those links. It sets up Accounts Payable, or pays the vendor instantly. It gives you expense reports and job cost reports. It does time & materials billing for projects. If you include an itemized breakdown, it updates material prices for future estimates.

You may interact with smart fields hundreds of times per day. Because of that, they need to perform well. It took some effort to make that happen in the current Goldenseal.

Last week we used the Qt framework to set up smart fields for Goldenseal Pro. After a couple days they already look great, and perform properly.

Smart fields are the last interface detail we were worried about. As a tool for finishing Goldenseal Pro, Qt has aced the test. It’s going to build the new 64-bit interface on a reasonable schedule. Wheee!

For the short term, the question is: how long will it take to finish? We don’t have enough experience with Qt to answer that yet. It took 3 years with Cocoa to get roughly half to 2/3 done. So far, programming with Qt has gone about 4x faster than Cocoa. If that math continues, the best guess is another year or so.

One uncertainty is Apple’s new M1 chip. We won’t have to change our code for it, but the Qt framework needs an update to run natively there. Qt is mostly open-source, and folks are working on M1 compatibility now. They probably will finish before we do. It helps that TurtleSoft doesn’t use anything fancy in Qt— just the basics. BTW that need to rewrite for M1 is a big part of why we decided to halt Cocoa development. It was last straw on camel’s back.

For the medium term of five to ten years, my biggest concern is that the Qt Company probably will get bought. It could be swallowed by any big fish that sees strategic value in them: Apple, Google, Microsoft, Oracle. Nokia owned Qt for a while, and maybe they will re-buy before they get swallowed. With luck the actual Qt framework won’t suffer too much from assimilation, so we’ll get a 10 year lifetime or more.

For the real long term, we’ve found out the hard way that long term planning does not exist for software. It’s risky to rely on any small or medium-sized company: they often disappear. It’s risky to rely on the big players: their frameworks and tools often disappear (or become useless). Maybe things will settle down some decade, but probably not soon.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff started work on breakdown tables last week. After two days, they already looked great. Values filled into cells. Text was editable. General appearance about the same as our current accounting software. Even better, the code (QTableWidget) was easy to understand. It got the job done without too much sweat. That is a very, very good sign.

It took a month to get to the same place using Cocoa for Macintosh. NSTableView has many built-in features, but it is complicated and hard to adapt. There were many quirks to overcome.

MFC for Windows was even worse. They don’t have a built-in table class at all. We found a few libraries to make a grid of cells, but they were ancient and buggy. So we started to write a table class from scratch, but then the pandemic hit. The break gave us time to realize that MFC was just not going to work out. It’s too old, and too creaky. Hence the pivot to QT.

Breakdown tables are not completely done in the QT version, but they are good enough for now. We’ll come back and finish them later. The plan is to get past all the potential deal-killers at the beginning, before investing too much time.

Next on the list is smart fields (called clairvoyant fields in the current Goldenseal). Those have a popup button that shows a list of projects, vendors or whatever. You can click the button and choose one. Or you can tab into a field and type the first few letters, or start typing then choose from a scrolling list. It’s ideal for accounting software, where everything links to other stuff.

The basic design for smart fields came from Bruce Tognazzini at Apple, one of their human interface gurus. He called it a disambiguating field.

Cocoa has something called a combo box. It is similar, so at first we thought it might be Tog’s design brought to life. We fiddled with NSComboBox for weeks before realizing it wouldn’t work. Close, but users could type in things not on the list, and there was no way to prevent it. No good way to deal with it. We ended up building smart fields from three components, just like in the current Goldenseal. There’s a text field, a popup button next to it, plus a scrolling list that pops down when you start to type.

MFC also has combo boxes, but with the same basic problem. QT has them too, but they are even less adaptable than in Cocoa or MFC. Being worse was better, since it was obvious they’d never work. We didn’t waste time trying.

This will be the 4th time we build 3-part smart fields, so it probably won’t take very long to get them working.

Breakdown tables use smart fields. For example, for each line item in an estimate there are three: Category, Subcategory, and Cost Item. Each row in a construction estimate can show all sorts of stuff, so the code to manage them is very complicated. It’s a collision of many complex things.

In the Cocoa version, we never managed to get smart fields to work properly when in tables. The eventual solution was to have a pop-up window to enter each line item, instead of doing it inside the table row. That turned out to be a nice interface. We may use it for the QT version also. Not so cramped as working in little table cells.

If QT is very cooperative, we could do it both ways. Then users can choose which they prefer.

Dennis Kolva
Programming Director
TurtleSoft.com