Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

When talking about SwiftUI, I mean having CAAppKitBridge/Opal/Back implement 
SwiftUI API as its interface to the upper layers. This gives us both a partial 
SwiftUI implementation that will be useable when we get Swift interop, and a 
common denominator where both AppKit and UIKit can stand on. Then we can have, 
for example, NSView and UIView both implemented based on SUIView. (SwiftUI 
classes lacked prefixes, so for the Objective-C based partial implementation I 
am suggesting adding SUI as the prefix.)

As of Swift interop itself, the main hurdle is ABI. I don’t think GCC can even 
emit code in either GNUstep runtime or Apple Swift runtime and their ABIs, so 
that is why a GCC-built GNUstep have no hope at attempting Swift interop. 
Apple-released Swift compiler have interop code in its source tree but it is 
disabled outside macOS. What we need is somehow patch it to enable interop, 
choose which libobjc, Foundation and CoreFoundation to use (either patch our 
own version, or throw out our own code and use Apple’s version,) and then 
somehow figure out how to make it work with the rest of GNUstep code.

While the high level API for libclang is C, I think Xcode uses a bit more than 
those and taps into the C++ part, so C++ is needed.

> On Nov 27, 2019, at 6:04 AM, Ivan Vučica <ivan@vucica.net> wrote:
> 
> On Tue, Nov 26, 2019 at 3:49 PM Maxthon Chan <xcvista@me.com> wrote:
>> 
>> AppKit on CoreAnimation can be our first big piece of fully ARC code. I 
>> don’t think anything in AppKit would require special memory handling, so it 
>> should be able to be fully ARC'd. Just by enabling ARC and @properties we 
>> get a lot of potential bugs out of the system.
> 
> Can you share your design for how AppKit on Core Animation would work
> in GNUstep?
> 
> Because ARC would not help with the design we went with during GSoC
> 2018 -- see 
> https://github.com/gnustep/libs-quartzcore/tree/master/CAAppKitBridge
> and related changes in -gui etc. The issues were not due to ARC and
> @properties (with @properties actually being available on recent GCCs,
> I think). The issues were, if I remember correctly, due to things
> getting painted in the wrong location, with some properties being
> reset at the wrong time, et cetera. Very frustrating for student,
> myself and (I hope I'm not speaking out of order) Fred.
> 
> Therefore, do you have a different proposal on how AppKit should paint
> onto a CALayer, with a root CALayer being painted onto the screen?
> 
>> Actually if UIKit is in the plans,
> 
> Your phrasing brings some joy when I'm looking at the English idiom
> "in the plans" :-)
> 
> As in -- there are plans, as in "we have at least two options on how
> to proceed", but nobody has committed to working on either.
> 
> Two options that come to mind:
> 
> 1. carefully implement UIEvent+UIApplicationMain, then
> UIView+UIWindow, then UIButton, then UITableViewController, then
> UINavigationController, carefully segregating window+GL context+event
> pump functionality into backends (like on gnustep-gui)
> 2. finish CAAppKitBridge, then port Chameleon, improving
> AppKit+CA+Chameleon along the way
> 
> I'd say that finishing CAAppKitBridge is good anyway, while
> implementing UI* classes from scratch is certainly a fun activity (and
> one that might be easier to put on mobile platforms, for instance on
> Sailfish).
> 
>> before working on AppKit I would suggest working on SwiftUI first (at least 
>> a Objective-C based subset of it that can result in the correct Swift 
>> interface when we get Swift interworking) and build AppKit and UIKit on top 
>> of that. (This is like Apple using CoreFoundation as a common denominator 
>> between Carbon and Foundation, I am suggesting using a partial SwiftUI as 
>> the common denominator between AppKit and UIKit.)
> 
> I can tell you for sure that I am personally completely unfamiliar
> with SwiftUI, and almost completely unfamiliar with Swift itself, so I
> can only comment on what I'd do to switch AppKit to Core Animation,
> and what I'd do to start writing UIKit. Whoever wishes to address this
> before I get around to it, reach out to me.
> 
> If someone wants to tackle SwiftUI before finishing CAAppKitBridge,
> I'm afraid I'd be useless. Maybe there's someone in the community that
> could help with this activity?
> 
>> Also if we get that improved C++ support, we can start working on a better 
>> IDE and build system that is comparable to Xcode.
> 
> Why is C++ support a requirement for working on a better IDE?
> 
>> Modern Xcode uses libclang and libllvm for code highlighting and code 
>> sensing, so that is why Objective-C++ is needed,
> 
> Unless libclang's API changed significantly since I used it in 2013 at
> university, Objective-C++ is not a requirement for code highlighting
> and code sensing. I'm looking at my old code in a .m file and the API
> is raw C.
> 
>> and it is also a huge piece of ARC code (Apple made a point when they 
>> converted Xcode from GC to ARC in Xcode 5.)
> 
> Which huge piece of ARC code are you referring to that we can use?
> 
>> As of our replacement xcode-build and IDEKit (the library parsing xcodeproj 
>> bundles) that can also be a huge piece of ARC code.
> 
> This is a different problem. It *can* be, it doesn't have to be.
> 
> Plus, an improved editor doesn't *need* to be Xcode-compatible or able
> to read Xcode project files (though it's a nice bonus).
> 
>> And there is Swift interworking since I mentioned SwiftUI, which requires 
>> clang.
> 
> This, again, does not mean GS core *needs* to depend on Clang. Does
> Swift interop (which, if it's available on non-Apple platforms, I'd
> love to familiarize myself with) actually require such changes to
> GNUstep's headers and implementation that we cannot segregate it from
> the rest of GS?
> 
> David's argument (as far as I understand it -- he can correct me) is
> that many things become simpler to implement if we use Objective-C++
> and ARC. And if we adopt it, I accept that it's far easier to delete
> the older implementations of the functionality -- the implementations
> which require neither ARC or Objective-C++. This is indeed very
> appealing.
> 
> However, I remain unconvinced that we *have* to remove the old code
> and that it's such a heavy burden to have a version for the GCC
> runtime and GCC and a version for libobjc2 and Clang.
> 
> (And, of course, this is a separate issue from how binaries --
> including developer 'binaries', such as Debian's configuration for
> building GNUstep software shipping in gnustep-make -- should be built,
> and whether they should arrive to users preconfigured for GCC and GCC
> runtime. But that's a separate topic.)