Windows Main Window (May 6)

Running a project-based business is complicated, and we spend a lot of time thinking about how to make it easier.

The original Goldenseal design was inspired by FileMaker. There is an area on the right showing one record, and a smaller control area on the left with a ‘book’ for navigation (and a few other controls).  Each type of record has its own window: Customers, Estimates, Material Purchases etc.  Additional windows show reports, Pay Bills, Reconcile, Custom Layouts, and other commands. It’s easy to end up with dozens of windows scattered about the screen.

Goldenseal Pro is switching to a single-window interface. Instead of pull-down menus at the top of the screen, it has an outline (aka tree) view on the left that organizes all records, reports and actions into folders. Records still appear on the right as usual. Those two parts of the interface are already working on both Mac and Windows, and it’s a lot tidier than what we had before.

On the Mac, we have a control area at top right with the navigation controls (the ‘book’ and other controls that used to be on the left). We can easily pop in other controls: for Find command, reports, action dialogs like Pay Bills, and Custom Layouts.  Everything in Goldenseal Pro can now happen in the main window, with tabs to move between recent items. If you like clutter, you can still use separate windows, but they aren’t essential any more.

On Windows, we are still experimenting with the control area.  So far, there are 3 different options: a wide ribbon bar, a simpler tool bar, or a detachable/dockable tool bar.  None of them look exactly like the Mac layout, but the dockable bar is closest.  We are still testing them, and haven’t yet decided which to use.

One last bit of unfinished interface is the way we handle breakdown tables. They are bulky and optional, and we want a better way to show and hide them. The Mac version now has drawers that pop out from the side or bottom of the window, to show optional breakdowns.  There is nothing equivalent in Windows, so we are still fiddling with that. 

The MFC library comes with about 200 sample projects, demonstrating different bits of interface. We are building and trying all of them again. Maybe we will discover something that works better for the control area and tables.  It will probably be another week or two before we settle on a final design.

Inventing new interface is frustrating and slow. We are also working on Mac interface whenever we want to see tangible results, quickly.

Dennis Kolva
Programming Director





Goldenseal Pro Alpha 1 for Mac (Apr 27)

The first Goldenseal Pro Alpha is now available for Mac. It requires OS 10.11 (El Capitan) or 10.12 (Sierra). It will not run on older Mac OS versions.

To run the alpha version, follow these steps:

  1. Click the link above to download the software.
  2. It is compressed, so you may need to double-click to decompress it, if your browser does not do that automatically.
  3. Open the GS-Pro-Alpha1 folder, and double-click on the Goldenseal-Pro-Alpha1 app.
  4. Choose Open Business File from the File menu, and open Test-File.  The outline on the left contains all your accounts and transactions. Open the folders and click to see one or more types of records. They will appear in the main part of the window, with tabs at the bottom to navigate between them. You can also use separate windows like the current Goldenseal (right now the only one that works is Prospects, in the Records menu at the top of the screen).
  5. This is an ‘alpha’ version, which means that many things do not work yet. You are welcome to explore the app but some things will do nothing. Some may give error messages or crash the program. You probably will hear random beeps (we add them to unfinished code so we don’t forget). No need to report problems in this version.

To check how well your company file converts to the new format, follow these steps:

  1. Make a copy of your company file.
  2. If still running Goldenseal Pro, choose Quit from the Goldenseal Pro menu.
  3. Open the GS-Pro-Alpha1 folder, and double-click on the Goldenseal-Pro-Alpha1 app.
  4. Choose Open Business File from the File menu, and select the copy of your company file.
  5. Goldenseal Pro will ask you if you want to convert your old file, then will ask you where to save the new file, and what to name it.
  6. The conversion may take a minute or two.  When it finishes, choose Quit from the Goldenseal Pro menu.  If the conversion gives errors or can’t finish, please let us know so we can improve it before the final version.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report (Apr 18)

The Mac version of Goldenseal Pro has come to a good, temporary stopping point.

It shows most fields in the data entry screens, but we are still working on  breakdown tables.  They are by far the most complicated part of the interface. The Cocoa half of that code is ready, but the new tables are very different from the PowerPlant tables we used in regular Goldenseal.  We can probably delete 90% of our existing table code, and make a much simpler connection.

However, before we do anything that drastic, it’s time to see how tables work in the Windows version, using their MFC library.  So, we will switch to Windows programming for a while, and get it caught up to the Mac version again. Then we can design the new table classes so they work well on both platforms.

The Mac code is ready for an alpha version. We’ll release it next week, after we do more testing.  Nothing you can use to run your business yet, but it’s a chance for users to see (and comment on) the new interface.  Also, you can use it to convert your company file to the new format, and see how well the translator works.  That way we can see what breaks on real data, and fix it before the final release.

Dennis Kolva
Programming Director


Turtlesoft 30th Anniversary (Apr 10)

30 years ago this week, Turtlesoft sold its first copy of MacNail. It was a set of estimating templates for Macintosh Excel 1.03, spruced up from the spreadsheets we used for Turtle Creek Carpentry. MacNail came on one floppy disk. The label had a nail head that we whipped up in MacPaint, and printed at 72dpi dot matrix.

As we overhaul the Goldenseal source code this year, it’s fun to think about how much has changed since 1987.

Back then, the Mac Plus was an expensive, high-end machine that came with 1 megabyte of RAM. That was generous for the time (MS-DOS maxed at 640K), but programmers still had to be frugal. Our staff spent many hours thinking of ways to shrink the MacNail spreadsheets by 1 or 2K. It was a big deal, deciding whether to use 1 or 2 or 4 bytes for a value.

These days, programmers can count on a few 1000 megabytes of RAM. It’s often reasonable to use an 8-byte value, just in case that number gets too big in some weird future world. We wouldn’t want Goldenseal to fail when you start work on your 2-billionth project, right?

Back then, it took 3 minutes just to open the MacNail spreadsheet file.  Progress bars and spinning cursors were vital, to let people know the computer hadn’t frozen.  Having a big progress bar helped, so you could do something else across the room, and see when it was almost done.

These days, processors are 100x faster. This week we removed all the code that spins cursors, because modern machines are so fast they don’t need a rotating clock or hourglass. We kept the progress bars, but they’ll be a subtle little bar at the bottom, rather than a full-size window. There aren’t many things that will take more than a second or two.

When we first began programming Goldenseal in the mid 1990s, it took 7 minutes to rebuild the source code, even if just one word changed. Large changes had to run overnight, and complete project rebuilds took a whole weekend.

These days, Goldenseal rebuilds in 15 to 150 seconds, depending on how much changed. That means many more cycles of writing-and-testing per day. Practically speaking, programming is much less draining when you can make a change and just try it out, rather than triple-checking to make sure the logic is correct before daring to build it. Programmers can think more about large design issues, and less about punctuation and typos.

Back in the 80s, programming languages were still young. They broke a lot, and required complicated coding to accomplish anything.  Just drawing a button on the screen could easily take 30 lines of rather complex code.

These days, C++ and other languages have matured.  They’ve added well-tested libraries, so it’s possible to write code that runs fast, and won’t crash. There is still plenty of learning curve for each new library, but the Internet makes it relatively easy to find tutorials and answers.

Meanwhile, Goldenseal Pro is just starting to fill data into breakdown tables. Half the work seems to be throwing out all the old code that we don’t need any more.

Dennis Kolva
Programming Director


Refactoring Goldenseal (Mar 29)

Back in Summer 2014 we realized that Goldenseal needed a major overhaul. Apple stopped updating the Carbon and QuickTime frameworks that we used, so it was just a matter of time until it stopped working.  We searched for and tried out several different subcontractors to rewrite the GUI (graphic user interface).

Meanwhile, our staff finished one additional update to Goldenseal, but then started to refactor the existing code. The first thing was to remove old crud left over from 68K Macs. Then we converted 32-bit code to 64-bit, removed anything dependent on the doomed Carbon and QuickTime, replaced the NeoAccess database, and eliminated most of the old PowerPlant framework.

Last September we gave up on subcontractors, and started GUI programming in-house. For that we use the Cocoa and MFC frameworks for Mac & Windows, respectively. However, we probably still spend half our time refactoring the existing code.

Refactoring is a lot like remodeling an old house. Some things we tear out and replace. Some, we scrape off the crud and leave them. Our rule of thumb for refactoring was expressed very clearly this week in The Daily WTF: “Thinking is hard, and I’m not very good at it. Every block of code should be simple and obvious, because if it makes me think, I’ll probably screw it up and break something.”

This week we are replacing the PowerPlant array classes. The analogy for that is more like tearing out the main beams, because they are used everywhere. We wrote a replacement more than a year ago, and have used it in new code long enough that it’s well-tested.  Now it’s time to shift over entirely.

Refactoring is also a chance to make design changes. The maximum array length is currently a 32-bit number (4 billion max) but we probably will make it 64-bit (9 quintillion).  Nobody will ever need the extra space, but it may help us stay compatible with future CPUs.

Meanwhile, we’ve finished about half of of the Mac data entry interface. It now allows a main window and/or separate windows, and shows almost all of the fields.  The only hard things left are the tables, used in itemized estimates etc. One is starting to work, and we’re gaining on the others.  Best guess is a few more weeks until we release an ‘alpha’ version for folks to try out.

Dennis Kolva
Programming Director

How we program Goldenseal Pro (Mar 20)

In movies, programmers usually sit at a terminal and type pages of dense computer code, at breakneck speed.

In reality, programming new GUI code tends to go more like this:

  1. Try a few Google searches to see if someone has written a tutorial on how to make the new thing.  If not, search Stack Overflow for related questions.
  2.  If that is not enough, look through the list of Cocoa or MFC classes for anything already designed to do the new thing.  Search again for tutorials on how to use those.
  3. If desperate, check the indexes of a few reference books. Try more searches with slightly different words.  Or give up, and try a completely different approach.
  4. After getting a vague idea of how to proceed, search Google and GitHub for sample code.  Apple and Microsoft both have tons.
  5. If there are sample projects, run them and see if they do the job.  If so, step through the code in the debugger and try to understand it.
  6. If no samples, search.  Probably some smaller code samples, somewhere.
  7. Copy/paste the likeliest code into the actual project.  Tweak as necessary.  If totally desperate, write a few lines of brand new code. It rarely takes more than 5 or 6 lines to do the job. Often it’s just 1 or 2.
  8. Run it and see if it works.  If not, step through the code in the debugger and find where it breaks.
  9. Test it, tweak it, test some more, tweak some more.  This requires a small amount of typing, but most of the time is spent running the program, dozens or hundreds of times per day.
  10. In some cases, throw it all out and try a different approach. Repeat steps 1 to 9.

If it weren’t for debuggers, it would be nearly impossible to write complex software. “Debugger” sounds like something you can wave at bugs to kill them, but unfortunately it’s not that easy.  Instead, you set a “break point”, then run the program. When it gets to the break, you step through one line at a time, and see exactly what changes when.  Sometimes the problem is obvious, and sometimes it takes many trials.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report (Mar 11)

We are making gradual progress on the new Macintosh interface. Here’s a screen shot link showing what it looks like now:

There is an outline view on the left that replaces all the old pull-down menus. There’s a “book” to navigate through records, and tabs at the bottom to switch between what used to be separate windows.  We will still let you open multiple windows, but they will be optional.

When we first started the Pro update, the plan was to have subcontractors rewrite Carbon to Cocoa (Mac) and QuickTime to MFC (Windows), keeping the same appearance.   That way the contract specs were easy, since it just had to match what we already had.  The plan was to start redesign work after the conversion was finished.

Now that we’re doing the work in-house, it makes more sense to combine the redesign with the general code updating.  So far we have made many more changes than first expected, but it’s also looking much better than expected.

Cocoa is not easy to master, and it probably will take us at least another month before all the basics are working on the Mac version.  No insurmountable problems, but there are many details that each take a day or two to finish.  Fortunately, we only have to do this once.  It’s going to be a real pleasure when we can get back to writing plain old C++ business code.

Dennis Kolva
Programming Director
Turtle Creek Software

Breakdown Tables (Feb 28)

Last week we added top controls to the Mac version, so it looked sort of like a Windows ribbon. It didn’t take long to find that it was too cluttered, and not all that useful.  So the main window got one more redesign, and we are quite happy with the final product.  It’s possible we will remove ribbons from the Windows app also, but we’ll get the Mac interface further along before we go back and decide on the final Windows appearance.  It’s kind of a leap-frog process, jumping between platforms every few weeks.

There is still one big design issue left, which is the breakdown tables for itemizing smaller details in Estimates and other records. 

When we first wrote Goldenseal estimating/accounting software, none of the C++ libraries had good tables. We had to write that interface from scratch, and probably spent a programmer-year or two on it.  Tables have complicated code that has not aged well. Fortunately, both Cocoa and MFC have mature table classes.  We can get reliable appearance, scroll-wheel support, column sorting, and other pleasant features for much less work than the original.

The big design question is, where to put them?  Currently, Goldenseal switches between entirely different layouts when you click the Breakdown popup on the left side of the screen. There are at least two different types of tables that can sit below the other fields, plus a no-table view.

Many users have found that system confusing, so we probably will simplify to a single layout, with just one type of breakdown table. Cocoa has “drawers” that can open out to the right, and that seems like a great place to put the (optional) breakdowns.  It fits particularly well with the new single-window setup, and today’s wider screens.

Dennis Kolva
Programming Director


Goldenseal Pro Progress Report (Feb 22)

It only took a day or two to set up the main application window in Goldenseal for Windows.  Still many details to finish, but the basic appearance looks good.

The Mac version was a different story. We tried one approach and just couldn’t get it to work. So we started over with a different approach, and could not get that working, either.  

Out of sheer frustration, we downloaded about 50 sample Cocoa apps from Apple and elsewhere, hoping to find something similar that we could use as a working example.  Nothing was close, though we did find some useful samples that will help us when coding other parts of the project.

Yesterday we started over for a 3rd time, building things one small step at a time, and getting each bit to work before moving on to the next step.  That went more smoothly.  Maybe we finally found the right approach, or maybe we just made every possible mistake, and couldn’t help but do it right eventually!  Anyhow, Goldenseal for Mac now has a single window that lets you navigate through all parts of the program.  Still many details to finish, but the basic appearance looks very good.

It took almost two months to design the new interface, and then get it working similarly on both platforms.  A bit of a digression from our original plan, but it probably will end up being worth the extra time.

Dennis Kolva
Programming Director
Turtle Creek Software

Vanilla Programming (Feb 6)

Last week, we discovered a huge trove of Microsoft sample code.  It included the interface source code for most of their apps (Office, Internet Explorer, File Explorer, Outlook…). It also had about 100 sample apps, showing how different features work. We spent most of the week building and running their code, and learned a lot.

Among the samples was RibbonGadgets, with all possible types of controls on a ribbon. We spent a few days trying to merge it into our code, so we could start with a working sample, and then modify it to suit our needs.  Unfortunately, ribbon setup is complicated and very fragile, and we just could not merge it. We finally gave up, and are now building a ribbon from scratch. Slower, but we can test at each step and make sure it still works.

We are building Goldenseal Pro for Windows to be as “vanilla” as we can, using the same MFC classes that run Microsoft’s apps. That way, there is less risk of incompatibilities in the future, and more likelihood that our code will upgrade automatically in future versions of Windows. The goal is Volvo station wagon, not Ferrari.  Boxy but reliable.

On the Mac side, Cocoa has no built-in ribbon interface. It does have toolbars, but not the kind we need. Fortunately, the screen layout tools in Cocoa are much more flexible than in Windows, so we can still create a similar appearance on both platforms. Being “vanilla” is tougher on Mac because Apple changes it so often, but at least we’ll be current for a while.

Enough interface is working now, that we can tell it’s going to be nifty. The main window will have almost everything that is now in pull-down menus, but organized better. It will be much more understandable for beginners, and not too hard a switch for current users.

We’ll release an ‘alpha’ version after we finish the new ribbon interface. That way, you can check it out and give feedback. The first release will also let you import your existing data, so you can see if it converts properly to the new format. If not, we’ll have plenty of time to fix the bugs.

Dennis Kolva
Programming Director