The application framework that we have embarked upon has seen a few modifications on the way to a solid basis upon which to build a program. Abstractions were introduced in the last article, Exploring SFML Graphics in C++ – Refactoring Wave 3, that focused on cleaner and clearer ways to represent certain concepts such as windows and views. I have refined this framework to better express the idea of a view. A view is where graphic elements are arranged and contained and there needs to be an approach for defining, introducing and transitioning views. I do not describe that latter objective here but defining and introducing views or, in this case, a single view, is necessary. The information that follows show the progress that has been made in reaching this goal.
This is the final article on this particular series of refinements to the application framework and test program that I have been exploring. First, let’s start with some code.
The primary element added is a class named MVCViewBase. It is a base class that effects the means for referring to different views in a polymorphic way. Classes that are views derived from MVCViewBase are expected to implement operations implied by the interface defined by MVCViewBase.
The chief goal with views at this stage using this approach is as follows:
- Express a set of common operations, common to all views within the scope of the application framework.
- Implement processes unique to each view underneath a common interface.
- Produce a common output for the visualization system to process independent of the view’s logic.
The application framework has does achieve all of these goals. As it stands now, the application framework is largely complete in terms of fundamental capabilities and processing stages related to views. The following screenshot shows some of the classes introduced in this wave of refactoring as represented in the Code::Blocks development tool.
The structural improvements by way of the RAII technique discussed in the previous article on this topic has aided me in further cleaning up the test program to present functionality in a more cleaner and clearer way. Besides the improvements in C++ code legibility, I have introduced a test view as a class called ProgramViewFirstView. This view derives from MVCViewBase and is processed through a ViewStandardController for the purposes of producing a ViewModel in a standard way. The ViewModel is the product of the controller handed to the visualization engine.
Today that visualization engine is SFML. The intent is not focus on SFML but to have a reasonable upper level design that is flexible enough to use whichever engine makes sense. The visualization engine used here is SFML but it could be Allegro, OpenGL or DirectX or any number of visualization helper systems. The test program has been shaped to productively use the application framework that incorporates the SFML to exercise visualization capabilities in a robust and reliable manner.
The screenshot below shows the current state of the test program as represented in the Code::Blocks IDE.
Answering Questions Already Answered
Mainstream frameworks such as Microsoft C# WPF, Java Swing, C++ Qt have defined solutions that does this. Microsoft C# WPF only runs on Microsoft Windows; Java Swing may have deterministic code issues; and C++ Qt may lack deployment certainty. In an office setting in environments organized around Microsoft Windows, Microsoft C# WPF is perfect. Companies looking for exceedingly long-term software may opt for Java Swing and C++ Qt is obviously a useful tool for companies seeking to build desktop and native mobile software for sale.
Those tools have the qualities for defining views in an exceedingly easier way than I have arrived at this point. The question is why consider the approach I have laid out in these series of articles about an SFML based application framework in C++? The answer stems from my insights into cross platform software development. The answer is that sometimes you have to go in a different direction to achieve a certain result. The result I am aiming for is a narrower application framework that I can better calibrate to the quality and code design and deployment criteria of a varying nature. Building your own frameworks can enable you to achieve such goals but doing so costs more in terms of time and diminished initial certainty. As someone, like myself, pursuing this for purely exploratory reasons, the costs are mildly acceptable. Pursuing these goals when the stakes are higher or the time requirements are more austere means that you often defer to the more productive solutions from Microsoft, Apple, or Oracle which I am fond of in terms of their value in those cases where they are a benefit. Privately, however, I am pleased to explore a sliver of the process of what may constitute the definition of those tools for defining views.
Test Program Output
The ProcessEvent method of the ProgramViewFirstView class defines a sequence of actions in which a list of shapes are created. This list is eventually transferred from the view to the WindowViewManager to draw the visual data provided from the view through the controller.
The effort of structuring the test program and the application framework has been to abstract and organize operations and data in such a ways as to allow me to add views in a standard and clean way. Ideally, this means that a new view consists of nothing more than a class that has a list of visual data and methods that implement functionality in a manner that minimizes the extent to which that view class has to be concerned with the mechanics of presenting information.
Below is a screenshot of the test program when launched. The magenta square originates out of the ProcessEvent method of the ProgramViewFirstView class. As the program loops, it clears the display to a blue background and then draws the magenta square. It does this many times per second at such a rate that you do not notice that the square is removed and re-added on each turn of the cycle. Despite the more refined structure of the program, the code is still organized, at its core the same as it was originally defined in the first article titled, Exploring SFML Graphics in C++. This design may be inherently broad enough to allow more advanced expressions of views concurrent with interactive events such as keyboard input. If that is not the case, then the design may have to evolve to incorporate threads and callback functions unless my research and contemplation sees me to a different outcome. At this point, I have been satisfied to pursue a course that has seen the expression of the design in terms of abstractions in C++ in a certain direction. The culmination of this exploration is seen below and is largely unchanged across refactoring processes (Waves 1 – 4). This is good in that refactoring should maintain output while allowing you to decisively improve structure and code definition.
Code File Listing
All code files are available for viewing. You can find the final version for this series on SFML on GitHub. Just follow the path to building_cpp_with_sfml_wave_04 from michaelgautier/codeexpo. The next sub sections provide a few more details.
Application Framework Files
All of the files for the application framework are listed below. The major changes include the classes named ColorSpec; MVCViewBase; ProgramWindow; VisualWindow; VisualSettings; ViewStandardController; and ViewStandardModel.
Test Program Files
All of the files for the test program are listed below. Most of these files are the same files but the Program class has been rewritten and reorganized internally. The WindowViewManager contains and accomplishes a larger share of the functionality once exercised in the Program class. The ProgramViewFirstView is analogous to a visual screen, in this case, a magenta square. Or, at least, that is what this view produces.
- Exploring SFML Graphics in C++
- Subsequent changes: Wave 1, Wave 2, Wave 3, and Wave 5 (conclusion for series 2)
- Series 3: Build a Cross-Platform C++ Program with SFML