Structuring ImGui Windows

Why Organization Matters

Before we dive into the code, take a look at what a complex, real-world application built with ImGui looks like.

To build an application like our telemetry engine, which will have separate windows for plots, logs, and profiler controls, we need to think beyond a single main loop. Each piece of the UI should be its own self-contained, reusable component.

The Simplest Approach: Encapsulating UI in Functions

The most straightforward way to clean up our main loop is to move the code for each window into its own function. This is an excellent pattern for simple, mostly stateless windows.

For example, the "Controls" window we built last time could be refactored like this:

// In a new file, e.g., "UI.h" / "UI.cpp"
namespace UI 
{
    void RenderControlsWindow(ImVec4& clear_color)
    {
        ImGui::Begin("Controls");

        ImGui::Text("Change the background color.");
        ImGui::ColorEdit3("Background Color", (float*)&clear_color);
        
        // ... other widgets ...
        if (ImGui::Button("Reset Color"))
        {
            clear_color = ImVec4(0.45f, 0.55f, 0.60f, 1.00f);
        }

        ImGui::End();
    }
}

// In main.cpp
int main()
{
    // ... setup ...
    static ImVec4 clear_color = ImVec4(0.45f, 0.55f, 0.60f, 1.00f);

    while (!glfwWindowShouldClose(window))
    {
        // ... new frame setup ...
        
        UI::RenderControlsWindow(clear_color); // Just one function call!
        // You could call other functions for other windows here.

        // ... rendering ...
    }
    // ... cleanup ...
}

This simple change already makes our main loop much cleaner and separates the UI logic from the application's core loop.

A More Robust Structure: Classes for Stateful Windows

Functions are great, but what happens when a window becomes more complex? Our LOD Plotter, for instance, will need to manage its own data, zoom level, pan offset, and other state. Passing all of this state back and forth through function parameters would become clumsy.

A much better solution is to use a class to represent a window. Each window class can encapsulate its own state (member variables) and behavior (member functions). A common and effective pattern is to create a base Window class and have all your specific UI windows inherit from it.

Let's distill the core idea from the article:

1. Base Window Interface: Define an abstract base class that represents any window in our application. It has one job: to be drawn.

   class IWindow
   {
   public:
       virtual ~IWindow() = default;
       virtual void Draw() = 0; // Pure virtual function
   };
   

2. Concrete Window Implementation: Create specific window classes that inherit from the base class and implement the Draw method. They also hold their own state.

   class LogWindow : public IWindow
   {
   public:
       void Draw() override
       {
           ImGui::Begin("Log");
           // ... draw log entries from log_messages ...
           ImGui::End();
       }
   private:
       // State specific to the log window
       std::vector<std::string> log_messages; 
   };
   

3. Window Manager: In your main application logic, you can now manage a collection of these windows polymorphically.

   // In your main application class or loop
   std::vector<std::unique_ptr<IWindow>> windows;
   windows.push_back(std::make_unique<LogWindow>());
   windows.push_back(std::make_unique<PlotterWindow>());
   
   // In the render loop
   for (const auto& window : windows)
   {
       window->Draw();
   }
   

This structure is clean, object-oriented, and highly scalable.

Encapsulating the Entire Application

We can take this one step further. Not only can we encapsulate our UI windows, but we can also hide all the boilerplate for setting up GLFW, OpenGL, and ImGui itself inside a main Application class. This follows the RAII (Resource Acquisition Is Initialization) principle you've seen before: the constructor sets everything up, and the destructor cleans everything up.

The goal is to make our main.cpp beautifully simple:

int main()
{
    MyApp app;
    app.run();
    return 0;
}

After this refactoring, we have a base App class with a virtual void update() method. Our MyApp inherits from App and overrides update() to draw its specific UI. This is a solid, flexible design. But for a high-performance application, we can do even better.

Zero-Cost Abstraction with CRTP

The use of a virtual function introduces a small runtime overhead: a vtable lookup. Every time app->update() is called, the program has to look up the correct function pointer in a virtual table. For our profiler, where we want to eliminate every nanosecond of unnecessary overhead, we can remove this cost using a powerful C++ pattern: the Curiously Recurring Template Pattern (CRTP).

CRTP allows us to achieve compile-time polymorphism. Instead of a vtable lookup at runtime, the compiler knows exactly which function to call and can even inline it, reducing the abstraction's cost to zero.

Here is what the CRTP pattern looks like in code:

Base Class (The Framework):

template <typename Derived>
class Application
{
public:
    void run()
    {
        // ... init ...
        while (/*... not closing ...*/)
        {
            // ... new frame ...

            // No vtable lookup! The compiler knows 'Derived' is 'MyApp'
            // and can inline this call. This is zero-cost abstraction.
            static_cast<Derived*>(this)->update();

            // ... render ...
        }
        // ... cleanup ...
    }
};

Derived Class (Our Application):

#include "Application.h"

class MyApp : public Application<MyApp> // <-- The "curiously recurring" part
{
public:
    void update()
    {
        // Our ImGui code goes here
        ImGui::ShowDemoWindow();
    }
};

By using CRTP, we get the best of both worlds: the clean, high-level organization of an application framework and the bare-metal performance of calling a function directly.

Conclusion

Today we've transformed our single-file application into a professional, scalable C++ project structure. This is a massive step forward and sets a solid foundation for the complex features we will build.

Key Takeaways:

• Placing all UI code in main is not scalable.
• Functions are a simple first step to organize stateless UI elements.
• Classes are a superior way to encapsulate stateful UI windows, like our future plotter. Using a base class with a virtual Draw() method is a common and effective OOP pattern.
• The entire application boilerplate (window creation, main loop) can be encapsulated in a reusable Application class using RAII.
• For maximum performance, we can replace runtime polymorphism (virtual functions) with compile-time polymorphism using the Curiously Recurring Template Pattern (CRTP), achieving zero-cost abstraction.

What's Next?

With our application now cleanly structured, we are ready to start building the visualization tools themselves. In the next lesson, we will dive into the ImGui Draw List API. You'll learn how to break free from standard widgets and render custom primitives like lines and rectangles. This is the first step toward building our custom LOD Plotter, as we'll need to draw the plot axes, lines, and bars ourselves.