Hi everyone, It’s been a little over three weeks that I’ve been working on my Google Summer of Code project of making JavaScriptCore (WebKit's JS engine) and WebCore (WebKit's layout engine) build on top of GNUstep. Today, I’ve completed the first “phase” of the project, which pretty much involved 1) trying to build it; 2) noting down everything that broke.
This effort generated a TODO list for adjustments to GNUstep so that JSC and WebCore would work seamlessly on top of a GNUstep stack. Given this list, we can start deciding on where to focus efforts for making JSC/WebCore usable. Approaches include addressing the issue in GNUstep or patching WebKit in a “GNUstep port”, that would get around these issues by using some code from other current WebKit ports (GTK and Qt are some examples). First of all, I should address how the build was done. Until now, two WebKit components have been fully built (WTF and JavaScriptCore), and one has been compiled and not linked (WebCore). WTF (the Web Template Framework) is a series of helpers for WebKit which involves things as diverse as crypto, threading, text encoding, low-level memory analysis and inter-process communication. Most work here involved isolating (through preprocessor guards) code that had been marked in WebKit as Cocoa-specific, but that was in fact Darwin-specific — which will eventually constitute a patch to WebKit’s upstream. This Darwin-specific code was seamlessly replaced with its already-existing Linux-specific counterparts, and how to fit that into WebKit is not the matter of this thread. At this point, I chose to disable the remote inspector WebKit feature[1], since it relied on XPC and Darwin's notify functions for IPC. While these two libraries could eventually be implemented in a cross-platform manner, they currently rely on the Mach kernel's messaging model, so getting it to run on Linux would be too much of a hurdle for now. Moving on, some changes were done to WTF’s Platform.h header, which defines some WebKit capabilities on a per-platform basis. Here, I chose to disable support for audio, video, media streaming, RTC – since realistically, GNUstep is also far from implementing Apple's whole media stack, and graphics seem like a priority anyway. Since we have the option to disable these features "cleanly", it seemed like the right way to go for now. After this was done, the only issue that stopped WTF from working seamlessly was the lack of some CoreBase functions: CFLocaleCopyPreferredLanguages(); the CFPreferences* suite. (The latter will become a bigger problem when it comes to WebCore, but we'll get there.); and CFBridgingRetain/CFBridgingRelease, which is already the subject of a thread here which hasn't yet been concluded. Moving on, I started building JavaScriptCore. Building was done rather simply after some header adjustments in libobjc2, Base and CoreBase. I moved on to running the JSC tests, and as they failed I started fixing some bugs in GNUstep. The first was a problem with NSMapTable in base for which I submitted a patch to the mailing list which is currently inconclusive[2]. The second issue was a matter with CoreBase's run loop where we got into a deadlock if we tried to remove a timer from a run loop, for which I haven't yet publicly submitted a patch. I will open a pull request with both as soon as I split my myriad disconnected changes to Base and CoreBase in a series of organized commits. The next issue was a little more complex. JSC's bridge with Objective-C relies on a private extension Apple made to the Objective-C ABI which is only integrated with its ObjC runtime. An issue briefly documenting the matter was opened in libobjc2[3], and changes will need to be done to both clang and libobjc2. At this point, I chose to move on from the failing JSC tests and start building WebCore. In this process, I haven't yet generated any patch aside from a small one in Opal[4] regarding header issues, but I have generated a fairly big "TODO list" to follow. Although it is not complete (certainly linking and trying to run the tests, as with JSC, will show us some more hidden issues), it fulfills the purpose of giving me (and the project) elements to pick which direction to follow. It is as follows: 1) New Frameworks (mostly Carbon stuff that has not yet been deprecated) * CoreServices: implement TEC* converters (from CarbonCore.framework) * CoreServices: implement HITheme, HIEvents UI functions * CoreServices: implement CarbonEvents for the keyboard (from HIToolbox.framework) * ApplicationServices: implement UniversalAccess.framework * ApplicationServices: define kAX* accessibility constants (from HIServices.framework) * ColorSync: define ColorSync types (no actual implementation is needed) * Security.framework: implement Certificate Verification functions 2) Base (mostly new APIs introduced after OSX 10.4) * base: considerable adjustments to NSURL * +[NSURL fileURLWithPath:isDirectory:] (OSX 10.5, with some 10.6+ auxiliaries) * +[NSURL URLByResolvingAliasFileAtURL:options:error:] (OSX 10.10) * -[NSURL getResourceValue:forKey:error:] (OSX 10.6) * NSURL.fileURL * NSURLBookmarkResolutionOptions enum * base: minor changes to NSFileManager * -[NSFileManager attributesOfFileSystemForPath:error:] (OSX 10.5) * implement NSFileManagerDelegate (OSX 10.5) * base: minor changes to NSProcessInfo * -[NSProcessInfo disableSuddenTermination]; -[NSProcessInfo enableSuddenTermination] (OSX 10.6) * -[NSProcessInfo beginActivityWithOptions:reason:]; -[NSProcessInfo endActivity:], NSActivityOptions enum (OSX 10.9) * -[NSProcessInfo systemUptime] * base: implement NSURLCredentialPersistenceSynchronizable * base: implement new NSURLProtectionSpace authentication methods * NSURLAuthenticationMethodNTLM * NSURLAuthenticationMethodNegotiate * NSURLAuthenticationMethodClientCertificate * NSURLAuthenticationMethodServerTrust * -[NSURLProtectionSpace distinguishedNames] * base: implement new NSURLRequest cache policies * base: major changes to NSURLConnection * declare NSURLConnectionDelegate as a protocol * -[NSURLConnection currentRequest] (OSX 10.8) * -[NSURLConnection scheduleInRunLoop:forMode:] + unschedule (OSX 10.5) * -[NSURLConnection start] (OSX 10.5) * -[NSURLConnection setDelegateQueue:] (OSX 10.7) * NSURLAuthenticationChallengeSender corrections * base: update NSCoder to new APIs * -[NSCoder decodeObjectOfClass:forKey:] (OSX 10.8) * NSSecureCoding protocol and method (-[NSCoder requiresSecureCoding]) * base: NSDate: NSSystemClockDidChangeNotification * base: create NSMakeCollectable() as wrapper around CFMakeCollectable() * base: create NSURLSession class * base: create NSFileCoordinator, NSFilePresenter classes * base: add NSFileWriteFileExistsError = 516 to FoundationErrors * base: NSGeometry: create NSEdgeInsets, NSEdgeInsetsZero * base: add new NSHTTPCookie properties * NSHTTPCookie.HTTPOnly * NSHTTPCookie.secure * NSHTTPCookie.sessionOnly * base: NSCalendar: NSCalendarUnitSecond etc. new enum values * base: NSCalendar: NSCalendarIdentifier* enum 3) CoreBase * corebase: implement CFNotificationCenter functions * corebase: implement CFStringTokenizer functions * corebase: implement CFPreferences functions * corebase/base: implement -[NSRunLoop getCFRunLoop] 4) CoreNetwork For CoreNetwork we need to implement some further socket functions, CFHTTPMessage and proxy support. However, I wonder why CoreNetwork was started given CFNetwork's state. Is there any reason why we should push for CN rather than just use CFNetwork? 5) Opal (mostly small adjustments) * opalgraphics: re-typedef enums so they are interchangeable * opalgraphics: should definitely not need a cast between CGPathRef and CGMutablePathRef * opalgraphics: implement CGContextPathContainsPoint() for CGContext * opalgraphics: export CGImage property strings and CGImagePropertyOrientation enum for use with CGImageSourceCopyPropertiesAtIndex() * opalgraphics: CGPDFDocumentGetPage() * opalgraphics: new CGPath functions * CGPathCreateMutableCopyByTransformingPath() * CGPathGetBoundingBox() * CGPathAddRoundedRect() * CGPathCreateWithRect() * opalgraphics: divide OpalGraphics and "OpalImage" as an ImageIO equivalent[5] * opalgraphics/gui: create interaction between NSColor and CGColor * opalgraphics/gui: create interaction between NSImage and CGImage * opaltext: introduce SFNTLayoutTypes.h * opaltext: re-typedef enums so they are interchangeable * opaltext: update CTFontUIFontType enum with new values * opaltext: implement CTFontDrawGlyphs(), CTFontManagerCreateFontDescriptorFromData() * opaltext: define kCTFontOpenTypeFeatureTag, kCTFontOpenTypeFeatureValue constant strings * opaltext: update CTFontSymbolicTraits enum with new values * opaltext: implement CTLineGetBoundsWithOptions(), define CTLineBoundsOptions enum 6) QuartzCore (LOTS of work!) * quartzcore: +[CATransaction setCompletionBlock:] * quartzcore: major CALayer additions * -[CALayer setBorderWidth:] * -[CALayer setMask:] * CALayer.name * CALayer.drawsAsynchronously * CALayer.doubleSided * CALayer.borderRadius * CALayer.edgeAntialisingMask * -[CALayer renderInContext:] * CALayer's all sorts of filters * CALayer.contentsScale * CALayer.anchorPointZ * CALayer.borderColor * quartzcore: CAAnimation additions * quartzcore: -[CAAnimation isRemovedOnCompletion] * quartzcore: CAAnimation.keyTimes * quartzcore: CAAnimation.timingFunctions * quartzcore: implement CAValueFunctions * -[CAValueFunction name] * +[CAValueFunction functionWithName:] * generate CAValueFunction selection name constants * quartzcore: create unimplemented layer subclasses * CAOpenGLLayer * CAShapeLayer * CATransformLayer * quartzcore: new include guards for CATransform3D to operate ObjC-independenty (incorporate to current PR) * quartzcore: make NSView interact with CALayer[6] 7) GUI (LOTS of work too implementing modern APIs mostly) * gui: create NSGestureRecognizer * gui: create NSPasteboardItem * gui: create NSTextAlternatives * gui: create NSRunningApplication * gui: create NSSharingService * gui: create NSVisualEffectView * gui: create NSUserInterfaceLayout* enums (+ support in NSCell) * gui: create NSAccessibility functions and categories * gui: implement new NSWritingDirection enum values + NSWritingDirectionAttributeName (NSAttributedString) * gui: implement NSBackgroundStyle for NSCell * gui: NSSpellChecker: -showCorrectionIndicatorOfType:..., -dismissCorrectionIndicatorForView: (OSX 10.7) * gui: -[NSEvent isDirectionInvertedFromDevice] * gui: NSEvent: implement phases (NSEventPhase) * gui: implement NSPasteboardWriting, NSPasteboardReading protocols * gui: NSPasteboard: implement NSPasteboardType* constants; options * gui: -[NSScrollView setScrollerKnobStyle:] * gui: implement NSScrollView contentInsets, scrollerInsets * gui: NSScroller: implement scroller style * gui: implement NSSpeech property constants * gui: -[NSTextField sizeThatFits:] * gui: -[NSTextList startingItemNumber] (OSX 10.6) * gui: -[NSFontManager orderFrontStylesPanel:] * gui: NSView: implement NSFullSizeContentViewWindowMask * gui: NSColor: handle SRGB (OSX 10.7) * gui: +[NSCursor IBeamCursorForVerticalLayout] * gui: -[NSWindow setStyleMask:] * gui: NSCell.truncatesLastVisibleLine * gui: -[NSView setShadow:] 8) libobjc2 * implement _protocol_getMethodTypeEncoding() -- requires clang ABI change * make `nil` and `NULL` interchangeable[7] --- That all said, I'd really appreciate opinions on the items on the list if you've played with them before; or if there's any particular issue you'd like to work on to help me get a working WebKit :) Equally, if there's anything more seasoned project contributors consider more worthy of attention than other items. Thanks -- really -- for all the support so far, -- Daniel. [1]: https://trac.webkit.org/wiki/WebInspector#UsingtheWebInspectorremotely [2]: http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00015.html [3]: https://github.com/gnustep/libobjc2/issues/37 [4]: https://github.com/gnustep/libs-opal/pull/1 [5]: A preliminary discussion on this can be found on http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00033.html. [6]: This item, as Ivan has already mentioned to me, is extremely complex and should practically be considered as part of a section of its own. [7]: On Apple's stack, passing `nil` as a value for a raw pointer is accepted. In many cases in WebCore, it requires `NULL` to be used instead else the build breaks due to type conflicts. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev