On Tue, Nov 26, 2019 at 3:49 PM Maxthon Chan <xcvi...@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.)
