Goldenseal Pro Menu Commands (Dec 16)

Right now, Goldenseal has 316 different menu commands which each open a different type of window.  There are 17 accounts, 51 transactions, 95 lists, 24 action dialogs, and 129 reports.  Running a business is complicated! We probably can eliminate a few commands, but nearly all are needed by at least some users.

In Goldenseal Pro we plan to reduce the number of menu commands and windows, to make navigation easier.  As a start, we just finished a Preferences command that consolidates 8 menu commands into a single window, with tabs. The new Preferences window looks nice and works well.

Using the same approach, we can probably convert those 316 menu commands to 30 or 40 windows with tabs. It will reduce clutter, and group related items together. For example, the Estimating command will show Estimates, Allowances, Bids, Project Phases, Cost Items and Assemblies all in one window, with tabs to switch between them.

There is another approach we are working on, that consolidates the menus even further. It has a column of accounts, transaction types and lists on the left, grouped in folders that can be opened or closed. Click on one, and that type of record fills the rest of the window, on the right. It works the same as tabs, but handles more choices.

Once we finish the Macintosh data entry windows, we will get caught up to the same place in the Windows version, and then release them as a ‘pre-alpha’ version so users can try out the new interface(s). There are many fussy details to address, so it probably will take a month or 2 until we get to that point.

Dennis Kolva
Programming Director


Smart Fields (Dec 5)

Back in 1985 we started to write estimating and accounting software in Lotus 1-2-3 on a Tandy 1000, and then in MS Excel on a Mac Plus. It first sold in 1987 as MacNail 1.0.

At the beginning, the spreadsheets had vendors, cost categories and jobs as plain text fields.  Unfortunately, reports would show Smith and Snith as separate jobs if you made a typo.  Even worse, an extra space character also split it into a different job, even though it looked identical on the screen. OK for perfect typists, but not for humans.

We switched to number codes, but that was hard to remember.  So we added “lookups” that showed the name next to the number.  Better, but you still had to memorize hundreds of numbers, or use a cheat sheet, or guess a lot. The lookup formulas were also very fragile.

Back then, Bruce Tognazzini was the “interface guru” for Apple.  He wrote about a hypothetical disambiguating field, designed to choose items from a list by typing the first few letters.  It also had a popup button so you could enter data with the mouse. The setup sounded ideal for accounting data. There was nothing at all like that in Excel, which was one reason why we decided to develop Goldenseal as a stand-alone accounting app.

Apple never added the disambiguating field to its standard controls, so we wrote one from scratch.  Disambiguating seemed too odd a term, so we called them clairvoyant fields.

When we started the Cocoa update this year, we were excited to see a class called NSComboBox. It looks like a disambiguating field, with text and a popup button.  Unfortunately, when we tried using it, it turned out to be just the opposite.  For accounting, everything needs to go into a specific vendor account, job and cost category.  It’s nice to have an easy way to add new accounts, but you do not want to create a new account every time you make a typo.  Unfortunately, the combo box gives suggestions, but is happy to accept whatever you type. We tried hacking it, but it is just not meant to have other behavior.

So, we are now in the middle of redoing clairvoyant fields to work with Cocoa native controls.  It will be a text field next to a popup button, just like before. Type a few letters and it shows a list.

Clairvoyant fields sound too complicated, so they’ll become smart fields.

It will take some experimenting to come up with a new look for them. Probably a gray border? It needs to look good on Mac, Windows, Android and iOS.

As a boon to data entry, popup fields will also become smart fields. That way, you can do all data entry from the keyboard, and never touch the mouse. It will be a Preferences option, so you can keep the original popup appearance, if you prefer.

Dennis Kolva
Programming Director


Inside Macintosh Cocoa (Nov 25)

When we first started work on the Goldenseal accounting software, there was a set of printed books called Inside Macintosh. It was 7 or 8 volumes, about a foot wide, and pretty much the Bible for Mac developers.  Our copies grew battered from constant use, and we had a ‘cheat sheet’ that pointed to the pages we used most often.

These days, Apple’s documentation is all online. Unfortunately, it’s also more scattered. The Web makes it very easy to find answers quickly, when you know what question to ask. Unfortunately, it also seems to make discovery harder, when you don’t know if something exists in the first place. Hard to search, when you don’t know which words to use.

For example, last week we set up the record window layouts, but then stumbled upon a Cocoa class that makes record scrolling seem more like pages in a book. To use it, we had to throw out what we did, and start over.

To help discover what else we don’t know, we are now gathering all of the Cocoa classes into a spreadsheet.  It won’t be Inside Cocoa, but at least it will show everything it can do. There are already 250 rows, and it’s not even half-way done, yet. The project has already turned up several nifty classes that will improve the interface, without much effort.

Meanwhile, we also spent the last couple weeks improving the new database code. It was giving a few error messages after converting old files to the new format, and those bugs are now fixed.  It also does a better job of deciding how long records stay in RAM.

For a while, we were concerned that we might have made a mistake by writing our own database code, instead of licensing from someone else. However, so far it is working extremely well. It’s much simpler, and probably will be much more reliable. Between 1998 and 2015 we rewrote more than half the old NeoAccess code, so replacing the rest was not as overwhelming as it might have been. And, of course, alternatives like Core Data or SQLite have their own bugs, quirks and design flaws.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report (Nov 11)

We are now in the “middle” stage of the Goldenseal Pro project.  There are many different things we can work on, and it doesn’t matter which we do first.

When we removed blocks of obsolete code last year, we replaced them with one line of code that gives a beep. So, as we make progress on the interface, it also starts to beep a lot. Eventually that gets too annoying, so we go in and add code just to shut it up. For example, this week we added ‘new style’ code to handle dates, times, and error messages.

Judging by how the work has gone so far, I think we will have something ready to ship by late Winter 2017.

Dennis Kolva
Programming Director

Goldenseal Pro Appearance

We started work on Goldenseal Pro for Windows a couple weeks ago, and soon had to stop until we made a decision about the basic window setup.

On Macintosh, there is a menu bar at the top of the screen. The current Goldenseal then shows separate windows for each type of record (customers, estimates, material purchases, checking transactions, etc). You can open just what you need, and put the windows side-by-side on the screen so it’s easy to jump from one task to another.

Windows has a menu bar along the top of each window, instead of at the top of the screen. That can take up a lot of space when there are multiple windows, so the current Goldenseal setup is to have one big window with a menu bar, and then smaller ‘child’ windows inside it, for each type of record.  It’s called MDI (multiple document interface).

These days, very few programs use MDI: it looks fine on a small screen, but is rather dorky on a large one.  However, if we abandon MDI, we still want the Mac and Windows versions to look approximately the same. It makes our tech support (and manual writing) easier, and it’s also easier for users to switch platforms.

Most apps are fairly simple, and can get by with just one window.  The trend in GUIs seems to be that even complex programs will stuff everything into one window, with tabs and/or panels to organize it all. A single tabbed window works OK well when there are 5 to 10 things to show, but we have more than 100 possible accounts, lists and transactions that you might want to see. Running a business is complicated, which makes our app more complicated than most.

Usually when we have a tough interface problem, we look at other apps and ‘borrow’ whatever looks the best.  Unfortunately, we haven’t found the ideal model to copy, yet. The closest ones so far are the two apps we use for writing code (Xcode on Mac, Visual Studio on Windows).  Xcode has one main window, plus the option to open separate windows. Visual Studio has one window, with tabs to switch between files. Neither is particularly ‘user-friendly’, but programming is also very complicated, and at least they don’t make it any worse.

Unless we find something better, we will use a combination of the two approaches for Goldenseal Pro.  It will have a main window with tabs for all the accounts and transactions you have active, plus the option to move anything into a separate window.  Move them all, and it will look the same as now.

Meanwhile, work is progressing well on Goldenseal Pro. Right now we are busy deleting the old drawing code from our GUI classes, and adding links so they can connect with the modern GUI objects from Cocoa and MFC.

Dennis Kolva
Programming Director


Goldenseal Pro Progress Report (Oct 20)

On the Mac, Goldenseal Pro now shows data entry windows: complete with fields, titles and buttons.  That is pretty much the specs for the first draw stage of six. It feels like we are making decent progress, and getting ‘up to speed’ with Cocoa.

The second draw is to link in the fancier aspects of the human interface: tables, having controls interact with each other, and lots of little stuff like colors and fonts and sounds.  Originally, we planned to use the same basic approach as the current Windows code, but now we are considering a more complete redesign. There is a lot of old clutter in the code base, which may be easier to just replace entirely.

It makes sense to get the Windows version caught up to the same place, before deciding how much GUI code to rewrite.  So we have shifted gears, and are currently delving into Visual Studio and Microsoft Foundation Classes (MFC).  We’ve also peeked at C# and .Net (the Microsoft equivalents to Objective-C and Cocoa), but probably won’t use those.

Sadly, Microsoft’s software design and documentation is even denser than Apple’s.  The first part of Goldenseal Pro for Windows will be a spell of rather frustrating work. Still too early to say how difficult it will be, or how long it will take.  Best guess is a month or two.

On the plus side, we can do small stuff in the Mac version whenever Windows gets too head-bangingly difficult.  Some programming problems are best solved by just ignoring them for a few days, and doing something that is more fun.

Dennis Kolva
Programming Director


Writing Big Software (Oct 11)

Goldenseal is a rather big app: 6 million lines of code, which compares to the 20+ million lines in Microsoft Office.  We have at least 15 programmer-years invested in it.

Like any big project, you still have to build it one day at a time.  We have learned that programmers need to see tangible results at least a couple times a day.  A couple times per hour is better. So we are inching along on the interface conversion, with many small milestones (yardstones?). Sometimes we add temporary code to draw something on the screen, just so there is visible progress!

Yesterday we got over a big hump when we figured out how to write ‘linkers’ that connect each of our interface classes to the matching one in Cocoa.  Cocoa was using our C++ code weeks ago, but it was much harder to go the other direction. Now that we have a template for a few classes, the rest will be easier.

Along the way, there are many small details to convert or modernize. Right now we are working on colors. Goldenseal used to pick most colors from a palette of 256 colors, but Goldenseal Pro will use ‘color wheels’ with millions of choices.

Dennis Kolva
Programming Director


Goldenseal Progress Report- Sept 30

Goldenseal Pro now connects from the database to the display windows, which is where our previous contractor got “stuck”.  It was very exciting, the first time it showed a list of categories!

The Goldenseal app includes several hundred layout resources, used for data entry screens, reports and printed forms.  In the original Goldenseal they were stored as resources, embedded in the application file.  The modern approach is to store them as separate files, hidden in an ‘application bundle’.  So we wrote some one-time code to translate all the layouts to the new style. Now we are working on the code that reads them, and sets up the fields and buttons on-screen.  Getting that to work is the biggest task in the whole project, and it probably will take a few weeks to complete.

At every design step, we need to decide where to draw the line between Cocoa and our existing C++, but we are using Cocoa as much as possible.  It means rewriting more code, and spending more time learning the ins and outs of Apple’s framework, but it ought to result in a better interface (and better compatibility with future OS versions).  We used a pure-Cocoa setup for the list of categories, and it seemed worth the extra effort.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report- Sept 20

We are gradually ramping up the programming work on the Mac version of Goldenseal Pro, accounting software.  

After starting on the interface classes, we soon realized that almost everything needs to be written in Objective-C. That is the only way to hook into our existing C++ code.   We were really psyched to use the newer Swift language, but switching between three different languages drove us nuts.  Partly because different concepts, but mostly because the punctuation is very different. So, Swift is out, unless we find good reasons to use it later.  We will still use Swift for future iPhone/iPad development, because that will be entirely new code that won’t need to integrate with anything old.

Back when we tried subcontracting the upgrade work, the contract had 6 payment draw stages of approximately equal sizes.  Draw 1 is to open a list window (for example, anything from Options-Payment Terms), and then view and save list records.  Now that the programming work is in-house, we will use the same milestones.

We are still climbing the learning curve for Objective-C, but the Pro version already has menu commands that open windows and show a list of items. We still need to link it to the database and have it load screen layouts, then that will finish draw 1.  This is also the time to design many basic structures, which is good reason to take it slow, and do it right.

The Cocoa framework was developed in the mid-1980s for the NextStep computer.  It’s a ‘black box’ with many nifty features, but it can be challenging (especially for large apps like ours). We aren’t the only ones who still need a major rewrite: Microsoft is finally releasing their first Cocoa and 64-bit code this year, in Office 2016. 

On the plus side, Cocoa lets you build a lot of interface with very little code.  It’s going to allow some nifty improvements to the Goldenseal user interface. For example, popup buttons you can access from the keyboard.

On the minus side, Cocoa is hard to debug, and lacking in practical documentation. We have been perusing open-source projects, just to see how other people handle ‘the basics’.  Cocoa is also changing constantly, so at least half the answers for it in Stack Overflow are outdated and incorrect.  We have learned to check the date on all books and online info.  Much before 2013 and it is probably wrong. Anything after 2014 will be for Swift, not Objective-C. The ‘sweet spot’ is very narrow!

Some year soon, Apple will probably change the Macintosh from Intel to their own ARM chips.  Most likely they will also replace Cocoa with a new Swift-based OS, though that will be an enormous project.  We’ve learned our lesson, and are now designing things so the next remodeling round will be easier.

Dennis Kolva
Programming Director

Goldenseal Pro Progress Report #10 (Sep 6)

Our staff now has a decent grasp of the new Swift programming language, and the basic Cocoa libraries.    It will take a few months to get fully up to speed, but we are ready to start coding.

Our contractor wrote quite a bit of startup code in Objective-C, and we are reviewing it now to see how much can be salvaged.  We may need to start over entirely, but it’s worth spending a week to understand his code, and decide what to keep (and how to merge it).  If nothing else, we need to learn enough Objective-C so we can link our C++ to Swift.

It took us about 2 months to move Goldenseal from Mac OS 9 to X, and 2 weeks to move it from PPC to Intel.  Unfortunately, this is going to be a bigger transition.  Hard to estimate right now, but it will be months, not weeks or years.  A lot of the time will be “learning curve” that will pay off when we start writing apps for iPhone and iPad.

Dennis Kolva
Programming Director