El vie, 21-04-2017 a las 16:01 -0700, Geoffrey Garen escribió: > I think the biggest consideration here is the problems we’ve noticed > in the C API that have produced poor designs that we don’t intend to > support going forward. > > Does the WPE port’s API need to be backwards-compatible in a source > or binary way? > > Is it practical for the WPE port’s API to mirror the ObjC API?
The easiest way would be to reuse the GTK+ API. WPE has the same dependencies than the GTK+ port except for GTK+ itself. The GTK+ API of course depend on GTK+, but only for the WebView, and a few other fallback implementations like the file chooser, color chooser, printing, etc, that are, in any case, optional. So, we could move 95% of the GTK+ API to a common glib dir and reuse all that in WPE, only adding a WebView implementation for WPE. > Thanks, > Geoff > > > On Apr 21, 2017, at 2:24 PM, Alex Christensen <achristensen@apple.c > > om> wrote: > > > > This is exciting news, Zan! I’m happy to see innovative new uses > > of WebKit. > > > > What kind of groups hope to use this new port? What kind of groups > > hope to maintain this new port? Will it be beneficial to the > > WebKit community to have their cooperative work? I see having more > > groups motivated to organize things in a supportable way as > > positive. > > > > I don’t think we should just use the C API as it is. We want to > > eventually remove it completely. If we do upstream WPE, I propose > > doing something like one of the following: > > 1. We could make a new C API that more closely mirrors the Cocoa > > API, to which we only add things we have committed to > > support. This should be done in collaboration with the existing > > API owners. > > 2. We could mark parts of the existing C API as part of the API we > > have committed to maintaining. There is a lot of messy stuff in > > the existing C API we eventually want to remove even before we > > remove the whole thing (old client versions, testing-only > > functions, private functions that access things we want to > > eventually organize differently, etc.). For example, a lot of the > > things in WKContextPrivate.h should be moved from a multi-process- > > global approach to a WKWebView/WKPage-based organization. The > > basic concepts are here to stay, though. > > 3. Have third parties who use the API just deal with whatever > > changes we throw at them. This could be viable if there were only > > a few small groups using the API, but it would hinder innovative > > use of the API. We might want to reserve the right to make API > > breaking changes anyway, though. > > > > > On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote: > > > > > > Hi, > > > > > > the WebKit team at Igalia would like to propose upstreaming the > > > WPE port > > > of WebKit, taking on the duty to maintain it alongside the GTK+ > > > port. > > > > > > The WPE port started in 2014 as the 'WebKit for Wayland' project > > > inside > > > Igalia [1]. The port was derived from the GTK+ port, but avoided > > > dependency on any GUI toolkit. It relied on the Wayland display > > > protocol for on-screen presentation. That dependency was later > > > dropped > > > in favor of using generic interfaces to adapt to different > > > platform-specific presentation systems. This allows any vendor > > > to > > > simply provide the necessary backend implementations that are > > > tailored > > > to their platform. > > > > > > The port is intended to be the Web platform engine of choice for > > > embedded Linux systems. Since late 2014 Igalia has been > > > sponsored by > > > Metrological to further develop the WPE port, targeting primarily > > > various set-top box platforms. Miguel Gomez blogged about this > > > effort > > > back in December [2]. The port can also address other embedded > > > use > > > cases, for instance in-vehicle infotainment or digital signage. > > > > > > The GTK+ and WPE ports mostly have the same dependencies except > > > for the > > > GTK+ toolkit library. That enables the two ports to already > > > share a lot > > > of code. The biggest difference between the two is that the WPE > > > port > > > exposes the WebKit2 C API, while the GTK+ port exposes a GObject- > > > based > > > API. Apart from that, the maintainers' plan is to further align > > > the two > > > ports as much as possible, ideally simply stacking the GTK+ port > > > on top > > > of WPE, with only a few additional tweaks for GTK+ > > > integration. This > > > would lessen the maintenance burden for both ports and the > > > project as a > > > whole. > > > > > > The WebKit team at Igalia thinks this port is on stable footing > > > and has > > > solid prospects for the future. That's why we'd like to join the > > > upstream community and continue our work there. > > > > > > The patch with the port changes is in bug #171110 [3]. We have > > > existing > > > x86_64 buildbot configurations [4] that we would have to port > > > over to > > > the webkit.org build master. We're planning further builder and > > > tester > > > configurations for ARM architectures in the future. Layout test > > > baselines would be landed separately. (Those too would be > > > subject to > > > alignment with the GTK+ port.) > > > > > > We're happy to address any questions or considerations. > > > > > > Regards, > > > Zan > > > > > > [1] > > > https://lists.webkit.org/pipermail/webkit-dev/2014-December/02708 > > > 7.html > > > [2] > > > https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for- > > > embedded/ > > > [3] https://bugs.webkit.org/show_bug.cgi?id=171110 > > > [4] https://build-webkit.igalia.com/waterfall?category=WPE > > > _______________________________________________ > > > webkit-dev mailing list > > > webkit-dev@lists.webkit.org > > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
