Undo & CAD (Sept 25)

Undo support is a real PITA for programmers: it makes everything 2 or 3 times harder. Luckily, we don’t need it for many things in our accounting software.

Undo is most useful while you edit text, but the OS and frameworks already handle that for us. We just inherit from QTextEdit or QLineEdit, and it works. Popups and other data entry fields are easy to change, so they have little need for undo. Worst case, you can Revert Record and go back to the last saved version.

Custom Layouts is the only place that needs lots of Undo code. It’s a drawing environment that lets users change the appearance of data entry screens, printed forms and reports. While tweaking layouts, you’ll often want to reverse small changes.

Programming Undo often requires sneaky tricks. For example, when you delete something, it just becomes invisible. Undo the delete and it appears again. The actual deletion happens later.

Goldenseal has single Undo. You can reverse the most recent action, but that’s it. The new accounting app is a bit better, with multiple Undo. You can go back step by step and undo each action since the last Save.

To figure out how much to undo, our staff has been checking other graphics apps. It’s good timing, since we just closed on a new house last week. We need to make floor plans for future rehabs, and to help decide on office layout before lugging desks and file cabinets.

When Turtle Creek Carpentry first computerized, MacDraft was the best app for blueprints, even though it crashed frequently. Eventually MacDraw improved enough to be a more reliable replacement. That worked great for a decade or so.

Sadly, most of Apple’s apps did not survive the switch to OS X. We still have all sorts of handy data that can only be seen on antique machines running OS 9.

These days, we have yet to find a decent, simple CAD app to replace MacDraw. Some apps are awkward. Some lack important features. Some are way too complicated. So far, LibreOffice Draw and FloorDesign2 seem the best of the lot, but neither is as functional as stuff from 25 years ago. Many innovations from the early Macintosh just faded away.

When it’s finished, Custom Layouts will have about 1/3 of the code needed to recreate MacDraw Pro. It will be very tempting to spin off a simple CAD app, some day. However, we do have more important things to work on right now.

Dennis Kolva
Programming Director
TurtleSoft.com

Colors (Sep 15)

Our new estimating/accounting software still had one unfinished data entry field: a color picker. It’s only used in Cost Categories, for Estimate breakdowns. Colors make it easier to see which items belong to each project phase.

Getting the picker to work was easy: just a few lines of code. Tidying up the source code for colors took longer. Some parts are as cluttered as an attic or garage. Kinda like a 30-year time machine, showing the evolution of PCs.

Goldenseal began when most personal computers used 1-bit monitors. Back then, there simply wasn’t enough memory for more than one bit per pixel. Black & white for Macs, various pairs for MS/DOS.

As RAM increased, colors crept onto the scene. The earliest used just 3 bits: six colors plus black and white. Later, Macs upgraded to 4-bit colors: twice as many choices. There was pink! Light blue! More than just Roy G. Bv. Later, 6-bit and 8-bit became common, expanding the gamut even further.

All those were indexed colors. Each pixel chose from a palette of 8, 16, 64 or 256 shades. For anything in between, you dithered two colors in a pattern. OK when viewed from a distance, but pixelated in close view.

By the time Goldenseal shipped, nobody used less than 8-bit colors (256 choices). Our code supported five different bit depths, but ignored four of them. The system palette was too garish, so we made a custom version that was mostly light tints (for backgrounds) and dark shades (for text).  Data entry backgrounds used 24-bit true colors to get more pastels.

Twenty years later, RAM is cheap. Nearly everyone uses 32-bit colors. Rather than a palette, those have 8 bits apiece for red, green, blue and alpha (transparancy). That’s 16 million shades, good enough for most uses. It’s what we use everywhere in the new accounting app.

Apple goes deluxe, with 64-bit colors in their Cocoa framework. The extra depth is a slight improvement for high-quality photo editing, but overkill otherwise. Few users will notice the difference.

Sadly, for a few years we used Cocoa for the new accounting app. Some of our color code is still 64-bit. Switching between the two sizes sometimes causes bugs, but at least they are obvious and easy to fix. If Qt ever enhances their color setup, we’ll be ready.

For business forms and data entry screens, the old 8-bit palette was perfectly fine. Colors aren’t any better in the new system. In fact, the pickers are more complicated now. Too many choices. However, we updated to full color despite that, because it’s easier. Our staff has better things to work on than a retro popup of 256 color squares, made from scratch.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Graphics & Company Logo (Sept 8)

We test the new accounting software by using it for our own daily business. Sooner or later, a bug pops up: that’s the whole point of testing. If the fix takes too long, we need to go back to just using Goldenseal, instead of both in parallel. That cycle has happened dozens of times in the past year. Each time it gets a little further.

Earlier this week we got printed forms looking good, but they didn’t have a company logo. Time to fix that.

Goldenseal uses a Mac data format called PICT. It’s long gone. These days graphics are handled with files rather than blobs of binary data. It’s a whole ‘nother way of doing things that needs brand-new code.

The new accounting app still doesn’t have a way to add new items to custom layouts. So that was this week’s project: start with the simple things and work up to logos and graphics.

First were squares, ovals, rounded rectangles and lines. Next, text captions. Those need a dialog for the text. Then new fields and buttons. One step more complicated, since you choose from a list of possible items. It needs a fancier dialog.

Finally, the stage was set for graphics. That was easier than expected. Add a file chooser dialog and a few lines of code, and it worked.

Right now, the app keeps files at their original location: Pictures, Documents, Downloads or wherever. Change the image, and it changes what shows up on printed forms. However, if you move, rename or delete the file, then the app can’t find it.

There are places we can hide image files. Those are harder to break, but not invincible. Install the app and company file on a new machine and they’ll be left behind.

The current Goldenseal stores images inside the database. No way to lose them, but that also has problems. Your company file can get huge, and reading/writing is awkward. We have to make a temporary file from the data, then delete it.

Graphics still need some design thought. There’s no perfect solution.

Dennis Kolva
Programming Director
TurtleSoft.com

Frameworks (Sept 1)

Goldenseal accounting and estimating software is many lines of C++ code. Our staff built its business logic, data storage, and most other details. The app also uses code from other people: mostly for the graphic user interface (GUI).

The current Goldenseal uses a 32-bit framework called PowerPlant to handle mouse, keyboard, and screen display. Its code is very lean: our staff still had to add many details to make it work.

PowerPlant was a solid foundation for 25 years, but the new accounting software needed something for 64-bit OS versions. The good news is, modern frameworks have more things built-in. We spend less time on screen drawing, mouse clicks and other basics. The bad news is, modern frameworks have plenty of quirks and flaws. We spend time dealing with those, instead.

As we move into the final phase of development, that’s most of what we do these days. Some fixes take an hour or less. The worst need a day or two.

One Qt problem has been worse than that. It’s been bugging us for months.

When you click in text fields, there’s a little blinking cursor that marks where text is added. Most apps do the same thing. However, when you click elsewhere or hit the tab key, the Qt field won’t stop blinking. Tab through several fields and it looks like a Christmas tree with flashing lights. We don’t want to ship it that way even though the flaw is not mission-critical.

After some futzing, our staff fixed the problem in fields that have text in them. But blank fields still blink away. Other folks have reported similar problems online, but nobody had a fix. We finally filed a bug report. Qt staff marked it as P3 Somewhat Important.  We shall see how quickly they fix it. We sure can’t.

There’s a bigger problem: all code these days is big and complicated. Lots of people work on it, and nobody has the big picture. As a result, nothing is as clean as it could be. Even worse, because of the complexity, every bug fix has a 25% chance of breaking code somewhere else. Programming becomes a game of Jenga. Or maybe Whac-a-Mole.

We face the complexity problem in our own code. We stick with it because whacking bugs feels so good when they finally flatten.

Dennis Kolva
Programming Director
TurtleSoft.com