[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which O

From: Ivan Vučica
Subject: Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)
Date: Wed, 27 Nov 2019 15:17:25 +0000

On Wed, Nov 27, 2019 at 3:01 PM Max Chan <address@hidden> 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

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

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]