Option 6: Rather than wrap the entirety of an existing UI toolkit, or create a new one entirely from scratch, instead make a new ApplicationKit-like MVC framework that uses un-wrapped GTK+ calls to draw itself and handle input. GTK+4 is now stable, and has been considerably simplified; it could be used for this purpose without bindings as it is already a C library. We would begin by implementing two classes; here I will use the OF- prefix, as we are talking about an "official” UI framework for ObjFW. These classes are OFWindow and OFView. OFWindow is by far the simpler of the two; it is essentially an Obj-C object which wraps the basic functionality of GtkApplicationWindow. It uses a GTK+ widget hierarchy to show an optional headerbar and a single main OFView, sized to fill the window's available area. OFView, on the other hand, is both far more complex and the absolute core of the entire UI. It is the class which defines what a "view" in MVC is. It has the following capabilities: - Draw arbitrary text and graphics to the area provided for it by its superview. - Draw an arbitrary GTK+ widget hierarchy in its area, arranged using whatever GTK+ layout is appropriate. - Position subviews within its alloted area, relative to its own borders, using GTK+'s now-stable constraints-based layout system. Subviews overlap the drawable surface. - Recieve event messages generated by mouse and keyboard events, as translated by GTK+ callback functions attached to the relevant signals. - Recieve target-action messages from other objects. Further, OFApplication would recive enhancements to interface with the GtkApplication class, allowing it to manage menus and the like, as well as recieve and respond to UI event messages. Event messages, as generated by widgets, would first go to the widget’s parent OFView; the default behaviour for all event messages is simply to forward the event message to the superview, or, if there is none, to the parent OFWindow, or if there is none, to the OFApplication instance. It should be fairly easy to see how these two classes provide the basis for a complete set of views. Futher on, we can develop data source protocols for complex views, such as tables and columns and icon views, allowing essentially arbitrary model classes to be used with them. Benefits: - ObjFW applications will run wherever GTK+ runs. - Familiar in general to AppKit devs, without being a clone. - Able to address any flaws in AppKit's design. - It will fit with the Objective-C way of doing things. - It will be able to use the native menuing systems on all supported platforms. - Development will be very much faster than wrapping every GTK+ class individually, not to mention faster than doing it all from scratch. - We can use the GTK+ port of WebKit to make OFWebView. Drawbacks: - Everyone who helps code it needs to at least understand the basics of how GTK+ works. It's not terribly difficult, but it is a drawback. - We have to design and build all our OFView subclasses. AppKit does provide a rough template to work from, though. - It won't look native anywhere but Linux and the BSDs. - Wrappers have an inherent risk of memory leaks if not written correctly.