Create a class for the base station GUI session that initializes and manages GLFW and NanoGUI. Modify the current main file to declare and construct the session object. This class will provide a starting place to integrate features together.
Design Considerations
Using one class for the GUI session avoids the need to declare lots of local variables in the main() method. We learned with the legacy base station that it is difficult to organize new features when many variables needed are initialized in the main method. A session object can be shared for easy access to program resources rather than having to pass local variables or declare global variables in multiple files.
Requirements
The session class will initialize and manage GLFW
Declare, define, and register the GLFW event handlers needed for NanoGUI. Reference both the GLFW Input Guide and NanoGUI Example 3.
The callbacks should be static member variables since GLFW will not know of a base station session instance.
The static callbacks still need access to the object instance. There will never be multiple instances of the base station session. Two clean solutions for global access:
Make a static member variable of the session that is a pointer to the main session. Additionally, define a static getter function that dereferences the pointer and returns a C++ reference (MySessionClass&). The constructor will set the instance variable to this
Use the GLFW custom window pointer, which is a void pointer we can get/set through GLFW. Setup will need to set the pointer for every GLFWwindow. In practice, the static member variable solution is probably cleaner
Create a GLFW window and initialize a NanoGUI screen for that window. Reference: GLFW Window Guide
NanoGUI needs testing on multiple screens, so we'll leave multi-screen support for another task
Define a function to call in the main loop that will poll keypresses and call the necessary NanoGUI functions
We may not need to do anything in the main loop other than call this function. The main loop function could run the loop inside itself and never return until the window should close.
Any config options needed (fullscreen/windowed mode, fullscreen mode monitor, specific resolution or automatic, etc.) should be passed to the constructor. They will later come from Boost's property tree (ptree), and the ptree will be passed to the constructor, but for now, the default values can be fixed in the main file.
Default window configuration should be fullscreen mode with the primary monitor.
Timeline: Opportunity to discuss any issues or design problems in the meeting on November 9th. Pull request submitted for review on or before Monday, November 15th. This will allow new tasks assigned on the 16th to count on this framework.
Design Uncertainties
Where will other components be declared and initialized, such as the network library and control library? Since the GUI will be driving everything, it seems the network library and control library will be members of the session class. Is this design scaleable and maintainable?
Main Objective
Create a class for the base station GUI session that initializes and manages GLFW and NanoGUI. Modify the current main file to declare and construct the session object. This class will provide a starting place to integrate features together.
Design Considerations
Using one class for the GUI session avoids the need to declare lots of local variables in the main() method. We learned with the legacy base station that it is difficult to organize new features when many variables needed are initialized in the main method. A session object can be shared for easy access to program resources rather than having to pass local variables or declare global variables in multiple files.
Requirements
MySessionClass&
). The constructor will set the instance variable tothis
Design Uncertainties
Where will other components be declared and initialized, such as the network library and control library? Since the GUI will be driving everything, it seems the network library and control library will be members of the session class. Is this design scaleable and maintainable?