Colors (Dec 27)

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

 

 

Mobile Apps (Dec 18)

Our new accounting software now connects over a network. Your company file sits on a Mac or Windows computer, then other users can sign on as a client. Goldenseal already does that over a LAN (local area network), but the new app also lets you use the Internet to log on from anywhere. It will make life easier for any construction business that spends time on job sites, or runs business from a truck.

The next step: mobile apps that do the same thing from a phone or tablet. Networking code for them is similar, but user interface and operating systems are different. Mobile is actually five different platforms.

iPhones and Android phones are the most common, and also the most difficult. Because their screens are tiny compared to desktops, they need a totally different user interface. Ours will just be a simple list of fields showing data from a desktop server. Here’s a really rough mock-up:

You’ll drag up to see more fields. Swipe sideways to see breakdowns or Find mode. To enter data, press a field, then either choose items with a finger-press, or type on the tiny keyboard. Changes save to a desktop server over the Internet. Our subcontractor is working on that now.

Rather than switch modes in one phone app, we’ll have single-function apps for each type of record. One will shows contacts. Others will handle labor hours and simple material purchases. Beyond that, we’ll wait for user requests. It may be possible to design some sort of construction estimating for simple projects, but phones really are the wrong size for that.

Tablets are totally different. They have enough space to fit the current desktop interface, so there’s no need to design a new look. The hard part is operating systems. There are three options.

Apple’s iPadOS is evolving the iPad into a slightly smaller and cheaper Mac. It runs real apps like Numbers and GarageBand. The problem will be Qt. It supports iOS, but four generations behind. It’s still not clear how much of the full app it can move to iOS. If we are very lucky, the new accounting app will run on iPad: either as a client, or as a stand-alone. If not, then it will just look like the phone app. Maybe we can make the window two columns wide and a bit prettier.

Android tablets have a similar problem. Probably worse, since they don’t have a desktop cousin. Our contractor is working on Android first, but anything on tablet probably will just be a bigger-screen version of the phone app.

Windows tablets will be easiest, since they can run regular Windows desktop apps. We’ll test the new accounting app on one soon, to see how practical it is.

Laptop computers are not much bulkier than tablets, so they probably are the better choice for most businesses. You get a keyboard and track pad, plus normal desktop apps. It’s easy to plug in a mouse, trackball, full keyboard or other USB devices. However, tablets do provide an opportunity. I’ll discuss that more in a future post.

Meanwhile, our staff is back to testing and bug fixing in the regular desktop app, plus tweaking a few final details in the multi-user version.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Network Ports (Dec 10)

Connecting your computer to a network isn’t hard, but plenty of stuff goes on behind the scenes to make it work. One part of that is ports: channels that carry a certain type of traffic. The multi-user version of our new accounting software needs one so clients and servers can talk to each other, whether over a LAN (local area network) or an Internet connection.

There are 65,535 possible ports (two bytes minus one). First up are the well known ports, using the first 1,023 numbers. For example, http web traffic moves over port #80, while encrypted https uses #443.  For email, there’s #109 for POP2 and #110 for POP3.

Most well-known ports are already allocated for something. They are much too classy for our accounting software.

Next step up are the registered ports, from 1,024 to 49,151. Only 10% of those are filled. Last week TurtleSoft sent in an application to register #21,587 for the new app. It’s TS as text. Goldenseal has been using #18,259, which translates to GS, but we want to keep them separate.

The Internet Assigned Numbers Authority (IANA) assigns ports. Sadly, they shot us down, and said to use the temporary range (49,152–65,535) instead. We appealed, explaining how users needed something easy to remember. Nope, shot down again.

Then we looked at the list of registered port numbers on Wikipedia. TurtleSoft is not the only one out in the cold. Apple, IBM, Microsoft, Cisco, Minecraft and many others use an unofficial port number rather than a registered one. Apparently IANA is stingy to everyone.

Right now, nobody else has registered GS or TS, and that status probably won’t change. So we will use 21,587 (TS) unofficially for the new multi-user accounting software. In the unlikely case that our port conflicts with some other app, you can easily switch to a different number.

Meanwhile, the networking code is almost finished. Soon we can get back to regular testing and programming.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Subcontractors (Dec 2)

The multi-user version of our new accounting software is moving right along. Clients can sign on to the home computer over a LAN or Internet now. Their window is starting to look like the single-user version. There’s still more to do, but the end is in sight. Work has also started on mobile apps for iOS and Android, for phone or tablet.

The multi-user code is a joint effort between our staff and a programmer in Turkey. He handles the Qt and network portions of the project, while we build the GUI and business parts. Often there is overlap in between.

Much of the work on our end is fixing bad design from a previous subcontractor. In 2000, we hired a large software firm in India to create Windows and multi-user versions for Goldenseal. They started with an experienced programmer, but soon shifted everything to a newbie. He wrote plenty of terrible code, and took shortcuts that still affect Goldenseal’s quality.

The project was promised to finish in 6 months, but it actually dragged on for more than 2 years. It would have gone even longer, but our staff chipped in and did some things just so we’d have an app to ship.

The poor-quality Windows code is long gone, but the networking still needed an overhaul. That task has taken a few weeks already, and probably will need a couple more.

Over the years, TurtleSoft has hired about 20 different subcontractors, and negotiated with more than 100. Most were for C++ work, with a few for website and shopping cart setup. Individual programmers have usually worked out the best.

It was the same way with Turtle Creek Carpentry. In two different decades, we shared projects with excellent plumbers who worked solo. Then they hired a small crew, and still were pretty good. Then they expanded too much, filled up with bozos, and became disasters. One electrician took a similar path.

Talent at hands-on work does not always translate to management skill.

Dennis Kolva
Programming Director
TurtleSoft.com