Turtlesoft Blog

Last October, TurtleSoft hired a subcontractor to write networking code for our new accounting software. It was a three-part contract: first for desktop, then for Android phones and tablets, then for iPhone and iPad.

The desktop part finished in December. It lets multiple users access the same file over a LAN (local area network), similar to what Goldenseal does. Even better, it also works over the Internet. Connect a laptop to Wifi, enter the IP address for the server machine, and it’s just like you’re at home.

Part two of the contract was to build a prototype app to run on Android. That just finished last week, much later than expected.

The good news is that we probably can run the full desktop app on Android tablets, plus a smaller, simpler version on Android phones. The bad news is that programming it will be hard. Getting Qt, Android and Java to play nice with each other is no easy task.

Part three of the contract starts next: building a similar prototype for iPad and iPhone. Hopefully it will be easier.

The projects for mobile devices were mostly just “proof of concept”. We wanted to see if they could work at all, how they would feel to use, and how hard they’d be to program. Final work on them will wait until the desktop version is released and stable.

Meanwhile, testing on the desktop app still turns up up plenty of bugs. We used it full-time to run our own business for a while, but had to revert and re-enter a couple weeks of purchases and sales, all because of a serious bug in bank transactions. They were missing some important data that only showed up when we added running totals to the display.

If the iOS project goes quickly enough, we plan on a first public release of the new accounting software for Mac and Windows desktops, soon after it’s done. If iOS bogs down as much as Android, then we’ll launch the desktop version before it finishes.

Dennis Kolva
Programming Director
TurtleSoft.com

This week is a milestone for our new accounting software. TurtleSoft now uses it full-time to run our own business. We have used it in parallel with Goldenseal for many short spells, but now data only goes into the new file.

The new app still has plenty of glitches. Using the software every day turns them up more quickly. Most are just annoyances that don’t take long to fix. If something more serious turns up, hopefully the daily backups will be enough to allow recovery.

The previous TurtleSoft company file had a few hundred bad Sales breakdowns buried in it, left over from similar beta testing in the early days of Goldenseal accounting. Most were fixed by the code that translates from Goldenseal to the new app, but some were too damaged. Those didn’t survive the transition and disappeared. In the new accounting app, at least that block of Sales records from the 1990s won’t crash any more when you view them. Now they just give an error message.

Meanwhile, work on a mobile version is progressing, but slowly. Android is very difficult to work with! Our staff has a comfy routine to build test apps on Mac and Windows, but phone and tablet are much more fussy. Mystery problems and error messages galore.

If the desktop app seems solid enough by the time Android work is finished, the first release will happen soon after that. If still too many bugs, it will wait until after work is completed for iPhone and iPad.

Dennis Kolva
Programming Director
TurtleSoft.com

There’s a saying for construction work: cheap/fast/good, pick any two.

It also applies when writing software for accounting. TurtleSoft is not rolling in money like the early to mid 1990s, so this time around we had to go for cheap/slow/good rather than cheap/fast/bad.

One issue we still need to decide on is file size. For that, the choice is more like fast/small/reliable, pick any two.

The NeoAccess database we used for Goldenseal was fast & small, and not reliable. We had to rewrite their code in order to make software good enough to sell. It made files bigger. Some of that was because we added sanity-check data to the indexes that kept track of where each record is located. We also added a second place to store record addresses: a list sorted by file location instead of a binary tree. That way, if the Neo code lost track of a record, we could still find it and repair the damage.

For the new accounting software, we used the same ideas, but added a few more to make the database even more reliable. It has a price. An empty Goldenseal file starts out at 106K. The new app currently starts at 14 megs, over 100x bigger.

Much of the extra bulk comes from a design decision. Any record database needs to keep lists of where records are located in the file: it’s called an index. There are over 200 record classes, and each gets its own index.

NeoAccess started a new index the first time you used a class. It went at the end of the file. Once an index had 8 records, another index went at the end (later we upped that to 32). Their approach was frugal with both RAM and disk space, but the result was indexes scattered throughout the file. They were hard to locate, and fragile. One stray bit change in an index could destroy a big chunk of the file.

The new app starts with 200+ empty indexes at the beginning of the file, even if you don’t ever use them. Doing that adds to file size, but it makes repair easier. We know exactly where everything is. Right now the indexes are big enough that the “tree” of indexes is not very deep. We can shrink them, but it will make things slower and a bit less reliable.

Another index tracks the contents of each file sector. More empty space at start-up. We also can shrink that, with similar consequences.

Goldenseal is a monster. It does all sorts of things: construction estimating, accounting, project management, rentals, sales, contract writing. Most users don’t need all that. We really need to pivot to smaller, cheaper apps that just do one or two things. Those users probably won’t like to start with a 14 meg file.

This is one of several quandries we are still working on, in the time left before first release. There are many things we can do to reduce file size, but it’s a matter of weighing the costs.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Almost a year ago, I announced we were ready for a first release of our new accounting software. However, the app just was not ready then. Testing turned up more bugs than expected. Too much important stuff was still undone. Also, building a finished app able to install on Mac and Windows machines proved to be harder than expected. There are extra hoops to jump through, these days.

After a extra year’s work, code quality is looking much better now. Almost everything important works like it should, and almost all serious bugs are zapped. Last week we fixed about 1000 minor compiler warnings. Most were trivial, but a few future mystery bugs lurked in there. Those are now zapped.

The past couple months our staff has focused on multi-user coding, and now Android. Soon iOS. We found a good subcontractor who is doing the hard stuff. What that is done, we probably will also hire him to set up the final builds for Mac and Windows apps. Most likely it will happen in 2 or 3 months. During that time our staff can do more testing, and iron out more wrinkles.

Being able to run business software on any combination of desktop, tablets and phones will be a big plus for TurtleSoft. Intuit and most other competitors have shifted to online “software as a service” systems. The monthly fees are great for their bottom line, but it leaves a gap that we can fill. Some small businesses will prefer to run locally with their data stored on their own desktops. If they can also use phones and cheap tablets at jobsites and on the road, all the better.

A year ago we assumed the first release would be an “alpha”. Something to look at, but not reliable enough to use long-term.  This year we’ll start with a “beta” release. Some lingering bugs for sure, but good enough to rely on day to day.

Dennis Kolva
Programming Director
TurtleSoft.com

When thinking about computers, I like to compare them to automobiles. Both technologies have followed similar paths, with a gap of about 100 years.

Cars and computers started out big, slow and awkward: massive steam tractors in the 1850s and 60s; room-size mainframes in the 1950s and 60s.

Then came a half-century of innovation, much of it done by small start-ups. One round created useful vehicles to move people and goods faster than horses. The other built hardware and software to run a business, view cat videos, and do other amazing things with glowing rectangles.

Next was a couple decades of industry consolidation. For cars, most innovators either disappeared, or became brand names at General Motors or Ford. Computer hardware and software followed a similar path, boiling down to Microsoft, Apple, Google, Amazon, Adobe, Meta, Intuit.

Then came a long spell of bloat, perhaps because competition was gone. Cars grew chrome, fins and stylish updates, with little focus on being reliable transportation. With some exceptions (e.g. VW Beetle), 1920 to 1970 was filled with gas-guzzlers: dangerous on the road and hard to maintain.

It took a few more decades until cars turned into reliable transportation that just worked, without much fuss. My current Honda Fit is light-years more reliable than my first vehicle in the 70s: a Fix-Or-Repair-Daily pickup truck.

Computers are not doomed to follow the exact same path as cars, but they sure are in the bloated/mediocre stage now. TurtleSoft first faced that 20 years ago, as Apple migrated through chips, frameworks and programming languages. At first we kept up, but each change grew harder. Goldenseal 4.96 was the furthest we could go without a total rebuild.

Coding a 64-bit desktop accounting app was a long, failed slog, mostly because of poor quality tools from Apple and Microsoft. Qt, a surviving scrappy start-up, saved the day.

Right now we’re struggling to build accounting for Android. It relies on code from two other superpowers: Google and Oracle. Setup has been a version-matching nightmare. We still can’t get it to build apps on TurtleSoft computers, despite more than a week of trying. There are too many libraries necessary, and no instructions on how to get them working with each other.

We will persevere, but it’s not an easy task.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

Our new accounting software now runs on Android tablets. It’s not even a reduced version: the GUI is almost identical to the desktop app. You can store your company file on the tablet, and use it just like a cheaper laptop. It’s also possible to keep your data on a desktop machine at the office, and sign on as an Internet client.

We haven’t tested the tablet version yet, to make sure it lives up to the promise. Our staff is still setting up Qt and Android so we can build the app here and run it. Setup is a complicated process. At the moment, all we have is a screen recording showing that the software works.

It may take a fair amount of testing and tweaking to get Android tablets to be crash-free. The app relies on at least 4 layers of code libraries, and they don’t always work well together. Even worse, Android doesn’t have much of a debugger, so we can’t step through the code to figure out problems. It may need much trial-and-error to get everything in order.

Work also is progressing on a phone version. That will be much simpler than the desktop and tablet versions. It only acts as a client, and only does one thing at a time. Getting phone accounting apps to be reliable will be much easier. They probably also will be used more often, simply because everyone has a smartphone in their pocket these days.

Next on the list is iOS apps to run on iPhone and iPad. With luck, programming those will go as smoothly as the Android project.

So far, Qt seems to be performing pretty well as a multi-platform development tool. There’s a lot to be said for writing code once, then having it run on 6 different types of hardware.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff uses the Qt framework to build the new accounting software. It creates apps for both Mac and Windows. If there’s enough demand, we could even release something for Linux.

Every month or two, Qt gets an update. Usually they don’t affect our code, but the latest one broke the Windows GUI. All colored backgrounds suddenly went white.

A while back I ranted about past hassles with text on computers. Colors have a similar rocky history. This is not the first time they’ve caused problems.

Our first estimating software (MacNail) ran on the Mac Plus, with simple one-bit black & white pixels. Monochrome was the rule back in those days.

Soon, the Mac II came along with an 8-bit graphics card (enough for 256 colors). In order to actually see more than B&W, we had to jump from the standard one meg of RAM to 4MB (an extra $4000, inside an already expensive machine).

Because memory was so precious, apps and hardware often used a smaller range of colors: usually 8, 16, 32 or 64 of them. Goldenseal still contains ancient code to deal with black & white and the many possible color gamuts.

256 colors was enough for many tasks, but it was too sparse for photos. The best you could do was a custom set of colors to match the contents, then dither with dot patterns to get anything in between. Not great, not terrible.

As computers matured, RAM grew cheaper and colors improved. First it was 16-bits (65,000 choices): fine for almost everything, but photos still needed to be dithered. The specs used 5 bits apiece for red and blue, and 6 bits for green.  Human eyes are more sensitive in the middle of  the spectrum.

Then came 32-bit full color, with one byte apiece for red, green and blue. It allows for 16 million hues, good enough for all but the fanciest photo editing (humans can only distinguish a couple million colors). The left-over byte was soon used for transparency (called the alpha channel).

Life would be easier for programmers if everyone standardized on one color system, similar to UTF-8 for text. Sadly, that is not what happened. Web standard is 32 bit RGBA, but Apple uses decimal numbers instead. Qt stores 2 bytes apiece (64-bit colors). The spectrum also may come in CMYK (cyan/magenta/yellow/black) or HSV (hue/saturation/value), plus the usual RGB and RGBA. They all get to the same places, but with different numbers and different math.

The current Goldenseal uses a palette of 256 colors for lines, text, and field background colors. We set up a custom color palette with extra pastels (for backgrounds) and dark shades (for borders and text). Still plenty of bright colors in between.

We would have kept the same setup for the new accounting software, but 32-bit colors are easier to program. We actually store 64-bits for them, just to be compatible with Qt. Memory is cheap, and maybe it will help for a future RobotOS which adds X-ray vision.

Meanwhile, alpha channels are still evolving (it’s what broke our Windows version). Opacity doesn’t have much impact on accounting software, but we did find a few places to use it. You might like having alphas if you print forms in color?

Color pickers only set RGB colors, so the new Custom Layouts puts transparency into a separate dialog. Right now, it gives weird decimals as we convert between percents and integers. 100 doesn’t divide into 256 very well.

Dennis Kolva
Programming Director
TurtleSoft.com