ObjFW  Timeline

Hello Kyle,

thank you for your proposal containing option 6 which I have thought about a while.

First I think that your approach of saving work and getting things done the fast way should really be considered taking into account our very limited manpower. But I'd also like to add that I never considered writing a Gtk wrapper by hand but rather to create a generator or use one of the existing ones to accomplish that goal. Nonetheless - that's still much work of course.

I'd also like to add that we should not model anything after AppKit, but rather look at UIKit from my point of view. Just because UIKit is the framework which is way newer and also way simpler than AppKit - at least afaik. I have to admit I've never developed an app using it.

Considering the MVC design pattern I agree with you that Gtk already provides the View part using C language elements (or utilizing GtkBuilder and ui files). So we do not need that part to create apps using ObjFW, which is a great feature of ObjC of course.

I think, what we actually need are the glue parts between the view layer (Gtk or maybe UIKit as a drop-in replacement) and the controller layer. As far as I understood that's the point where UIKit utilizes ViewControllers (VC). I think we also need

1. a way to set ObjC methods as callback functions for a Gtk view and
2. a way to do data binding / key-value coding.

As I do have too limited experience for both Gtk and UIKit I think I'm going to create a little app using Gtk and UIKit for the views at some point and try to figure out which parts are missing exactly. Once I managed to create the needed parts for a concrete example I think I'd be able to think about a more general solution.

Currently I'm quite confident that it won't be too complicated using ObjC. So even having a first small example app would be a "very nice to have" from my point of view.

As I really like the development going on for Gtk4 and libadwaita (former libhandy) I'd favour trying those.

So, now my 2 cents. I thought a while about it and I agree with your statements above. I'd like to add some differentiation and consider desktop and mobile target platforms.

Going for desktop only

Taking a conservative desktop approach would mean to use Qt I think. It's just the most used cross platform toolkit that works very well and still looks acceptable everywhere. (This does not differentiate the Linux desktop any further, taking into account the GNU/Linux desktop got only 2,35% or something of the desktop market share.)

But if it comes to mobile (targeting iOS, Android, Windows Mobile, Plasma Mobile or Ubuntu Touch/UBports) you will need to use QtQuick/QML and/or Kirigami as well. That would mean to not only handle C++, but go the JavaScript/QML path as well. If we consider our users (I mean developers wanting to have a cross platform GUI toolkit) then I assume there are very few ObjC developers (f.e. coming from iOS development) who want to ditch their xib files and storyboards and start mangling QML.

Going mobile first

If we take into account there already is a (incomplete) AppKit port by the GNUstep project I won't target the desktop as a first class citizen again, even though most of us probably like their desktops. But mobile marketshare is 59% vs 37% of the desktop with mobile still gaining space (https://www.netmarketshare.com/device-market-share).

That means most of the ObjC devs of the last years probably were iOS/UIKit developers and not developing for the desktop (AppKit), considering macOS was having 9.77% of the desktop market share in 2019 and iOS 28.23% of the mobile one (https://macdailynews.com/2019/06/03/apples-macos-and-ios-market-share-both-up-in-may-2/).

Targeting mobile first could lead to the usage of Gtk because with the efforts of the ongoing Phosh project apps are going to work mobile using the same C code basis afaik. Using Gtk themes these may even integrate into Android.

Conclusion

To be really appealing to UIKit devs that would mean to create a Gtk wrapper which is very close to UIKit. ObjC devs thus could provide a Gtk based frontend for Android/</a>Gnome/Phosh/Windows (Mobile) with maybe little changes, but leave it unchanged for the Apple platforms. (UIKit apps sooner or later are going to work at every Mac, despite the ongoing development of SwiftUI of course, with Swift currently not providing ObjC bindings for Linux.)

So, now my 2 cents. I thought a while about it and I agree with your statements above. I'd like to add some differentiation and consider desktop and mobile target platforms.

Going for desktop only

Taking a conservative desktop approach would mean to use Qt I think. It's just the most used cross platform toolkit that works very well and still looks acceptable everywhere. (This does not differentiate the Linux desktop any further, taking into account the GNU/Linux desktop got only 2,35% or something of the desktop market share.)

But if it comes to mobile (targeting iOS, Android, Windows Mobile, Plasma Mobile or Ubuntu Touch/UBports) you will need to use QtQuick/QML and/or Kirigami as well. That would mean to not only handle C++, but go the JavaScript/QML path as well. If we consider our users (I mean developers wanting to have a cross platform GUI toolkit) then I assume there are very few ObjC developers (f.e. coming from iOS development) who want to ditch their xib files and storyboards and start mangling QML.

Going mobile first

If we take into account there already is a (incomplete) AppKit port by the GNUstep project I won't target the desktop as a first class citizen again, even though most of us probably like their desktops. But mobile marketshare is 59% vs 37% of the desktop with mobile still gaining space (https://www.netmarketshare.com/device-market-share).

That means most of the ObjC devs of the last years probably were iOS/UIKit developers and not developing for the desktop (AppKit), considering macOS was having 9.77% of the desktop market share in 2019 and iOS 28.23% of the mobile one (https://macdailynews.com/2019/06/03/apples-macos-and-ios-market-share-both-up-in-may-2/).

Targeting mobile first could lead to the usage of Gtk because with the efforts of the ongoing Phosh project apps are going to work mobile using the same C code basis afaik. Using Gtk themes these may even integrate into Android.

Conclusion

To be really appealing to UIKit devs that would mean to create a Gtk wrapper which is very close to UIKit. ObjC devs thus could provide a Gtk based frontend for Android/Gnome/Phosh/Windows (Mobile) with maybe little changes, but leave it unchanged for the Apple platforms. (UIKit apps sooner or later are going to work at every Mac, despite the ongoing development of SwiftUI of course, with Swift currently not providing ObjC bindings for Linux.)

As a free surplus of taking the Gtk way you will get that the Gnome/Elementary OS/Phosh communities probably are much more welcoming an approach that allows porting Cocoa (Touch) based software than the Qt/C++ communities.

Finally I like C over C++, but that's just personal preference.