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

[Fred Kiefer]

Sorry, I don’t have time for a proper reply, but if you need a co-mentor and if 
it isn’t already to late I could register again this year. After there we 
didn’t expect any students I was to lazy to go through the process.

In gui Daniel could work for example on the NSTextBlock  or whatever bit of 
layout mechanism is still needed to cover basic web layout.  I find the 
proposal very attractive and even if we won’t get a full working WebKit at 
least we will have a better overview of which parts are still missing in 
GNUstep to support it. As for the missing frameworks there are different 
sources where part of these could be taken from. This is not central to GNUstep 
so even non GPL frameworks could do here.

Fred


> Am 31.03.2017 um 19:23 schrieb Ivan Vučica <ivan@vucica.net>:
> 
> (replying from phone)
> 
> This mailing list is probably the best one to discuss this.
> 
> 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.
> 
> 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 :)
> 
> 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!
> 
> 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.
> 
> JSCore seems like a cool project, but I defer to others who looked more into 
> bridging projects like that.
> 
> 
> 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
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep