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 <[email protected]> 发送时间: 2019年11月27日 23:17 收件人: Max Chan <[email protected]> 抄送: Discuss-gnustep Discuss <[email protected]> 主题: 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 <[email protected]> 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?
