On Tue, Jun 20, 2017 at 4:40 AM Daniel Ferreira (theiostream) <bnm...@gmail.com> 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 > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev