[Webkit-unassigned] [Bug 144561] [GTK] Re-enable Quartz backend on cmake build system

Sun Jun 21 17:54:20 PDT 2015

https://bugs.webkit.org/show_bug.cgi?id=144561

--- Comment #28 from Philip Chimento <philip.chimento at gmail.com> ---
(In reply to comment #24)
> [...] we still
> haven't agreed on whether or not to support OS X in WK2.

I'd be very disappointed if you decided not to support it, for reasons detailed below. However, I definitely understand not wanting to make any guarantees about it. How about making it opt-in only? That is, commit the rest of the OSX patches but not this one. Or, commit this patch but explicitly print out a warning message when the Quartz option is activated, saying that it is not guaranteed to be supported.

(As a side note, I'd like to clarify that this issue is about supporting the compilation of WebKitGTK on OSX _with the Quartz GDK backend_. I don't see how you can prevent people from building WebKitGTK on OSX with the X11 GDK backend, since that goes through the same code paths as building it on Linux/X11. And indeed, most of the bugs blocking #126492 apply to both the X11 and Quartz backends on OSX.)

> Note that nobody can possibly be relying on this now, except maybe you,
> since the GTK+ WK2 API has never supported OS X before. [...] The
> argument for not merging the patch is that if we don't merge the patch,
> nobody will waste time porting their OS X application to WK2 (which is often
> a major effort!) only to find OS X support removed again down the line.

Respectfully, I think you might be misunderstanding the use case. As far as I know there are no OSX-only GTK applications, either using WK1 or not. I think the concern is more about Linux application developers who in principle would like their application run on all platforms where GTK runs, but have already ported it to WK2, unaware that that would cut them off from the OSX platform.

As an example, the case in point and the reason why I have been trying to build WK2 in the first place is Devhelp. There is no reason why Devhelp shouldn't be cross-platform, and indeed GTK may claim to be cross-platform but the developer experience on any platform that GTK supports will be pretty terrible without something like Devhelp.

I would be perfectly happy if Devhelp stuck with WK1 as I think there's no reason why Devhelp needs its webviews to be multiprocess. But when WebKitGTK 2.6 was released, Devhelp (and many other applications) were ported to WK2 because, I surmise, the developers were spooked by WK1 being deprecated. And indeed, there was some encouragement from the WebKit team in that direction as well. [1]

Devhelp, by extension, blocks Gnome Builder from being built on OSX, since Builder depends on a version of Devhelp from after the port to WK2. Builder is another application that I'd really like to see packaged for OSX.

> Since so few and
> small patches are currently required, it seems like a harmless good idea
> right now, but we've already agreed to make accelerated compositing
> mandatory and have no plans to implement accelerated compositing for OS X,
> so it's sure to break in the future and require significant work to update.
> [...] And note also that
> implementing accelerated compositing for OS X would require significant time
> and technical expertise, so being realistic I doubt it will happen.

I wasn't aware of this but thank you for bringing it to my attention. That makes it all the more important to me that at least one stable version of a recent WebKitGTK should just build on OSX. I suppose that will keep us going for a few years until the applications have all moved on to a minimum WebKitGTK version that requires accelerated compositing. :-/

A few questions though; excuse my technical ignorance, but is accelerated compositing being done outside of GDK? Will it also not be supported on OSX with the X11 GDK backend? If done outside of GDK, will you have to write separate implementations for X11 and Wayland?

[1] https://mail.gnome.org/archives/desktop-devel-list/2014-October/msg00048.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150622/c8938e57/attachment.html>