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

[Daniel Ferreira (theiostream)]

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.