More Pro Plans

We’ve decided not to use QT as a cross-platform development tool for Goldenseal Pro.   It means throwing out some working code that we’ve already paid for, but it won’t be the first time we’ve done that.

QT would let us have one code base that runs on Mac, Windows, iOS, Android and even Linux.  That notion is extremely attractive, so this was a very difficult decision.  Unfortunately, QT has plenty of limitations and design flaws, and in sum they seem larger than the advantages it provides.  In the long run we’ll be better off with native code, even though it’s more work.

Over the past year we’ve relied on the judgement of subcontractors on how best to approach the Pro project, since we figured they had already done this kind of update.  That also turned out to be a mistake, and a big waste of time.

On the other hand, we don’t have any prior experience with Objective-C (for Mac) or the Windows libraries, and doing it all in house will be too slow.

So, we will spend a few months designing and writing the “core” of Goldenseal Pro.   Some of that will be in the platform-native languages, but most of it will be rewriting our base code to be more connectable to modern frameworks.  It will be a good way to spend the gray days of winter!

When that is done we will put it out to bid again, with a clearer set of specs, and a code base that is much easier to take over and manage.  We may even break it into smaller sub-projects, so work can proceed in parallel.

Dennis Kolva
Programming Director
Turtle Creek Software

Goldenseal Pro design phase

We haven’t written much code yet, and probably won’t for the next few weeks.  Instead, we are working on basic design, and getting familiar with new programming languages and tools (Swift, Objective-C, Cocoa and Quartz for Mac, Visual Studio for Windows, and QT for both).

We’ll start writing new code in mid- to late-December, but it will go more smoothly if the big picture is worked out, first.

Modern software tends to use a design approach called MVC (model view controller).  Our existing code kind of does that already, but we can probably spruce up a few things to make future maintenance easier.  We also want the desktop app to “talk to” mobile apps in the field, and it will be nice to design that in, and maybe even share some code.

Dennis Kolva
Programming Director
Turtle Creek Software

Resources and QT

We have been digging into the resource-handling code, and have pretty much decided not to use QT for it.  The problem is that QT stores the resources in compiled form, so it’s embedded in the application in an inaccesible form.   That means, for example, that it is much harder to build versions for other languages. It’s also impossible for users to “hack” minor changes.

The alternative is to write separate, native code for Macintosh (using Cocoa and either Objective-C or Swift) and for Windows (using their API). If we need to write native code for resources, than it may also make sense to just do it for everything.  More effort, but better.

I just read a well thought-out article that extols the virtues of writing for both platforms at the same time, instead of building one and then doing a “port” later (or using a cross-platform tool like QT).  Considering both at the beginning leads to better design.  Also better quality code, since each compiler catches different types of bugs.  It’s kind of like having two building inspections instead of one.

After 14 months of talking with (and paying) subcontractors and getting nowhere, the idea of doing the work in-house is appealing.  It probably would take a year or more of rather tedious/frustrating work to finish the Pro version that way, but the end results will be better.  This is going to be a tough decision.

Dennis Kolva
Programming Director
Turtle Creek Software

Converting Resources

The Goldenseal Pro app now runs, but it doesn’t get very far, yet.

The code starts out by loading info about the fields in each type of record.  The data is used for many things, so we grab it first thing, and keep it permanently in RAM for better performance.

On older Macs, Goldenseal got that info from Mac resources, which also stored all text, menus, window layouts, and other program data.  Anyone could edit the resources with ResEdit, and one user actually used it to translate everything into Spanish.  The Windows and OS X Carbon versions could read the same resources, but didn’t have any way to modify them.

These days, both Mac Cocoa and Windows store resource data as XML (similar to HTML).  So we are currently writing code that will move most of our existing resources into that format.  The conversion will save a lot of typing, and eliminate errors.

Dennis Kolva
Programming Director
Turtle Creek Software

Goodbye to Carbon

Goldenseal Pro now compiles using the latest Mac SDK, and no longer uses any Carbon libraries.  The demolition went a lot quicker than we thought!

Now that all the outdated code is gone, we just need to put new code back in.  That will be a gradual process, but having the old crud gone will make it much easier.

We’ve already started writing new code, using QT.  It is an open-source library that lets us use the same code for both Mac and Windows. QT has its flaws and limitations, but then again, the other choices have their problems too.

When we write accounting features, it’s in a nice clean place with just our own code.  We keep things tidy and well-organized, so it’s a pleasant place to work.

Unfortunately, system stuff relies on many layers of other people’s code, and it’s often a cluttered, complicated and ugly place.  Yesterday we loaded a Mac SDK (the code that sits underneath ours), and it was almost 50,000 files!  Interfacing with that much complexity is not for the faint of heart.

Dennis Kolva
Programming Director
Turtle Creek Software

Goodbye PowerPlant (mostly)

We started work on Goldenseal in 1991, using the Pascal programming language, the Think Pascal compiler, and their class framework (Think Class Library).  Less than a year later, Apple announced plans to switch processors (from 680×0 to PPC) and programming languages (from Pascal to C++).

We decided to just throw everything out, and start over.  Apple’s tools were not very good, but a program called CodeWarrior burst onto the scene for building C++ code.  They had a class framework called PowerPlant, and we built our code on top of it.   Having been bitten once, we were cautious and put a layer in between our code and theirs, in case we ever had to switch.

23 years later, we are appreciating that decision.  We will keep a few of the most useful pieces from PowerPlant, but we’ve already managed to prune out 80% of it, and will gradually remove most of the rest.   Then we can plop our code on top of a different framework.

Based on the past week’s progress, it should only take another week or two to finish the demolition phase.  We already have working code based on the QT framework, so we will continue work on that ourselves, and see how far we can get in a month or two.  At that point, we can make an informed decision whether to use it for the whole project, and whether to finish the work in-house.

It’s nice to be moving forward again, after being stalled for almost half a year.

Dennis Kolva
Programming Director
Turtle Creek Software

Goodbye 32-bit & AppleEvents

After 3 days of hacking frenzy, Goldenseal source code compiles again as a 64-bit app.  We had to remove all of the screen drawing code, but that is obsolete and will be replaced, anyhow.

We then removed all the AppleEvents code: a mid-1990s system that Apple developed, made essential, and then abandoned when they jumped to OS X.  Fortunately, we didn’t use it for anything, and it wasn’t important in any of the frameworks.

This is a bit like going into an old house, removing the old plaster, and deciding what to do next.  The framing is solid, and there is a lot of good design to be proud of.

Coincidentally, on weekends I am rehabbing the house in Spencer NY where Turtlesoft first began. Mostly doing electrical work, but now I’m thinking it might be worth gutting that place too!  It would sure make wiring easier.  Then again, all that blown-in cellulose insulation would be a real pain.

Dennis Kolva
Programming Director
Turtle Creek Software

Goldenseal Pro progress report #9

We are still waiting for a decision from a couple of contractors, but got impatient and started work on the conversion ourselves.   It’s a lot like doing a major rehab on an old house, and we are currently at the “gut and demolish” stage.

To start, we’ve upped the compiler to require 64-bit code, and are tearing out any old code that it breaks.  Some of it is important stuff that we will need to replace later, but 95% is early-2000s stuff in the PowerPlant framework, that we never even used.

We started prototyping Goldenseal in 1991, and this is at least the 3rd major “gut and rehab” we’ve done on it (plus a dozen or so smaller rebuilds).   Our own code rarely needs much work, but we rely on libraries from Apple and other sources, and those frequently becomes obsolete.  Tearing out the old stuff is like taking a tour through Apple’s abandoned technologies from the mid-1990s to the mid-2000s.

It’s possible we will just take it to completion in-house.

Dennis Kolva
Programming Director
Turtle Creek Software

Goldenseal Pro progress report #8

We have been taking extra time choosing a contractor, this time around.  We’ve talked with several people that sound good, but have pretty much narrowed it down to 2 candidates.  One is US based and will do a Cocoa update for Mac only.  The other will do a QT-based update for both Mac and Windows.

Once the choice is made, it will probably take 3 or 4 months to complete the work.

Turtlesoft outage

Arvixe, our website hosting service, switched turtlesoft.com to a new server on Friday.  They forgot to change their name servers to point to the new location, so the website was out of commission from some time Saturday until Monday late afternoon.  Due to the holiday weekend it took us a while to notice it, and then a while for them to fix it.

The site is now back in business.  Our apologies for anyone who needed the Answers button, and couldn’t get at it.