This is indeed great news, and would be an excellent contribution; it would really be cool to see an assignment to FSF indeed.
An ideal implementation would use CALayer underneath UIView, rather than -renderWithBoundsToGL. GNUstep has CALayer in the form of the library which is "still" called 'GSQuartzCore' -- ideally I'd take some time to rename that into 'OpalAnimation' or similar, to match the naming of the rasterization library, but it was never urgent. In any case, having a mainloop and event system classes would already be important. I expect we'd have to move make +[UIApplication sharedApplication] return the AP_Application's g_Application _always_ (or whichever platform-specific subclass is being used). https://github.com/more-please/inkle-android/blob/ed7f95c81c2f8ea603e2d5eef5e10ea4ae077a08/APKit/src/AP_Application.m and generally take bits-and-bobs of APKit_main.mm: https://github.com/more-please/inkle-android/blob/ed7f95c81c2f8ea603e2d5eef5e10ea4ae077a08/APKit/src/APKit_main.mm If I were to work on this, I'd aim for the following with the above codebase (assuming the copyright assignment happens): 1. Have app main function and UIApplication implemented. 2. Have them synthesize UIEvents that resemble the other platform's UIEvents. 3. Get UIEvents plumbed all the way into UIViews Then we could: 4. Assuming we now have UIWindow open a platform-specific window with a GL context (whether with AppKit or otherwise), get GSQuartzCore to paint into that GL context 5. Make the tree of UIViews be backed by an equivalent tree of CALayers 6. Implement UILabel and UIButton as proofs of concept Then it gets even more interesting with UIViewController, UINavigationController etc, which maybe again Inkle codebase can help with? Frederik: I wonder whether some bits of this would relate in an interesting way to Algoriddim's Android apps? On Mon, Jul 1, 2024 at 4:07 AM Ethan C <[email protected]> wrote: > Hi everyone, > > We have great news! Back in 2014 > <https://www.inklestudios.com/2014/03/11/tech-focus-android.html>, Iain > Merrick worked with Inkle Studios to port their games "Sorcery!", and later > "80 Days" and the "Sorcery!" sequels, to Android using OpenGL ES 2. Later, > he used the same codebase to port those games to macOS and Windows. He has > recently agreed to share his UIKit implementation with us, and his code can > be found at https://github.com/more-please/inkle-android. I am working to > get this code to work on GNUstep-on-clang-on-Linux, and later on to get it > back to Android and Windows. You can see my revisions here: > https://github.com/ethanc8/inkle-android. Most of the code compiles > rather nicely, but the UIKit mainloop is stuck in a thousands-of-lines file > with many platform-specific intricacies, so I haven't ported that over yet. > > This is quite an important contribution, which if we can properly > use this code, could give us a large start on being able to port iOS > applications to other systems, and harness the large iOS developer > ecosystem. However, the age of his UIKit code and the fact that Inkle's > games did not use as much UIKit as some more UI-heavy applications might > would require us to do major revisions. Additionally, we have not yet > received copyright assignment from him, and in the case that that couldn't > happen, it might be difficult to ensure that the project is legally sound. > Finally, as GNUstep approaches compatibility with macOS and iOS, we may > draw the attention of Apple's management and legal teams, which may invite > unpleasant legal circumstances. Therefore, it would be important to make > sure that the Free Software Foundation can defend the project against > lawsuits and that the project is on as sound legal ground as possible. This > may necessitate the rewriting of all of the header files in Iain's UIKit > implementation, and further talks with Iain about legal matters. > > Thanks, > > Ethan Charoenpitaks >
