UXGtkDriver

UXGtkDriver is the GTK4 realization of UXViewDriver: the Linux desktop backend.

#use <UXKit>            // or #import "UXGtkDriver.xc"

Built to a pattern, not from scratch

It is a sibling of UXAppKitDriver and uses the same arrangement as the iOS driver:

the shared shadow tree, which the driver walks to paint and hit-test
custom views painting through drawRect → UXCairoGraphics → the cairo_t of the current draw
realizeTree overlaying real GTK widgets whose signals land in the toolkit’s fire / value / field seams

neutral	GTK4
`UXButton`	`GtkButton`
`UXCheckbox`	`GtkCheckButton`
`UXTextField`	`GtkEntry`
`UXSlider`	`GtkScale`
`UXStepper`	`GtkSpinButton`
`UXProgressBar`	`GtkProgressBar`
`UXPopUpButton`	`GtkDropDown`

This fifth backend follows the existing pattern without adding to it. The interface already reflects three very different systems: GEM’s AES objects, Win32’s HWNDs and AppKit’s NSViews.

The neutral loop owns the run loop

driverOwnsRunLoop()    // false

GTK’s main context pumps under the neutral blocking loop; GTK does not call the toolkit back.

This is the desktop arrangement, and the opposite of UXIOSDriver and UXAndroidDriver, where the platform owns the loop and the application is a set of callbacks. driverOwnsRunLoop is the one flag that tells the neutral layer which arrangement applies.

Pointer input had to be added

By default GTK4 does not deliver raw button and motion events to a drawing area; it expects gesture controllers. The driver therefore attaches a GtkEventControllerLegacy and exposes ux_gtk_drag_next.

The shim keeps structs out of xc

As on every other hosted backend, the exported signatures use primitives only:

i32  ux_gtk_boot(i32* w, i32* h);
void ux_gtk_pump(void);
void ux_gtk_wait_event(void);
i32  ux_gtk_alert(i32 parent, u8* lines, u8* buttons, i32 defBtn);

No GdkRectangle or cairo_t* crosses into portable code. For the same reason, the clip stack is ux_gtk_clip / ux_gtk_clip_end instead of a context object.

Linking an app for Linux

The shim is C, so for an app linked by xcc itself it is a shared library, libUXGtk.so. frameworks/uxkit/tools/build_libuxgtk.sh builds it with the machine’s C compiler against its GTK 4, on a Linux machine or, from a Mac, on the UX_LINUX_HOST named in build.env. Then:

xcc -A x86_64 -dynamic app.xc -L <dir> -lUXGtk -lgtk-4 -lGL

-dynamic writes a glibc executable that loads GTK 4 and the other libraries at run time (from 0.72 that is the default, and -dynamic may be left out), and -l finds each lib<name>.so on the -L path or in the system’s library directories. To link on a Mac, --with-link-inputs also copies the Linux machine’s libgtk-4.so and libGL.so into the output directory. The app needs libUXGtk.so beside it, or on its library path, when it runs.

Testing

The gates are run_gtk_real.sh, run_gtk_loop.sh, run_gtk_mouse.sh, run_gtk_alert.sh and run_gtk_settings.sh. They run on Linux and cannot run on macOS, so verify a change here on Linux.

The GTK gates print a heartbeat, because a headless GTK run that has stopped looks the same as one that is waiting.