Re: State of the WebKit port

[Ivan Vučica]

On Tue, Jun 20, 2017 at 4:40 AM Daniel Ferreira (theiostream)
<address@hidden> wrote:
>
>
> 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.

Could you push some *preliminary* patches somewhere public?

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

Having to do anything Carbon related is frustrating. Ugh. I hope you
can minimize the need to implement Carbon stuff.

I'd be happy if we had stubs that returned noops, especially related
to HIEvents. Let's not dwell on having functioning input for your GSoC
project.

I found something about HITheme (for purposes of the project, I'd be
happy if we started off with drawing a rectangle in place of a widget,
and then figure out how to provide a correct implementation later),
but can you share what HIEvents is?

>
> * 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

Ouch.

At least a lot of the stuff seems enums. That seems to be a low hanging fruit.

No other comments.

>
> 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?


If we can actually use CFNetwork, we can use CFNetwork and evaluate
the results afterwards.

Lubos might need CoreNetwork as-is for Darling (+cc for visibility).
But it seems to be a stub, so he may be happy to get CFNetwork in its
place.

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


Since Opal does not currently depend on AppKit, these conversions
between NS/CG should be carefully done in an additional compat
library.

Also, I think it's totally reasonable for your port to depend on the
'opal' backend in gnustep-back.

>
>
> * 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]


Much of this is super-complex and interacts with a lot of
implementation details. Visual bugs are probable if you stub out some
of the stuff (borders, ...) -- and we can live with that. Ditto for
blurring et al. Not implementing animations will cause CSS animations
shenanigans to break, which I believe to be another thing we don't
really care about for purposes of your project.

Based on complexity I would strongly discourage trying to *correctly
implement* the following (that is: stub it out, and defer it for
post-GSoC/next-GSoC work):
* CAOpenGLLayer
* -[CALayer setMask:]
  - this requires rearchitecting the shaders (which are done for
shadows, and are already bad and don't do shadows well)
* CALayer.borderRadius
  - ditto as above
* CALayer's all sorts of filters
* CALayer.contentsScale

I would lightly discourage trying to correctly implement the following:
* CAShapeLayer
* -[CALayer setBorderWidth:]
* CALayer.borderColor
* CAAnimation.keyTimes

I'm conflicted about -[CALayer renderInContext:]. Playing with
framebuffers and copying things out of it will be... "fun". But I
suspect it's required. Can you confirm whether this is used regularly,
or only when CSS animations are in play?

One thing to remove from the list: CAAnimation.timingFunction is
actually implemented. :)
  
https://github.com/gnustep/libs-quartzcore/blob/e4d17ce/Source/CAAnimation.m#L651
(That was one of the trickiest parts of the whole thing to wrap my
head around, at the time.)

>
> 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:]


Ouch.

Out of these I can only say 'ignore setShadow', as it depends on CALayer.

NSVisualEffectView would be super hard to correctly implement without
control of a compositing window manager (so we can screenshot+reuse
the texture 'under the window'), without CALayer integration and
without blurring filter in CALayer. Please stub it with a NSView.
Though, honestly, it amazes me that it's required for WebCore...

NSUserInterfaceLayout* seems like it's used for LTR+RTL support. I'm
not sure if GNUstep overall supports RTL? If not, this can probably be
stubbed out and we can pretend that both constants are LTR.

Other stuff seems unfortunate but reasonable.

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

Yep, please rebase that PR and add ChangeLog entry / entries. :)

> [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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev