Some programming toolkits give you more control over the visual appearance and functionality of the user interface. One of the things I want to do is make the RSS Reader have an appearance that is 100% custom. The following charts the progress towards updating the RSS Reader user interface to a better form. The C++ code responsible for producing this is available at https://github.com/michaelgautier/gautier_system/ in reference to commits for 1/5/2018.
I was eager to continue with FLTK as it provided a solid balance between productivity and control. However, I encountered problems with FLTK in that it could not keep up with screen updates when working outside of its preferred programming model. I could use FLUID interface builder for FLTK but I was never interested in that. I could stick to the implied way FLTK wants you to have callbacks but that has its own issues when moving back and forth between class scoped objects and implementation module scoped objects. I found a useful way to work through that, but the final results in user interface updates was display glitches and button callbacks that did not materialize. Perhaps with more code, I could have worked around those, but I figured if I am going to write a lot more code for the user interface, that effort would be better spent in a direction that is more certain to deliver. What sealed the fate of FLTK was that the contents of an Fl_Group couldn’t be dynamically removed and replaced with corresponding screen updates that was stable. Likewise, linking callbacks to replacement widgets resulted in no materialization of associated functionality. Rather than spend days or weeks troubleshooting that, I decided to cut my losses in that direction.
The next thing I tried was wxWidgets. The homepage looks good. I read the book years ago and think the overall offering is solid. However, if I want to experiment with the third-party wxWidgets library and compile/link it in different ways, each revision to the configuration results in approximately 15 minutes of compilation time with a 2-core Intel i7 and 16GB RAM with SSD storage. I started timing it after about the 3rd time. After about a combined 2.5 hours compiling different versions of wxWidgets, I decided that is too much administrative overhead if the moment was ever critical. Anyway, I looked at the programming model for wxWidgets and it is superb if you want a framework that automatically manages many aspects for you but I’ve been down that road and I saw a future of even more code than what I thought said solution would justify. At the same time, the website’s recommendation against absolute position of visual items seemed inflexible.
I realized that the user interface design layout I was pursuing actually favors using the Allegro video game library. I returned to the RSS Reader I had done in Allegro a few years back and decided to merge it with the FLTK inspired design. I have written more code than when I was using FLTK but the code I’ve written is more predictable with greater control over the output and behavior. The roadblocks I ran into with past efforts has actually given me better judgment in the coding and the I’ve gotten to a better place faster with Allegro than I did previously. Those roadblocks have also given me a better appreciation of the trade-off between seemingly easy solutions versus those that require greater involvement. The result shown below required more code than previous versions and is far more reliable. The solution requires more mathematics and geometry concepts but the result is much better. The Allegro 5 video game code library was used to produce the output shown below.
Regions of Functionality
The solution starts with establishing regions of functionality. Each main block is where certain kinds of activities and information output will occur at a conceptual level. The code at this point is concerned with maintaining each region as it appears. Video game mechanics is such that the screen is constantly updating. What I wanted to do is put in logic checks that reduce unnecessary screen updates because while I am using a Video game library to build a user interface, I do not need the same frequency of real-time screen output. Some game programming experts say to avoid this technique of suspending updates and if they are right, I will pull it back. Another goal here is to establish the overall geometry and geometric boundaries that constrain functionality.
A useful aspect of many user interface programming libraries is in how they make widgets available. You cite a widget in code and the underlying library or framework takes care of producing the default visuals and associated functionality. At the level I am programming here, there are no widgets. No out-of-the-box functionality. It all has to be derived from scratch. A good place to start is to define geometric boundaries that will serve as the detection points for functionality. When a click of the mouse occurs coinciding with one of the boundaries, the logic can then associate the geometric region with functions to execute.
Another step is to place text in the right parts of the screen. Notice how the list of headlines are clipped so they don’t go past the geometric region in which they began. Actually, they do, but due to natural z-ordering, I didn’t have to put in place a clipping rectangle as would be typical. A useful side-effect of how the screen is being laid out.
Many of the graphics programming books focused on C or C++ I’ve read over the past 8 – 10 years tend to use graphs for the user interface. I used them quite a few years before that but discontinued their use when the programming toolkit makes their use excessive. What I see with this type of solution is a graph has a better case. The user interface geometry is accumulated into a graph structure that is then used to determine with Allegro drawing API are called to present the user interface. That approach seems to offer a good level of decoupling and with continuous refinement, will work to provide a good balance in productivity and result.