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

[Max Chan]

TBH I am not familiar with how GUI and Back interacts, and I am confused at why 
GUI, Back, Opal et al are layered that way.

-----邮件原件-----
发件人: Ivan Vučica <ivan@vucica.net> 
发送时间: 2019年11月27日 23:17
收件人: Max Chan <xcvista@me.com>
抄送: Discuss-gnustep Discuss <discuss-gnustep@gnu.org>
主题: Re: 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:01 PM Max Chan <xcvista@me.com> wrote:
>
> 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.

Are you sure you're correctly considering what -back actually does?

I don't think it makes sense to throw away all of -gui and possibly -back. I 
also don't think what you're saying is necessarily possible.
See how -draw* methods can be overridden, and how these calls eventually 
descent through -gui and -back into cairo, or art, or something else. Consider 
how graphics contexts are created and used in -back, how transforms are kept 
around, etc.

If this was at work, I would request a design proposal and possibly a detailed 
design document at this stage, but given this is a free software project, I'll 
just say that this would certainly be interesting to read a partial 
implementation of your proposed architecture.

If you want to bring something SwiftUI*-compatible into the story, I think 
wrapping it around AppKit lib (not around the nonexistent UIKit
lib) makes sense. Alternative is treating it as a new, independent entity and 
not touching -gui. Certainly I would seriously consider inverting the 
dependencies in this way without a very strong reason -- and a much stronger 
case can be made to put -gui on top of Opal, where -gui turns into backends for 
Opal. So, why would you prioritize this over CAAppKitBridge's truly 
noninvasive* changes to paint into a CALayer?

And this is all unimportant if the Swift bridge is not in place first.

* We should certainly not call a compatible implementation "SwiftUI"
except for compatibility reasons, and I should finally go ahead and rename our 
CA-compatible library too.
** They're noninvasive because if you don't load CAAppKitBridge's categories or 
use the Opal backend, you simply don't get to paint into CALayer; everything 
else works. There's just two i-vars and a property added to the NSView, 
otherwise, you don't really need to care.

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

You mean a major release of SwiftUI, or some major open source program being 
implemented using SwiftUI? Are there intentions to release SwiftUI as a free 
library? Can you point me at this?