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

[Ivan Vučica]

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.)