The following briefly covers a visual layout and C++ code structure for an RSS Reader. The visual layout has an eye towards a format useful for both desktop and mobile because who wants to make the same UI twice. The buttons will be big and clickable on a desktop and big and tappable on a mobile device. All essential functionality is designed to fit on 1 screen with no pop-ups or screen switching required. That requires a trade-off in which you have to keep away from nice to have features that would impose on the design.
I added a dash of color but obviously the aesthetic aspects are still in progress. The important thing is to work out visual customization in the context of FLTK. An important goal for this iteration was to resize the visual layout when the screen size changed. Easy enough in some other programming languages + widget libraries but challenging in the combination of FLTK and C++. The challenge was in applying resize logic in a way that addressed various aspects regarding fonts, screen resolution, and potential visual element reorientation. A previous iteration took the approach of clearing out the visual layout and rebuilding it. In the context of FLTK, that was a problem due to the way memory is allocated for some widgets. This iteration takes a smarter approach that I think combines solid aspects of video game and application-level user interface definition.
GitHub Update – C++ Class: mainscreengenerator.cxx
The latest update on GitHub involves an implementation file, mainscreengenerator.cxx. The implementation sequences and requests rendering of the above layout in the implementation file. Another implementation file, mainscreenblueprint.cxx determines the overall geometry and has been stable for 18 days. The output from mainscreenblueprint is fed into mainscreengenerator which applies the arrangement definition to widgets from FLTK to produce the layout. Sounds easy but the difficulty is in striking the right balance such that you don’t end up with individual sub-classes for every little thing you want to do. That was an option I wanted to avoid as that would give me maximum control at the cost of increased complexity. Finally, I reflected on some thoughts on Quora.com from David Warman who has been programming for 50 years and the final touch are the series of functions for returning widgets + the unification of screen size change with widget definition. The result is code that is simpler, cleaner, and better defined than the previously discussed iteration from 12/2/2017.