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

[Max Chan]

Hmm if this is the case, maybe we should end up with the Opal backend being 
merged into GUI proper and all other backends discarded. Way too many actual 
macOS and iOS apps uses CoreGraphics directly.

Also maybe we should drag OpenGL into this discussion, as a lot of 
CoreAnimation stuff may need that. If this way, we have:

CoreAnimation: OpenGL open a window on screen.
Opal: Use cairo to CPU-render the view and put it onto that OpenGL window.
GNUstep GUI: NSView paints a window.

Dragging OpenGL in the discussion also allows us better compatibility with 
Wayland too, as AFAIK Wayland uses exclusively OpenGL to render anything on the 
screen.

(There has been a trend in the Linux world to copy Apple architecture. systemd 
is a clone of launchd and networkd, Wayland is modeled after windowserver, etc. 
We might as well play along.)

-----邮件原件-----
发件人: Ivan Vučica <ivan@vucica.net> 
发送时间: 2019年11月27日 23:34
收件人: 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?)

gnustep-back: x11 / win32 open a window on the screen.
gnustep-back: Opal [let's treat it as a blackbox] / Cairo / libart / xlib can 
paint into it.
gnustep-gui: NSView paints using Opal/Cairo/libart/xlib into x11/win32 window 
-- this is the stuff in gnustep-back

Opal uses Cairo, but that's an internal implementation detail. It could have 
multiple backends in theory. It exposes a Core Graphics API.

Opal is, to me, the important backend because Core Animation's APIs (and 
therefore the ~compatible partial implementation in GNUstep) uses CGContext as 
the 'thing to paint into'. It happens to use Cairo, but Core Animation doesn't 
care as long as it can get the pixels out and uploaded to the GPU into a GL 
texture. (It might care if we can do that directly without a copy of pixels -- 
maybe Cairo can paint directly into GPU somehow, I never looked at that.)

Either way, the layering as it is right now makes sense. There's confusion 
about where should some of the graphics context state be kept (gnustep-back? 
cairo+libart+xlib?) but that's not the critical part of the layering.


On Wed, Nov 27, 2019 at 3:26 PM Max Chan <xcvista@me.com> wrote:
>
> 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?
>