The latest commit is on GitHub. I took the application-level code in RssReader.cxx and placed it into RssDisplay.cxx. The result of the change is the RssReader has a single responsibility rather than several. RssReader is now just a bridge between PrimarySurfaceDisplayWindow and the application-level processes. You have low-level graphics/interactivity requests/data covered by PrimarySurfaceDisplayWindow and they are converted to high-level graphics/interactivity requests/data received by RssReader. RssReader then maps the high-level request to the appropriate display screen.
RssDisplay represents the main display screen. Other screens introduced into the process would then receive the same graphics/interactivity request from RssReader in a standardized way. I introduced dynamic binding through a class named InteractiveDisplay. RssDisplay inherits from InteractiveDisplay which has virtual methods it overrides. I’ve kept use of virtual methods to a minimum and this is the only place at the application level in which such methods exist. The goal here is to enable multiple display screens conforming to a general standard for receiving graphics/interactivity data to respond to/use such data and then output to the screen within an overall screen output stage represented by the overridden UpdateVisualOutput function.
The program runs the same as before, but it can now be expanded in a more structured way in terms of how the program is defined in C++. The added structures improve isolation between the low-level part of the software from the high-level. The application-level (business end) of the program is now firmly divided from the graphics engine part of the program that specialized in the technical mechanics of forming windows, button clicks, and general graphics size changes. At the same time, the baseline is set to enable the addition of new screens in a manner that is more predictable.