Description
The Gtk bindings generator (see the GtkCodeGen target) is currently quite janky because I'm usually only touching its code when I'm adding a new view/feature to SwiftCrossUI that the bindings generator can't generate the required class bindings for. Most recent changes to GtkCodeGen have been bandaid fixes.
We'll eventually need the Gtk 3 and 4 bindings to become part of the public interface of the SwiftCrossUI package because we'll want to officially support creating custom platform-specific views. Before we make them explicitly public API we'll want the bindings to be pretty complete (and consistent).
This issue is very vague, so it's more of a tracking issue than anything. Here are some related subtasks that come to mind;
- Update generator to avoid unnecessary type name conversion edge cases (currently quite a few hardcoded conversions)
- Support interfaces properly
- Update the GObject class to support wrapping both owned and unowned references. Currently it assumes ownership and calls destroy/unref on deinit of the Swift class. This will make it possible to provide bindings for properties with non-primitive types.
- Support generating bindings for methods
- Provide a way to define custom widgets from Swift if possible (currently requires a bunch of C code)
- Provide a way to override virtual methods (currently also requires C)
- Get things to a point where we can generate bindings for all Gtk types (excluding a few if there are some impossible/problematic edge cases)
- Reduce the number of manually written widget bindings
- Only attach to signals for which the class has a non-nil closure. The current approach probably isn't very performant.
I'll update this list of tasks with new ones as I think of them.