The following is a complete set of structures for a C++ GUI that can be compiled for Microsoft Windows, MacOS, Linux, and more. It took a lot to put this together roughly 4 hours a week during the last few weeks. Please refer to the previous article for relevant screen shots of how this solution appears. That article also discusses the GUI in general. The point is not the appearance of the GUI, which can and will be changed, but the structures that allow you to produce a GUI using C++ and the Allegro 5 Graphics library as the means to assemble a GUI. I spent the most time so far on scrollbars. I had never hand created done scrollbars from scratch.
The makefile is the means I use to compile and link all the source code into a program.
Defines the start of the program. As you can see, I am building a new version of the Rss Reader I defined in 2015.
Defines the overall structure of the RssReader at an application level. Some would call this the interface to business logic. I am not really fond of that term, but this is what that would be called.
Application level code for the RssReader in which all the parts are brought together. When you compare this to the previous article, the code itself is quite different, but yet, the same.
The interface between the “application” or business logic and the actual graphics technology that makes the GUI a reality.
The primary code for interfacing with the Allegro 5 Graphics library. It was either consolidate it all here or merge it into the application level code. While consolidating the code results in more code written, it makes the overall access to the graphics system more manageable. It is also here where you most clearly see that I am “wrapping” many parts of Allegro, a C language library, in C++ by way of a class definition.
The previous article showed graphics drawing calls at the application level. I decided to encase all that in a type I call InteractiveRegion.
The code for the interactive region. This is the “bridge” between the graphics system represented by Allegro and the procedural approaches preferred by the “application level” code to define graphics boundaries, colors, and interactivity output.
This is a struct that I threw in after much time troubleshooting a gap between when a mouse is clicked/moved and when the “application level” code receives it. Use of this structure (referring back to Robert Nystrom’s Game Programming Patterns) simplified things immensely and resulted in stable interaction messaging between the graphics subsystem represented by Allegro and the application level code.
That is the entire solution in a nutshell. I spent quite a bit of time on getting the scrolling just right. I like it.