回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)

[Max Chan]

Apple implemented SwiftUI as a wrapper on top of AppKit and UIKit for macOS and 
iOS respectively, however architecturally those three libraries are at the same 
level. This is why I am suggesting us doing the reverse, making our AppKit and 
UIKit wrappers of SwiftUI. A better way to phrase this is that our partial 
SwiftUI becomes what Back used to be. So instead of being a bundle embedded in 
GUI, Back implementing SwiftUI becomes a proper framework standing on its own.

SwiftUI is a new framework, so it would be a while before any major open source 
release happens.

-----邮件原件-----
发件人: Ivan Vučica <ivan@vucica.net> 
发送时间: 2019年11月27日 22:51
收件人: Maxthon Chan <xcvista@me.com>
抄送: Discuss-gnustep Discuss <discuss-gnustep@gnu.org>
主题: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 
features are missing in the latest GCC?)

On Wed, Nov 27, 2019 at 3:32 AM Maxthon Chan <xcvista@me.com> wrote:
>
> When talking about SwiftUI, I mean having CAAppKitBridge/Opal/Back implement 
> SwiftUI API as its interface to the upper layers.

I am getting increasingly confused here. Why would these particular libraries 
implement the SwiftUI APIs?

Especially CAAppKitBridge which tries to use Opal backend in gnustep-back to 
paint gnustep-gui's views into CA's layers, by creating a GL view, scheduling 
repaints, etc?

Was I under the wrong impression that SwiftUI is a replacement / wrapper around 
AppKit/UIKit? In fact, Apple's basic tutorials suggest that it sits around / in 
place of UIKit, so does this discussion even apply in context of AppKit APIs?

What Mac-native open source apps can you point me at to basically understand 
SwiftUI without reading through tutorials?