1. Overview
The AlertWindowRealtime.hpp header defines the AlertWindowRealtime class, a GTKmm (GTK4) top-level dialog window used to present real-time malware detection alerts to the user. This window is displayed when an active threat is detected during on-access or background scanning and provides immediate response options.
Functionally, AlertWindowRealtime provides:
- Immediate visual notification of detected threats
- Display of file path and malware family information
- Presentation of pending alert counts for batch detections
- User actions for quarantine, ignore, and ignore-all
- Signal-based integration with backend workflows
- Modal-style interaction to enforce user awareness
2. Dependencies and Includes
#include <gtkmm.h>
#include <string>
- gtkmm.h – GTK4 window widgets, layout containers, and signal support
- <string> – file paths and malware family identifiers
3. Class Declaration and Scope
class AlertWindowRealtime : public Gtk::Window
The class derives from Gtk::Window, making it a standalone alert dialog capable of receiving focus and interacting directly with the user.
4. Public Interface
4.1 Constructor
AlertWindowRealtime(const std::string& file,
const std::string& family,
size_t pending = 0);
Constructs a real-time alert window initialized with threat metadata and optional information about additional pending detections.
- file – full path of the detected file
- family – malware family or signature name
- pending – number of queued detections awaiting user action
4.2 Ignore-All Signal
sigc::signal<void()> signal_ignore_all;
Signal emitted when the user selects the “Ignore All” option. This allows upstream components to suppress further alerts in the current detection batch.
5. UI Components
The alert window is composed of a vertical layout containing informational labels and action buttons.
Gtk::Box vbox;
Gtk::Label titleLabel;
Gtk::Label messageLabel;
Gtk::Label pendingLabel;
Gtk::Button quarantineButton;
Gtk::Button ignoreButton;
Gtk::Button ignoreAllButton;
- vbox – main vertical layout container
- titleLabel – displays alert headline (e.g., “Threat Detected”)
- messageLabel – shows file and malware family information
- pendingLabel – indicates the number of pending detections
- quarantineButton – moves the file to quarantine
- ignoreButton – dismisses the current alert
- ignoreAllButton – suppresses remaining alerts in batch mode
6. Internal State and Data Model
std::string filePath;
- filePath – cached path of the detected file, used for quarantine operations
Other runtime state (pending counters, UI text formatting, and signal connections) is managed in the implementation file.
7. User Actions (Callbacks)
User interactions are handled through button signal connections that invoke internal logic and propagate events.
- Quarantine – invokes
move_to_quarantine() - Ignore – closes the window without further action
- Ignore All – emits
signal_ignore_all
8. Internal Logic
8.1 Quarantine Action
void move_to_quarantine();
Transfers the detected file into the configured quarantine directory and updates the application state accordingly. The method typically delegates to the centralized quarantine subsystem.
8.2 Alert Lifecycle
A typical alert lifecycle includes:
- Receiving detection metadata from the realtime scanner
- Instantiating
AlertWindowRealtime - Populating labels and formatting messages
- Displaying the window with focus
- Dispatching user actions to backend services
- Destroying or reusing the window after resolution
9. Auto-Update (Scheduled Refresh)
This component does not implement periodic behavior. It is event-driven and instantiated only in response to detections.
10. Settings Storage
User decisions made in this dialog (ignore, ignore-all) may be propagated to runtime state or temporary suppression lists. No direct persistence is handled by this class.
11. Helper Functions and Filesystem Layout
Quarantine operations rely on centralized quarantine directories managed by the application, typically under:
~/.local/share/BastionGuard/quarantine/
Exact paths are implementation-defined and configurable.
12. Runtime and Security Considerations
- Prompt visibility: alert windows should request focus and remain visible until acknowledged to prevent silent threat dismissal.
- Safe defaults: quarantine should be the recommended default action for high-confidence detections.
- Race conditions: ensure the file is still present and unchanged before moving it to quarantine.
- Batch suppression: “Ignore All” must be scoped carefully to avoid disabling protection beyond the current detection session.
- Auditability: user decisions should be logged for forensic and support purposes.