Goldenseal Pro Progress Report- Table Views vs Cells (Mar 13)

Our staff is back to working on Goldenseal Pro. Right now we are focused on the little tables inside lists. It’s going well, with steady progress each day.

Working with Cocoa’s NSTableView class has been extremely frustrating the past few months, but I think we are finally over the hump.

About a year ago, it only took a few weeks to get the various tables to show data. Back then we were very optimistic. Unfortunately, creating a data entry interface turned out to be much, much harder than just displaying some text.

Apple has two different ways to set up tables: with cells or with views. Last year, we set up all the tables with cells. They are simpler, and we couldn’t find any sample code that used views. Unfortunately, since then we discovered that Apple has deprecated cell-based tables. That means they are officially obsolete, and will eventually stop working.

Because of that, we switched the list tables over to view-based. After everything is working properly there, it shouldn’t be too painful to go back and switch over the other tables, also. After all this effort, we really don’t want to start out with any outdated code in Goldenseal Pro.

During the past month, our staff spent many hours in Excel, fiddling with the spreadsheets that calculate pricing and page details for It was interesting to be writing Excel macros again! That is how TurtleSoft first began, back in the late 80s.

It was also interesting to work with the new Cocoa-based rewrite of Excel for Macintosh. It seems very clunky and awkward, compared to the previous Carbon versions. Maybe we aren’t the only ones who have struggled with NSTableView.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report (Feb 27)

There’s not much progress to report.

While finishing Goldenseal Pro, TurtleSoft has paid staff and bills by selling rare/retired Swiss Army knives and Leatherman tools on eBay. We have piles of them, purchased from airport confiscations in the Aughties. Cleaning and sorting multi-tools is a soothing break from programming.

A few weeks ago eBay decided to eliminate shipping of knives outside the US. That was about half our sales.  So we are finishing up the shopping cart on our SmartKnives website, a year earlier than planned.

Setup work was already close to completion, so it shouldn’t cause too long a delay. We ought to be back to full programming speed in a few weeks.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report- Tables (Feb 8)

Our staff is making decent progress on member tables (the relatively small tables found in a few accounts, and many lists). Simple ones now work properly. Next were the ‘to/from’ tables used in Tax Tables and a few other places. They are more complicated, but most features work in those now, also.

We also made a breakthrough on the breakdown tables used in Estimates and many other transactions. The current Goldenseal uses two types of tables: category breakdowns let you type in a list of items, while item breakdowns have a list of Assemblies or Cost Items. The difference is not obvious, and it often confuses users. Their code also overlaps by quite a bit. Category breakdowns still need to show allowances and bids, while item breakdowns sometimes use type0ins.

Last year, we decided to combine them into just one type of table. Merging them was not too hard, but they still seemed a bit too complicated.

For example, in Estimates there are 37 possible types of line items. It makes for a very long list of choices in the pop-up menu. Overwhelming. It was also difficult to find short phrases to describe each option properly. The merged version is even worse.

The breakthrough was to add one more column to the breakdown tables. Each line item now starts with a Type column.  It splits up the list, so the Cost Area options are shorter and more logical. That should make data entry easier for beginners (or tired experts).

A year ago, we estimated that tables would take 2 months of programming time. So far, our staff has spent about 5 months on them. There is probably another month or two left, before they are completely done and polished. It was a gross under-estimation, but that has been the trend for this project. Working with the Cocoa library is hard.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report- Messages (Jan 28)

Last week, our staff finished the back-end code to run member tables. They are the little tables with a list of checkbooks, rental units, tax table steps or other setup details. The interface is also mostly done, but it’s still not as responsive as we’d like. When you click in a cell, sometimes it shows a type-in field, as it’s supposed to. Sometimes it does nothing, or waits a bit.

Apple’s Cocoa library uses messages for almost everything. Every window and field and button works by sending messages around to other things. Right now we are setting breakpoints in all possible messages, so we can understand exactly what’s being sent when.

Unfortunately, this is not the first time we’ve had to deal with message problems.

Back in 1987, Apple introduced a program called HyperCard. At the time, it was by far the fastest way for non-programmers to whip up something interesting. We used it to create a simple construction estimator called Hyper*Estimator.

HyperCard also worked by sending messages. It was our first exposure to a programming problem called race conditions. A race happens when two messages are sent, then travel through the CPU with no guarantee of which arrives first. The winner may be entirely random. Or worse, one message may win 99.9% of the time. That creates a hard-to-reproduce bug in the rare cases when the other message wins. Even worse, the race results can be different on different machines. Debugging is so much harder when it breaks for users but not for us.

Hyper*Estimator took about 8 months to program. Then it required another 3 or 4 frustrating months to fix the obscure bugs caused by race conditions. Programming in HyperCard was fun, but fixing intermittent bugs was exactly the opposite.

The current version of Goldenseal uses the PowerPlant library, and it also included messages. However, its message system is written in regular C++ code. That meant we can step through it, and always know what happens when. Even then, we use messages sparingly. Usually there are better ways to get things done.

It’s still too early to say whether Cocoa messages have race conditions. It’s not something that Apple discusses in their specs. Regardless, the messaging is buried in machine language, so we can’t see what sent each message, or why. It’s very much a “black box”. The best we can do is experiment, and gradually guess at what’s inside.

That’s a nuisance, but Cocoa is no more opaque than HyperCard was. We eventually conquered that, and we’ll conquer this one too. At least for Cocoa it’s just the first click that’s a problem. After that it’s in our code, and fully under our control.

Dennis Kolva
Programming Director


Goldenseal Pro- Table Progress (Jan 15)

Our staff is making good progress on the new interface for breakdown tables. To edit a line item, it now shows a separate window with regular fields.  This design change gets us past some frustrating road blocks. It also seems like a big improvement over the current interface.

Breakdown tables are difficult. They’ve been a struggle in Goldenseal Pro, just as they were for the original Goldenseal. That’s partly because the bar is set very high for them. A big percentage of data entry happens in breakdown tables, so they need to look good, and run very smoothly.

For example, for the original Goldenseal, we spent a full week designing the little button that appears when you click in a table cell that shows a list of choices. For Goldenseal Pro we spent another full week for the same thing. The standard Cocoa popup button didn’t look good in a cell, and it’s not easy to change it.

Users need responsive action after a click in a table cell, and they’ll want to use arrow keys or tab keys to navigate. Cocoa’s NSTableView just isn’t designed to work that way.

Meanwhile, Goldenseal uses tables for more than just transaction breakdowns. Bank accounts include a little table for checkbooks, and Real Estate accounts have a table for rental units. About 30 lists also have tables. They handle stuff like payroll tax brackets, shipping costs by weight, and depreciation by year.

Fortunately, most of those tables are very simple- just 1 to 3 columns, and usually just text or numbers. Even better, they don’t get used very often. For those, we probably can still enter data directly into cells.

Dennis Kolva
Programming Director


Goldenseal Pro- Breakdown Table Redesign (Dec 29)

For software designers, a table is anything that shows a list of items in rows. Sometimes it has multiple columns of data, sometimes just one. For modern Mac OS, tables are made with NSTableView, built into Apple’s Cocoa framework.

In Goldenseal, we use tables for many things. Once we figured out the basics of NSTableView, we got most of them working fine in Goldenseal Pro, also.

The most complicated tables in Goldenseal are breakdown tables. Those show detailed line items in Estimates, Sales, Material Purchases, etc. They work kinda like a spreadsheet, but on steroids. Each row has several different types of data entry cells— text, popup lists, check boxes, padlocks. Some cells can change their type, depending on what’s in other cells.

A year ago, breakdown tables were already showing data, so we were optimistic about them. We just had to add data entry. Click and type, or click and choose from a menu, or click to unlock a padlock.

Alas, our staff has really struggled with that part. We’ve tried many different approaches. Each got some things working OK, but then hit a dead end. Each time we took a break and worked on other things for a while, then tried again.  Each failure made it all the more frustrating.

During holiday break this week, there was a “eureka” moment. Maybe the problem is bigger than just getting table cells to show popup menus. Maybe breakdown tables need a more extreme solution. Maybe the current design is fundamentally wrong.

Breakdown tables were also a struggle in the original Goldenseal. They took over a year of programmer time, with lots of futzing and fiddling. They’ve had the most bugs since then. Users often find them confusing. They still aren’t perfect.

Part of the problem is that the tables are very dense. Each line item only gets a little rectangular strip of screen space, maybe 1/4″ x 7″. It’s not many pixels to work with. Even worse, many table cells pop up a list of choices. That has to happen from a teensy box about 1/4″ x  1″. It’s too small for good interface design. Overall, the crowding makes breakdowns hard to program, and hard for users to understand.

For Goldenseal Pro, we already decided to put breakdown tables into a separate window, rather than in the main layout. It’s better use of screen space. Also, now there is room for useful buttons: you can click the Insert Row button, instead of control-click, click Delete Row instead of control-shift-click. The new setup is much more obvious for beginners.

We will now make the same interface change for data entry into table rows. Instead of typing or list-choosing directly in the row, you’ll double-click and see a data entry window. It will have regular data entry fields in a comfy layout, with helpful buttons.

For our programmers, the change saves a few thousand lines of code, and lots of frustration. No more futzing with rows and columns, and cramped interface design. In fact, breakdowns will have the same interface that we already use for lists, so we can reuse that code. Simpler design, which means fewer bugs.

For beginners, the new interface will be much easier to understand. Useful buttons, and less clutter. Easier for tired data entry staff, as well.

The change probably will be hardest for our long-time users, especially those who started out on the MacNail estimating spreadsheet. Goldenseal breakdowns still look and behave a bit like an Excel spreadsheet. Goldenseal Pro breakdowns will be less so.

Hopefully, the advantages will offset the annoyances, even for users who love Excel.

Dennis Kolva
Programming Director



Goldenseal Pro Progress- Breakdowns & Cocoa (Dec 21)

Last week we finished redoing the basic windows setup in Goldenseal Pro for Mac. This time we built the code with the latest OS version (and the latest version of Apple’s Xcode development tool). Xcode now gives better log messages for improper setup, so we could eliminate the errors, one by one.  Finally, everything was proper.

As a result, Goldenseal Pro now runs fine for all OS versions. The former crashes are gone. All windows are also resizable, now. They used to be stubbornly fixed-size, probably because their constraints weren’t valid.

There is still one more big hurdle to overcome.  Our staff has started on breakdown tables several times, but every time we get stuck. Most things work OK, but the basic interface is just not right. We want to have an editable text field appear promptly when you click in a cell. Unfortunately, that basic task has been extremely challenging to pull off.

What we finally figured out is that Apple’s table class (NSTableView) is designed for Finder-like lists.  To change a file name in the Macintosh Finder, you click in the text, then wait a second, then click again. It works that way so you won’t accidentally rename files when you really just want to double-click to open a file, or click-and-drag to move it.

Unfortunately, click-wait-click is not a good fit for Goldenseal Pro. That behavior is deeply baked into NSTableView.

To solve problems like this in C++ and PowerPlant, we would set breakpoints in the code, and then step through line by line to see how the library works. Eventually that leads to a clear understanding of the mechanics. Then, eventually, we can write code that does the job reliably.

Unfortunately, Apple’s Cocoa library is header-only.  Stepping into it show machine language. It is much, much harder to understand than C or C++ code. Even worse, it doesn’t show any of the comments that good programmers add, to help others understand their code. As a result, Cocoa is pretty much a ‘black box’. We have to try things, and see what they do. Then try other things. Maybe we can eventually understand the code, and maybe not.

Best guess right now is another week until we get the breakdown tables working properly, when you click on a cell. After that it will go much faster. Most of the rest is already programmed.

Dennis Kolva
Programming Director

Goldenseal Pro Progress- Containers & Constraints (Dec 11)

Every computer app needs to position stuff on the screen. Usually it takes four coordinates for each item: horizontal and vertical positions, plus height and width. The whole setup is called a frame, since it defines a rectangle that encloses the field, button, window or whatever.

Numbers are fine for computers, but not great for humans. We programmers would rather use a drawing program to lay out the screen appearance. Then we can see what we’re doing.

Goldenseal includes a simple drawing program in the Custom Layouts command. It lets anyone drag around fields, and change the appearance of data entry windows, printed forms or reports. Our staff used Custom Layouts to set up the stock layouts. Users can customize anything with it.

To set up the rest of the interface for Goldenseal, our staff used Constructor. It was a simple drawing program that came with PowerPlant, the library we used to build the first Goldenseal. Constructor set up the rest of the appearance that Custom Layouts couldn’t handle.

For Goldenseal Pro, we use similar visual drawing environments built into Xcode (for Mac) and Visual Studio (for Windows). They save a lot of time.

Frames are good enough for a simple screen layout. Everything has its size and place. But, what happens when you resize the window? These days, people expect stuff to rearrange, and stay useful whatever the size and shape of the window they are in. Unfortunately, a dynamic layout is much harder to set up than a static one. There are many complications.

One layout tool that every programming library uses is containers. All the contents of a container will move together. As a bonus, containers make programming a bit tidier. PowerPlant called them panes, Apple’s Cocoa framework calls them views, and Microsoft’s MFC calls them windows (in Windows programming, everything is a window). Containers are generally a good idea, but they do add some complexity.

Cocoa also has separate controllers for each view, as part of their MVC architecture (model/view/controller). Another good idea, but it adds even more complexity.  The main window in Goldenseal Pro has 9 different views, each with their own controller. Even worse, we need to swap several different views into the top bar and main record area, depending on what you are doing. It took a few months to get it all working correctly.

The other layout tool found in modern programming libraries is constraints. Basically, they are a way to bind each item to its neighbors, so it knows where to go when its container moves or resizes.

PowerPlant and Constructor had a very simple constraints system, but we rarely used it.

For the Mac version of Goldenseal Pro, it’s required that we use the constraints built into the Cocoa framework. We tried doing without it, but just got errors. Unfortunately, they are a confusing mess.

Apple started out with a ‘struts and springs’ metaphor, pretty much like connecting screen items with paper clips and rubber  bands. Then they replaced it with an auto-layout feature in the drawing view. It works great for some things, but can’t be used everywhere.

In OS 10.7, Apple added a NSLayoutConstraint class.  Every view needs at least four constraints, and each looks something like this in the code:

NSLayoutConstraint *rightConstraint = [NSLayoutConstraint                                                                                constraintWithItem : statusBar
                                                    attribute : NSLayoutAttributeTrailing
                                                    relatedBy : NSLayoutRelationEqual
                                                    toItem : theRecordView
                                                    attribute : NSLayoutAttributeTrailing
                                                    multiplier : 1.0    constant : 0];
Throw in a few hundred of those, and the code gets very cluttered. Finally, in OS 10.11, they added yet another constraint system, with much simpler code. Now each constraint looks like this:
[statusBar.topAnchor constraintEqualToAnchor :
                                                  theRecordView.topAnchor].active = YES;

It’s much more palatable, and less prone to stupid errors.

Over the past two years, we used frames to lay out some things in Goldenseal Pro. For others we used constraints, with some of each type. The screens looked OK, but we were definitely bumbling around and didn’t always do the right thing. Sometimes we accidentally added duplicate constraints. Some conflicted with others. Some were just plain wrong. Those inconsistencies are probably why the code crashes when we build with the latest versions of Mac OS.

This week we are redoing all the windows to use the most recent Cocoa constraint system. It’s going to be all anchors.  Newer versions of Xcode are better at reporting errors, so I think we can finally get it right.

Dennis Kolva
Programming Director



Goldenseal Pro- Mac OS Versions (Nov 30)

For the past two years we have been building Goldenseal Pro on Macs running OS 10.11 (El Capitan). Occasionally we test it on newer OS versions.

A few weeks ago we began to update the actual build computers. That means using newer versions of Xcode (Apple’s software-development app), running on the matching, newer OS. The app also uses newer versions of the SDK (Software Developer’s Kit).

To create Goldenseal Pro, Xcode starts with our source code (about 2500 C++ and Objective-C files). It converts the text into machine language, then adds Apple’s code from the SDK. It then links everything together to make the final app. Altogether, it’s a complicated process. Luckily, once it’s set up we can just change text, then hit the Run command. During productive programming, that happens 50 or 100 times per day.

Apple moves fast. Since 2012, they have released a new OS and SDK every September +/-. Each new release adds a few features, and fixes some old bugs. Unfortunately, new versions also remove a few old/deprecated features, and add new bugs.

Along with the OS, Xcode also evolves. Sometimes the interface that we see changes, as does the compiler which translates source code to machine language. Sometimes bug fixes, sometimes new bugs.

With all the changes in basic frameworks and tools, it’s not surprising to discover problems when we update the build OS.

At present, Goldenseal Pro does well when built with OS 10.12 (Sierra). The main window display has a few cosmetic glitches, but those are caused by layout errors that we are fixing now. Sierra is more fussy, but that’s a good thing.

We also can build with OS 10.13 (High Sierra). Most things work, but the app crashes after switching tabs in the main window. Lots of things break Cocoa, so it’s possible that fixing the minor display issues will also fix the crashes. We’ll see about that soon.

OS 10.14 (Mojave) uses a new file system that isn’t visible to OS 10.12 or earlier. To use it conveniently will require more new hardware. The new Mac Minis are not very attractive for the price, so we are considering options. Besides cash, it’s a matter of desk and shelf space, and what we use for daily business. I personally still like OS 10.8 (Mountain Lion) better than all. It’s the last version that allows files with color bars. Upgrading will be a downgrade for my own personal file management.

Before TurtleSoft ships Goldenseal Pro, we need to make a decision about which SDK to use for the final release. It limits which computers can run the app.

Right now, it looks like the best option will be to require either 10.12 (Sierra) or 10.13 (High Sierra).  Hearing from users will help. Mac OS version updates are free, but at some point they require a hardware update. There’s no way Goldenseal Pro can run on OS 10.8, but 10.11 is doable.  Maybe 10.10.  Even if we use an older SDK, it’s still good that we are building on newer OS versions now. It helps catch bugs, and ensures that Goldenseal Pro will migrate easily to future updates.

A couple weeks ago we were making good progress on breakdown tables. Since then, most days have been consumed by installations and testing. Fortunately, final setup is growing near. It will be nice to get back to regular programming again. Making code do tricks is much more fun than downloads and settings for the 6th or 7th time.

From here on out. TurtleSoft will run entirely on SSDs instead of hard drives. They are zippy.

Dennis Kolva
Programming Director

Goldenseal Pro Progress: NSDrawer -> NSPanel (Nov 16)

We started interface work on Goldenseal Pro for Mac a bit over two years ago. During the first couple months we learned Apple’s Cocoa framework, and checked their sample projects to see how best to design the windows.

One sample project was called Drawer Madness. It had a main window, with smaller windows popping out from the sides. It was implemented with a Cocoa class called NSDrawer. Getting drawers to work only took about 10 lines of code. It seemed an excellent way to display breakdown tables, so that’s how we programmed them.

Right about then, Apple decided to deprecate the NSDrawer class.  Deprecation means they won’t provide any further support or improvements, and plan to remove it completely some day. Sigh.

Breakdown drawers looked really nice, so we decided to stick with them for as long as they still worked.

This week, we started testing with the latest Mac OS version. Unfortunately, after opening a breakdown drawer, Xcode gave a warning that the “next responder” was incorrect. The app then crashed randomly. Xcode didn’t say what caused the problem, but NSDrawer seemed a likely suspect.

So, we replaced the breakdown drawer with a different type of window called an NSPanel. It comes down in front of the main window instead of out from the side. We already use panels for lists and “more info” windows, so the change wasn’t difficult. When it was done, there were no warnings, and no crashes.

We probably could duplicate the drawer appearance with a secondary window and some animation. Unfortunately, it would mean learning new Cocoa stuff, and probably would take at least a month to set up. Right now we really want to finish ASAP. Panels are good enough for now.

The way we display breakdowns is kind of a design trade-off. Goldenseal currently has breakdown tables at the bottom of the main window, with all the other fields. You can switch them on and off with the Breakdown popup button on the left. It makes some windows much taller than others. That’s OK when there are lots of separate windows, but it’s ugly if everything is in one window. These days, most apps use a single window with tabs, and Goldenseal Pro will do the same. It’s less cluttered.

Using a drawer on the side means you can see both the regular Estimate fields and the table, similar to how Goldenseal looks now but wider. It also has space for a few control buttons: Add Row etc. The down side is that the drawer is so wide that it may not fit on a 13″ laptop.

Using a panel is the most efficient use of screen space, it also has room for control buttons, and it reduces clutter to a minimum. But you can’t see the breakdown and the rest of an Estimate at the same time. If you need to jump back and forth it’s slightly annoying.

When our staff moved breakdown tables from drawer to panel, we consolidated the code so it will be easier to move again later. That way it won’t be too hard to add drawer-like windows in a later update, if users really want the option.

Dennis Kolva
Programming Director