In movies, programmers usually sit at a terminal and type pages of dense computer code, at breakneck speed.
In reality, programming new GUI code tends to go more like this:
- Try a few Google searches to see if someone has written a tutorial on how to make the new thing. If not, search Stack Overflow for related questions.
- If that is not enough, look through the list of Cocoa or MFC classes for anything already designed to do the new thing. Search again for tutorials on how to use those.
- If desperate, check the indexes of a few reference books. Try more searches with slightly different words. Or give up, and try a completely different approach.
- After getting a vague idea of how to proceed, search Google and GitHub for sample code. Apple and Microsoft both have tons.
- If there are sample projects, run them and see if they do the job. If so, step through the code in the debugger and try to understand it.
- If no samples, search. Probably some smaller code samples, somewhere.
- Copy/paste the likeliest code into the actual project. Tweak as necessary. If totally desperate, write a few lines of brand new code. It rarely takes more than 5 or 6 lines to do the job. Often it’s just 1 or 2.
- Run it and see if it works. If not, step through the code in the debugger and find where it breaks.
- Test it, tweak it, test some more, tweak some more. This requires a small amount of typing, but most of the time is spent running the program, dozens or hundreds of times per day.
- In some cases, throw it all out and try a different approach. Repeat steps 1 to 9.
If it weren’t for debuggers, it would be nearly impossible to write complex software. “Debugger” sounds like something you can wave at bugs to kill them, but unfortunately it’s not that easy. Instead, you set a “break point”, then run the program. When it gets to the break, you step through one line at a time, and see exactly what changes when. Sometimes the problem is obvious, and sometimes it takes many trials.
We are making gradual progress on the new Macintosh interface. Here’s a screen shot link showing what it looks like now:
There is an outline view on the left that replaces all the old pull-down menus. There’s a “book” to navigate through records, and tabs at the bottom to switch between what used to be separate windows. We will still let you open multiple windows, but they will be optional.
When we first started the Pro update, the plan was to have subcontractors rewrite Carbon to Cocoa (Mac) and QuickTime to MFC (Windows), keeping the same appearance. That way the contract specs were easy, since it just had to match what we already had. The plan was to start redesign work after the conversion was finished.
Now that we’re doing the work in-house, it makes more sense to combine the redesign with the general code updating. So far we have made many more changes than first expected, but it’s also looking much better than expected.
Cocoa is not easy to master, and it probably will take us at least another month before all the basics are working on the Mac version. No insurmountable problems, but there are many details that each take a day or two to finish. Fortunately, we only have to do this once. It’s going to be a real pleasure when we can get back to writing plain old C++ business code.
Turtle Creek Software
Last week we added top controls to the Mac version, so it looked sort of like a Windows ribbon. It didn’t take long to find that it was too cluttered, and not all that useful. So the main window got one more redesign, and we are quite happy with the final product. It’s possible we will remove ribbons from the Windows app also, but we’ll get the Mac interface further along before we go back and decide on the final Windows appearance. It’s kind of a leap-frog process, jumping between platforms every few weeks.
There is still one big design issue left, which is the breakdown tables for itemizing smaller details in Estimates and other records.
When we first wrote Goldenseal estimating/accounting software, none of the C++ libraries had good tables. We had to write that interface from scratch, and probably spent a programmer-year or two on it. Tables have complicated code that has not aged well. Fortunately, both Cocoa and MFC have mature table classes. We can get reliable appearance, scroll-wheel support, column sorting, and other pleasant features for much less work than the original.
The big design question is, where to put them? Currently, Goldenseal switches between entirely different layouts when you click the Breakdown popup on the left side of the screen. There are at least two different types of tables that can sit below the other fields, plus a no-table view.
Many users have found that system confusing, so we probably will simplify to a single layout, with just one type of breakdown table. Cocoa has “drawers” that can open out to the right, and that seems like a great place to put the (optional) breakdowns. It fits particularly well with the new single-window setup, and today’s wider screens.