GTK Implementation

Relevant Source Files

Application Lifecycle

The GTK app layer allocates a GtkApplication with ID com.nappgui.app, stores the startup callbacks, and then runs them from the activate signal path. During initialization it explicitly sets GDK_BACKEND=x11, records the command-line arguments, and prepares timer IDs plus listener slots.

Once activated, the backend calls osgui_initialize(), holds the application, and installs two recurring timers: one for the main update loop and one that waits until the GUI backend is fully initialized before calling the app's finish-launching callback. Termination is cooperative: the timer loop notices the terminate flag and runs the cleanup sequence.

Window System

GTK windows are wrapped by OSWindow, which stores the main panel, modal runloop, flags, role, accelerator group, listeners, tabstop state, hotkeys, resize constraints, and the last known configure-event geometry.

Move and resize behavior comes from configure-event, not from a separate Win32-style sizing message pair. The backend compares the incoming event with the stored geometry, emits move/resize notifications only for user-driven changes, and updates minimum size hints when the resize listener demands a larger size than GTK proposed.

Keyboard, Focus, and Modal Behavior

Key handling lives at the window level. The GTK backend intercepts Tab, Shift-Tab, Enter, keypad Enter, and Escape to implement tab traversal, default-button triggering, return-close semantics, and escape-close semantics. It also checks the window hotkey table on every key press.

Modal windows are implemented by creating a private GMainLoop, marking the window modal, showing it, and running that loop until oswindow_stop_modal(...) records a return value, optionally hides the window, and quits the loop.

Menubars and GTK-Specific Window Behavior

The backend treats menubars as part of layout sizing. It measures the current menubar height, keeps the required menu width slightly narrower on resizable windows to preserve shrink behavior, and recalculates window size requests when the menubar changes.

There is also a platform-specific quirk in the app layer: some GTK/Linux setups attach the menubar to a global application menubar instead of the window itself, so the app code has explicit logic to clear the application menubar when needed.

Drawing and Text

draw_gtk.c uses Cairo for geometry and raster drawing and Pango for text layout. The code is careful about transform handling: it avoids inheriting arbitrary Cairo rotation/scale state into the Pango layout context and notes that text scaling is managed by Cairo instead.

The GTK text path also maps NAppGUI features like underline, strikeout, ellipsis, and alignment to Pango markup and alignment modes. In practice, GTK is the backend where the draw2d abstraction is most visibly layered over external graphics/text libraries.

WebKitGTK Support

When web support is available, osweb.c creates a real WebKitWebView and maps the public commands to webkit_web_view_load_uri, go_back, and go_forward. Without support, it falls back to a plain GTK drawing area so the public API can still compile.

That compile-time gating is controlled by the CMake web-support check, which looks for compatible WebKitGTK packages.