Month: September 2024

Two months ago, our staff was ready to start serious testing on the new accounting software. Again. We do that by “eating our own dog food”. That means daily use to run TurtleSoft and SmartKnives. It was at least the 30th time we’ve done that. Each attempt gets a bit further.

What stopped us this time was printing: invoices and sales receipts were ugly. Custom Layouts is the way to fix that, but it still was missing some things. While adding those, all sorts of other bugs turned up, and were fixed one by one.

Printing is better now, but still not complete. It’s down to extra gray when drawing rectangles, and an ugly breakdown table. Sales receipts need one of those to itemize multiple items, and it needs to move down a bit to look good. Fonts are different, so some column widths need a tweak.

All that happens in Custom Layouts, and it stirs up a C++ problem. To change the table’s position, it has to act like the other fields: a click shows handles, and a drag moves it around. To edit columns, it has to be a table: double-click in a column shows details to change, drag on the edge of a column changes its width.

TCQ_LayoutField is our C++ class which handles the clicky and draggy stuff. It’s a type of QWidget, the Qt class that draws stuff on the screen (plus other tricks).

TCQ_Table is another C++ class which makes a spreadsheet-like table. It has children that handle each place it is used: in breakdowns, lists, reports, and printed forms. TCQ_Table is also a QWidget.

Custom Layouts has a TCQ_TableLayoutField which acts like both. The C++ way to do that is to give it two different parents. Normally that is no big deal, but this time it creates a dilemma. There are two paths to QWidget: which one to take? It’s called diamond inheritance. Kinda like incest, but for screen objects.

Up until now, TurtleSoft has never made any diamonds. There always has been a way to avoid them. We tried a few ways to make that happen for TCQ_TableField, but all had serious problems. So, right now we’re trying the diamond. When the compiler complains, we just need to tell it which branch to take.

This is a bold experiment in advanced C++ design. Tables still don’t drag right in Custom Layouts, but we’re working on it. Worst case, our staff will toss a few days work and try some other way.

Dennis Kolva
Programming Director
TurtleSoft.com

People usually procrastinate when projects begin, then rush around at the last minute to finish. It’s all because of net present value.

NPV is an accounting calculation that gives the current value of a future asset/liability. Getting money today is better than getting it next year, so NPV uses a percentage for risk/interest/opportunity cost to adjust from then to now. Multiply that by the time delay then subtract, and you get present value.

Likewise, spending time or money next year is better than doing it today. The math says: the more you can push to the end, the better.

Net present value is not something we calculate in our accounting software (though depreciation is almost the same). NPV is a planning thing, not bookkeeping. If you need it, Excel has a function to give a number quickly.

Allocating time and effort is important for survival, so every living thing seems to have an internal NPV calculator. Usually, it says “don’t think too far ahead”. In fact, humans have a much longer time horizon than most other species. Excepting beavers and orcas, maybe.

Work on TurtleSoft’s accounting software has gone that way. At first, completion seemed close: just a year or so to finish. So, the project was all-consuming. The expected reward was large, and worth whipping out in that time frame.

When things proved harder than expected, work slowed down. Other projects with nearer rewards took precedence. Then Covid took massive attention for a spell: fear of dying will do that. Despite all the barriers, programming did continue. Just slowly.

Now that the end is in sight, the new accounting software gets more attention and time. That probably will accelerate.

It also helps that TurtleSoft is firmly settled into its new home. The garden did great this summer, thanks to work put in over the past year. Some construction still needs doing, but nothing major. No more relocations are on the horizon. Finances are solid, unlike the final push to finish Goldenseal. That version was built on massive credit card debt. There’s much less anxiety, this time around.

Dennis Kolva
Programming Director
TurtleSoft.com

Back in July, our staff needed to tweak TurtleSoft’s printed forms so we could test the new accounting software in daily use. It meant adding more features to Custom Layouts. Every time work seemed to be finished there, something new came up. There have been many “last on the list” items.

Rich text is last on the list (so far……..). It’s what you see here: text with bold, italic, font changes, and other formatting.

The good news is, rich text was easy to add to our multi-line fields. One line of code, setAcceptRichText(true); was enough to turn it on.

The bad news is, Qt does it in a weird way. From the name, we figured they’d use RTF (rich text format). It’s a simple markup language developed by Microsoft in the 1980s. RTF is supported by MS Office and many other apps, and it would be perfect for our accounting software.

However, Qt uses HTML, instead. It’s probably a wise choice for the long term, since everything seems to be web-based these days. But HTML is way overkill for an accounting app.

For one thing, their approach is bulky. Every field has at least 465 bytes of hidden markup text: even if it’s empty. Basically, they set up a whole web page. Actual content can easily have more hidden HTML tags than text. RTF is much more compact than that.

Also, Qt only has partial support for HTML and CSS. It ignores php and JavaScript completely. So, text pasted from web pages may lose some details. Pasting from RTF has similar problems: some things don’t make it over because the tags are different.

Even worse, there’s no way to edit formats while inside our new accounting software. Text must be created in a word processor or other app that handles HTML, then pasted in. You can’t just type in rich text, nor can you change it after it’s there.

Qt does have classes to set up a rich text editor and/or an HTML viewer. But they’re complex, and meant for whole scrolling windows, not database fields. A mini text-formatting bar would be nice, but Qt doesn’t have one. Our staff does not want to program one from scratch. It’s a several-month project.

For contracts and spec-writing, HTML may be worth the downsides. Elsewhere, probably not. So, rich text is turned off by default in the new software. Custom Layouts has a checkbox to turn it on, for fields where you really want the fancier formats.

Rich text is slightly nifty.

Dennis Kolva
Programming Director
TurtleSoft.com

 

On a whim, our staff pasted some emojis into the new accounting software last week. It worked! The text saved fine to the database, and displayed properly. Much easier than expected. It’s all thanks to Qt’s robust support for UniCode.

Unicode is the standard format for all kinds of text, these days. It includes Ελληνικά (Greek), Українські (Ukranian), 한국어 (Korean), and any other language on this planet. Plus ♔♕♖♗♘♙, 😝🍑🏈🔥💩 and more.

This is one area where it really paid for us to procrastinate. Computer text has had some difficult times, but we missed most of the pain.

A typical English-language typewriter or keyboard has 47 printable keys, give or take a few. With shift and space bar: 95 characters. ASCII is a 7-bit system (128 choices) that’s big enough to handle it. Leftover slots are used for line feeds, tabs and the like.

Apple expanded ASCII to 8 bits. That’s what Goldenseal uses. The extra 128 characters include diacritics (ßàæçñòóôõö etc), Greek letters, extra currency symbols, and fancier punctuation. Other companies also expanded ASCII, but everyone used different setups. It’s why you’ll sometimes get emails with weird symbols.

8 bits is sufficient to cover most European languages. But move east, and there are whole new alphabets. Too much for just one byte.

For a while in the 90s and early Aughts, the solution was wchar_t. It’s 16-bit text, with 65,536 possible characters. That’s enough to hold alphabets for Britain, Thailand, and all points between. Wide characters support العربية (Arabic), کوردی (Kurdish), हिंदी (Hindi) etc.

That era was not fun. Some things still needed ASCII, some needed wchar_t. Use the wrong one and you’d get gibberish or worse.

Microsoft created a special hell, with LPSTR, LPCSTR, LPWSTR, LPCWSTR, LPTSTR, LPTCSTR, CStringA, CStringW, bstr_t, CComBSTR, WCHAR and TCHAR, all for different types of 8 or 16-bit text. There were equally obscure ways to convert between them: CW2A, C2AEX, etc. Use the wrong one and code would crash: sometimes suddenly, sometimes randomly later.

Move on to East Asia and wchar_t had another problem. China/Japan/Korea use ideographs: a different symbol for each word. Many thousands of them in each dialect. 2-byte text lacked space for them, so it wasn’t good enough for global use. It also was twice as bulky for regular Latin-language text.

Unicode fixed all that. It’s a clever system that mixes characters of different sizes: anything from 1-byte Latin to 4-byte 𒁎 (Ancient Sumerian). With over 4 billion possible glyphs, there’s room for every human language, current or extinct. Plus music notation. Emojis. Dingbats. Weird math symbols. And plenty more.

Even better, Unicode converts easily to UTF-8. That’s an 8-bit format that programmers can use to treat Unicode just like simple Latin text. Thanks to UTF-8, text-handling code inside our new accounting software accepts Unicode with no need to rewrite anything.

The new accounting app will have a few problems with Unicode, but nothing serious. Find works OK with special characters or emojis, but sorting won’t know what to do with non-Latin text. You’ll need to be careful with fonts: none support the entire gamut of Unicode, and some may be Latin-only. Other quirks may arise.

The next thing for us to test is rich text: with multiple fonts and formats inside. The Qt class we use for multi-line fields supports it. If we’re lucky, that also will be easy.

Dennis Kolva
Programming Director
TurtleSoft.com