Re: [GSoC] Make WebKit run on top of GNUstep

[Daniel Ferreira (theiostream)]

On Fri, Mar 31, 2017 at 2:23 PM, Ivan Vučica <ivan@vucica.net> wrote:
> I am generally willing to mentor GNUstep projects, but WebKit seems like a
> project where student needs to be extra-self reliant. It would be hard for
> me to mentor on internals of WebKit or intricacies of bridging ObjC with
> other languages.

I would assume so. After all, I'd have a GNUstep mentor, not a WebKit
mentor. My expectations would be to count on a mentor for questions
like "hm, how would should I go about architecting this missing CF
function?" or "do you think it'd be feasible to do [whatever WebKit
needs] in GNUstep or should we use a third-party library?", as well as
general questions about the GNUstep environment and contributions to
it.

What I think would really help for the occasional question about
WebKit porting though would be a contact in the project – after all,
they *did* offer assistance to creating a port to GNUstep back in the
day, right? Anyway, if that person can't be found I'd be fine just
going to the WebKit developers' mailing list to ask stuff.

> Speaking of downscaling the project, it is hard to downscale something like
> the an embedded web engine. Without already having familiarity with WebKit,
> setting a goal of "paint '<h1>hi</h1>hello'" might mean either giving the
> student too little or too much to do :)

True. I'm not sure finding the right size for a proposal (due on two
days, so not much time for research) will work best by having a set of
things I want to do. A better idea might be attained by listing the
things I do *not* want to do:

* I do not expect to build WebKit or WebKit2 (as in the public
interface to the engine). That's a later step.
* When building WebCore, I do not expect to have audio/video support,
as I mentioned earlier.

When I look at the other Cocoa-platform-specific code right now, I
don't see anything monstruous enough to consider it undoable.

> When it comes to CEF and such, I would not discount the value of having
> pretend-WebViews that use CEF: as an example, having something that can
> paint HTML-rendered invoices allows for easier writing of invoicing apps in
> GNUstep. However I'd expect it to be hard to interact with DOM and (as David
> said) restrict what you can do with it. It would still be super useful!

I understand that it'd have a great effect on the short-term, but the
thing I'm most interested in is playing with WebKit, really.

> When it comes to Quartz/Core Animation et al, one of the other ideas that we
> put up is to integrate Core Animation with AppKit. It would make us come
> closer to using Cocoa WebKit with less modifications. As is, I'd expect you
> would have to do away with anything that uses CALayers and your port would
> look more like the GTK or other ports.

To use CALayers, we'd have to build on top of this
(https://github.com/gnustep/quartzcore), right?

> JSCore seems like a cool project, but I defer to others who looked more into
> bridging projects like that.

Like I said to David, I worry that purely work on exposing the JSC
Objective-C API might not be enough work for three months. But I
appreciate any further feedback.

Anyway, despite being an extremely large project, I'm positive that a
LOT can be done with three months of full-time dedication. :)

There is only one thing that worries me: how are patches sent
to/reviewed by the GNUstep community so that I can plan my proposal
accordingly? (I guess another incentive to work more on making stuff
work in GNUstep than do stuff with GTK and friends in WebKit is that
this process seems way faster and less convoluted in GNUstep).

-- Daniel.

>
> On Fri, Mar 31, 2017, 16:03 Daniel Ferreira (theiostream) <bnmvco@gmail.com>
> wrote:
>>
>> On Fri, Mar 31, 2017 at 10:53 AM, David Chisnall <theraven@sucs.org>
>> wrote:
>> > Hi Daniel,
>> >
>> > I don’t have time to mentor this year, unfortunately, but it’s great to
>> > see someone interested in this.
>>
>> :)
>>
>> > In an ideal world, the way of doing the port would be to very simply
>> > implement all of the missing functionality in GNUstep, but that’s likely to
>> > be a huge amount of work.  That said, WebCore has a number of porting 
>> > layers
>> > for platforms that don’t provide all of these frameworks and many of them
>> > work by providing the required functionality (or falling back to some other
>> > library).  I can see three possible ways of managing a port, in increasing
>> > order of difficulty:
>> >
>> >  - Implement the WebView classes wrapping something like Nuanti Meta or
>> > the Chromium Embedded Framework.  This would use non-GNUstep widgets, but
>> > still basically work.
>>
>> Hm, this would not even involve the proposal of porting WebKit, right?
>> I see Nuanti Meta/CEF being somehow glued into SimpleWebKit or in the
>> Étoilé browser to, as you put it, "basically work". But I suppose
>> porting WebKit could be cool not only to get a web browser working,
>> but to get GNUstep to have equivalents of OSX/iOS's WebKit.framework
>> and JavaScriptCore.framework and do a greater step toward source code
>> compatibility with Cocoa.
>>
>> >  - Implement a new port that would use GNUstep widgets for buttons, text
>> > views, and other form elements, but use non-GNUstep everything else (text
>> > layout with whatever the GTK / Qt ports use and so on)
>> >  - Implement all of the missing Cocoa APIs that WebKit needs and do a
>> > simple recompile.
>>
>> I think the right way to go is a balance between the two, plus an
>> easy-way-out approach in some cases.
>>
>> For instance, I wouldn't worry much about building WebCore without
>> audio/video support to get rid of depending on AVFoundation,
>> AudioToolbox, AudioUnit and CoreAudio; or gamepad support to not have
>> to rely on IOKit or IOSurface, none of which will around in GNUstep
>> predictably for a long time. These things are not crucial to having a
>> decent web browser working, would generate too much effort/overhead if
>> we borrowed from GTK/Qt ports and well, this momentary limitation
>> might be an interesting incentive to kickstart these libraries in
>> GNUstep. (Note: there are in fact ways to turn audio/video off in
>> WebCore).
>>
>> Aside from the text layout example you used, we could apply the
>> "second approach" for stuff like Security.framework and
>> SystemConfiguration.framework. It would be too much effort to bring
>> them to GNUstep right-away, and in this case specifically it's quite
>> easy to generate a "replacement" cross-platform code for it – we might
>> even borrow from other ports. There's also code that still uses
>> Carbon, so that might be another case for this approach.
>>
>> As for stuff like missing Foundation/CF stuff (or even in Quartz), my
>> approach would be to add the missing implementation in GNUstep.
>>
>> > The second is these is probably the most useful, though it’s probably
>> > out of scope for a single GSoC project.  It might be feasible to put
>> > together something to do this incrementally, for example using the portable
>> > widgets that Chrome added and incrementally replace them with GNUstep ones.
>>
>> I'd appreciate some detail on this: I'm a complete novice to what
>> GNUstep has already implemented in graphics, text, widgets etc. Could
>> you shed some light on this?
>>
>> I don't like reliance on GNOME/GTK because we're assuming the guy
>> running GNUstep is doing so on a target supported by it. But if you
>> think it's a reasonable compromise GNUstep can take and not a
>> deviation from any sort of decision previously taken, doing the most
>> we can with GNUstep but falling back to GNOME when necessary seems
>> like a feasible approach.
>>
>> Speaking about it though, I am more and more sure that porting WebCore
>> fully is not something that can be done by a single person in three
>> months. I speak more about JavaScriptCore below, but I wonder if there
>> is any sub-goal I can set on my proposal, like, "make [this component]
>> and [rendering of this] work in WebCore". Any ideas?
>>
>> > One smaller project that might be interesting and feasible within the
>> > GSoC would be getting JavaScriptCore working with GNUstep.  It now has a
>> > very mature Objective-C bridge and this makes it possible to write Cocoa
>> > applications in JavaScript (as well as using JavaScript for scripting as a
>> > replacement for AppleScript).
>>
>> I did get to play a little with WTF and JavaScriptCore. I don't think
>> WTF needs any porting at all (the only Cocoa-specific parts of it is
>> using CF for threading and some other thingies; at least at a first
>> glance, it'd be fine for JSC and WebCore to link with it building the
>> Linux-standard version.
>>
>> As for JavaScriptCore, I reached the same conclusion -- getting the
>> ObjC bridge to build using GNUstep's libobjc2, Base and CoreBase seems
>> like a cool project. The result then could even be dropped into
>> SimpleWebKit instead of its ECMA* classes and solve a bunch of issues.
>> However, even though I did not dimension the effort required, but I
>> don't think it'd take three months of full-time work. What I *was*
>> planning was to work on it on a pre-code GSoC period (prior to May 30)
>> as a "warm-up" to learn more about WebKit's build system and get
>> acquainted with GNUstep since I suspect some functions would need to
>> be improved/implemented for JSC to build properly.
>>
>> BUT, this could most certainly be reviewed if you, who certainly have
>> more experience than me in this effort, assert that there *is* enough
>> to do for JSC to take a summer. :)
>>
>> > David
>>
>> Thanks for the feedback, and I think this is a good opportunity to ask
>> – is this mailing list the right place to discuss this? Who would
>> possible mentors to the project be for me to talk to them?
>>
>> -- Daniel.
>>
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep