On Fri, Mar 31, 2017 at 10:53 AM, David Chisnall <[email protected]> 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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
