DonatePage.hpp

1. Overview

The DonatePage.hpp header defines the DonatePage class, a GTKmm (GTK4) UI component that provides a dedicated donation/support page for BastionGuard. The page is designed as a simple vertical layout that presents donation-related content and triggers an action to open the donation destination (implementation-defined) when the user interacts with the UI.

Functionally, DonatePage provides:

  • A standalone GTK container suitable for embedding in a multi-page application
  • A vertical main layout (Gtk::Box) used to arrange donation UI elements
  • A private callback to open the donation page/workflow

2. Dependencies and Includes

#include <gtkmm.h>
  • gtkmm.h – GTK4 C++ widgets, containers, and signal primitives

3. Class Declaration and Scope

class DonatePage : public Gtk::Box

The class derives from Gtk::Box, making it directly usable as a page within a notebook, stack, or any other container-driven navigation structure.

4. Public Interface

4.1 Constructor

DonatePage();

Builds the donation page UI and initializes the main container layout. In typical usage, the constructor is responsible for adding child widgets to box_main (e.g., explanatory labels and a donate button) and wiring UI signals to on_open_donate().

5. UI Components

DonatePage is intentionally minimal and is centered around a single main layout container.

5.1 Main Layout

Gtk::Box box_main{Gtk::Orientation::VERTICAL, 8};
  • box_main – vertical box used as the primary layout container
  • Orientation – vertical stacking for donation content
  • Spacing – 8 pixels between child widgets (consistent visual separation)

6. Internal State and Data Model

The header does not define a complex data model. The page state is primarily represented by its widget composition (the main layout container) and a private action callback.

7. User Actions (Callbacks)

void on_open_donate();
  • on_open_donate() – triggers the donation workflow, typically opening an external URL (e.g., a website) or launching an in-app browser/action (implementation-defined)

8. Internal Logic

No additional internal logic helpers are declared in this header. The implementation is expected to:

  • Compose the donation UI within box_main
  • Bind a user interaction (such as a button click) to on_open_donate()
  • Open the donation destination using the project’s preferred mechanism

9. Auto-Update (Scheduled Refresh)

This component does not implement scheduled tasks or timers.

10. Settings Storage

This header does not declare a settings persistence interface. Any remembered state (for example, whether the user has already viewed the donation page) would be implemented outside this class or in the corresponding .cpp.

11. Helper Functions and Filesystem Layout

No filesystem or path helpers are declared in this header. Any URL storage, localization resources, or icon loading would be handled in the implementation file or by the surrounding application framework.

12. Runtime and Security Considerations

  • Safe URL handling: if on_open_donate() opens an external link, ensure the destination is hard-coded or validated to avoid unintended redirection.
  • User transparency: clearly indicate when the application is about to open an external browser or external site, and provide clear feedback if the operation fails.
  • Non-blocking behavior: opening external resources should not block the GTK main loop; prefer asynchronous launch mechanisms where applicable.
  • Minimal privilege: the donation action should not require elevated privileges and should avoid accessing sensitive local resources.
Published on:
Last updated on: