ObjFW  Timeline

6 forum posts by user letterus

2021-07-05
20:28 Reply: GUI framework - call for help! (artifact: 8cdafe60c7 user: letterus)

To sum it up:

I want to try porting CoreGTK (the CoreGTK generator) over there: https://codeberg.org/Letterus/coregtkgen

This is mainly to get into it. If I succeed there at least would a thin wrapper for GTK3 (and maybe libhandy later). I could use what I've learnt to improve a new version for GTK4.

I am still thinking about the port. It seems Tyler Burton has implemented a solution for way number 1 (ObjC callbacks). I think way 2 (data binding) is missing at all. This is because CoreGTK is a wrapper around GTK only and thus provides no features of GLib as GObject binding. On the other hand we probably can't use ObjC binding (KVO) because CoreGTK still uses plain C GObject structs.

What do you think? How much is data binding needed? I know UIKit tries to avoid KVO mostly (compared to AppKit), but I'm not familiar with UIKit programming. Would you recommend to try a port of CoreGTK?

2021-05-30
21:30 Edit reply: GUI framework - call for help! (artifact: c8a0520f80 user: letterus)

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 manually 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.

20:39 Reply: GUI framework - call for help! (artifact: bf95607d54 user: letterus)

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.

2021-03-14
22:06 Edit reply: GUI framework - call for help! (artifact: b09f3db346 user: letterus)

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.

Edit: Removed the reference to Android. There is no reasonable port of Gtk for Android yet.

22:05 Edit reply: GUI framework - call for help! (artifact: 2d061330ef user: letterus)

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.)

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.

Edit: Removed the reference to Android. There is no reasonable port of Gtk for Android yet.

17:10 Reply: GUI framework - call for help! (artifact: 5d8a88cc7d user: letterus)

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.