Building a Modular UI System

In the previous section, we introduced the application loop and event loop, which sets the foundation of our program. As our program and interactions get more complex, we need to build additional systems on top of this foundation to help manage the complexity.

In this lesson, we'll dive deeper into managing complex user interfaces by implementing a modular UI system. We'll cover key topics such as:

1. Creating a UI manager to handle events and rendering
2. Implementing nested components for better organization
3. Utilizing inheritance to create reusable UI elements
4. Using polymorphism for flexible component management

By the end of this lesson, you'll have a solid foundation for building scalable and maintainable UI systems.

Creating a UI Manager

We’ll start by creating a UI manager, which has two methods that will be called from our application loop.

• Events will be passed to the HandleEvent() method, giving our UI visibility of the events flowing through our application, and the opportunity to react to them
• The application loop will call Render() at the appropriate time, passing the SDL_Surface the UI should render to

1// UI.h
2#pragma once
3
4class UI {
5public:
6  void HandleEvent(const SDL_Event& E){
7    // ...
8  };
9  
10  void Render(SDL_Surface* Surface){
11    // ...
12  }
13};

Adding this clas to our program and connecting it to our application loop might look something like this:

1#include <SDL.h>
2#include "UI.h"
3
Window Class|Show
4class Window {/*...*/};
39
40int main(int argc, char** argv){
41  SDL_Init(SDL_INIT_VIDEO);
42  Window GameWindow;
43  UI GameUI; 
44
45  SDL_Event Event;
46  bool shouldQuit{false};
47
48  while (!shouldQuit) {
49    while (SDL_PollEvent(&Event)) {
50      GameUI.HandleEvent(Event);
51      if (Event.type == SDL_QUIT) {
52        shouldQuit = true;
53      }
54    }
55    GameWindow.Render();
56    GameUI.Render(GameWindow.GetSurface());
57    GameWindow.Update();
58  }
59
60  SDL_Quit();
61  return 0;
62}

Nested Components

Our UI manager is now removing UI-related responsibility from the main loop, helping to reduce its complexity. However, in large applications, our UI can get very complex, so we need ways to defer responsibility away from the UI manager.

A common way to design this is to imagine our UI existing in a hierarchy. For example, our main UI class might have three children, each responsible for a specific part of the UI such as a main menu, a sidebar, and a footer.

We’d create classes for each of these and, just like the UI manager itself, we can give them Render() and HandleEvent() methods:

1// MainMenu.h
2#pragma once
3
4class MainMenu {
5public:
6  void HandleEvent(const SDL_Event& E){];
7  void Render(SDL_Surface* Surface){};
8};

1// Sidebar.h
2#pragma once
3
4class Sidebar {
5public:
6  void HandleEvent(const SDL_Event& E){};
7  void Render(SDL_Surface* Surface){};
8};

1// Footer.h
2#pragma once
3
4class Footer {
5public:
6  void HandleEvent(const SDL_Event& E){};
7  void Render(SDL_Surface* Surface){};
8};

Our UI manager can now create these three children, and forward events and render requests to them:

1// UI.h
2#pragma once
3
4#include "MainMenu.h"
5#include "Sidebar.h"
6#include "Footer.h"
7
8class UI {
9public:
10  void HandleEvent(const SDL_Event& E){
11    MenuComponent.HandleEvent(E);
12    SidebarComponent.HandleEvent(E);
13    FooterComponent.HandleEvent(E);
14  };
15  
16  void Render(SDL_Surface* Surface){
17    MenuComponent.Render(Surface);
18    SidebarComponent.Render(Surface);
19    FooterComponent.Render(Surface);
20  }
21  
22private:
23  MainMenu MenuComponent;
24  Sidebar SidebarComponent;
25  Footer FooterComponent;
26};

This process can continue for deeper levels of nesting. For example, our MainMenu component might be comprised of a series of Button components. Each Button would take some responsibility away from theTMainMenu class, preventing it from becoming excessively large.

Within this framework, components can also have a dynamic number of children. For example, one of the children of our MainMenu could be a std::vector, containing a variable number of UI elements:

1// MainMenu.h
2#pragma once
3
4#include <vector>
5#include "Button.h"
6
7class MainMenu{
8public:
9  MainMenu(){
10    // Construct Children
11    // ...
12  };
13  
14  void HandleEvent(const SDL_Event& E){
15    for (Button& Child : Children) {
16      Child.HandleEvent(E);
17    }
18  };
19  
20  void Render(SDL_Surface* Surface){
21    for (Button& Child : Children) {
22      Child.Render(Surface);
23    }
24  }
25  
26private:
27  std::vector<Button> Children;
28};

Inheritance

Remember, we can also use inheritance when building out our collection of UI components. For example, a typical component we’ll need is one that draws a simple rectangle onto the surface:

1// Rectangle.h
2#pragma once
3#include <SDL.h>
4
5class Rectangle {
6public:
7  Rectangle(int x, int y, int w, int h)
8    : Rect{x, y, w, h}{}
9
10  void Render(SDL_Surface* Surface){
11    SDL_FillRect(
12      Surface, &Rect, SDL_MapRGB(
13        Surface->format, 255, 0, 0
14      )
15    );
16  }
17
18private:
19  SDL_Rect Rect{0, 0, 0, 0};
20};

Aside from rendering this component directly, we can also use it as the base of more complex components. For example, we might have a component that expands on this to create rectangular buttons, or a class that expands on it to create text boxes.

We’ll implement both of these later in the course, but the basic idea is outlined below.

Our Text class inherits from Rectangle, and replaces the Render() method. The Text::Render() function will call inherited the Rectangle::Render() method to draw the rectangle, and will then implement additional logic to draw the text on top of it:

1// Text.h
2#pragma once
3#include <SDL.h>
4#include "Rectangle.h"
5
6class Text : public Rectangle {
7public:
8  Text(int x, int y, int w, int h)
9    : Rect{x, y, w, h}{}
10
11  void Render(SDL_Surface* Surface){
12    Rectangle::Render(Surface);
13    // Render Text...
14  }
15};

Polymorphic Children

Finally, we can use polymorphic patterns within this design. For example, imagine we have a Grid component that is responsible for positioning its children in a specific way. For this class to be flexible, it shouldn’t need to know in advance what type its children should be, not should it require all the children have the same type.

This is where polymorphism can help us. Our grid could simply require its children have appropriate Render() and HandleEvent() methods. So, we create some type that meets these requirements, remembering to add the virtual keywords to make it polymorphic:

1// Component.h
2#pragma once
3#include <SDL.h>
4
5class Component {
6public:
7  virtual void HandleEvent(const SDL_Event& E){}
8  virtual void Render(SDL_Surface* Surface){}
9};

Our Grid class will store pointers to objects that have this type. Ideally, we’d want to give our Grid the capability construct children of an unknown type and assume unique ownership of them, but this approach requires some advanced topics we haven’t covered yet.

So for now, we’ll just construct the objects elsewhere and pass them to our Grid as a std::shared_ptr through the AddChild() method. This lets our grid at least share ownership of its children, and keep them alive in memory:

1// Grid.h
2#pragma once
3#include <SDL.h>
4#include <memory>
5#include "Component.h"
6
7class Grid {
8public:
9  void AddChild(
10    std::shared_ptr<Component> Child){
11    Children.push_back(Child);
12  }
13
14  void Render(SDL_Surface* Surface){
15    for (auto& Child : Children) {
16      Child->Render(Surface);
17    }
18  }
19
20  void HandleEvent(const SDL_Event& E){
21    for (auto& Child : Children) {
22      Child->HandleEvent(E);
23    }
24  }
25
26  std::vector<std::shared_ptr<Component>> Children;
27};

We covered memory ownership and std::shared_ptr in more detail here:

Memory Ownership and Smart Pointers

Learn how to manage dynamic memory using unique pointers and the concept of memory ownership

Next, let’s create some types that inherit from Component and override the Render() method:

1// Shapes.h
2#pragma once
3#include <SDL.h>
4#include <iostream>
5#include "Component.h"
6
7class Rectangle : public Component {
8  void Render(SDL_Surface* Surface) override{
9    std::cout << "Rendering Rectangle\n";
10  }
11};
12
13class Circle : public Component {
14  void Render(SDL_Surface* Surface) override{
15    std::cout << "Rendering Circle\n";
16  }
17};

Finally, let’s create some shapes and push them to our grid. For the sake of this example, we’ll do it from our UI manager:

1// Shapes.h
2#pragma once
3#include <SDL.h>
4#include "Shapes.h"
5#include "Grid.h"
6
7class UI {
8public:
9  UI(){
10    GridComponent.AddChild(
11      std::make_shared<Rectangle>());
12    GridComponent.AddChild(
13      std::make_shared<Circle>());
14  }
15
16  void Render(SDL_Surface* Surface){
17    GridComponent.Render(Surface);
18  }
19
20  void HandleEvent(const SDL_Event& E){
21    GridComponent.HandleEvent(E);
22  }
23
24private:
25  Grid GridComponent;
26};

Now, our Grid renders a rectangle and a circle on every frame, without needing to know the Rectangle or Circle types even exist:

1Rendering Rectangle
2Rendering Circle
3Rendering Rectangle
4Rendering Circle
5// ...

Summary

In this lesson, we've explored the fundamentals of building a modular UI system in C++ using SDL. We started by creating a UI manager to handle events and rendering, then introduced nested components to manage complexity.

We also discussed how to use inheritance for creating reusable UI elements and leveraged polymorphism for flexible component management.

In the next lesson, we'll build upon this foundation by adding interactive buttons to our UI. We'll implement hover and click functionality, allowing users to interact with our interface. This will involve handling mouse events, updating button states, and providing visual feedback to the user. Get ready to bring your UI to life with dynamic, responsive elements!

Free and Unlimited Access

Professional C++

Unlock the true power of C++ by mastering complex features, optimizing performance, and learning expert workflows used in professional development

View Course