[Webkit-unassigned] [Bug 178655] [WPE] webkit_web_view_new() should enable specifying wpe_view_backend object

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 24 02:49:54 PDT 2017


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

--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Zan Dobersek from comment #2)
> (In reply to Carlos Garcia Campos from comment #1)
> > Right. We just need to figure out how to expose WPE lib objects in the API,
> > because libwpe is not introspectable and it doesn't have documentation
> > either.
> 
> I don't think we should treat introspection support as a priority.

It's not a priority, but we should take it into account when designing the API.

> As far as C headers go, forward-declaring struct wpe_view_backend type is
> enough.

I think public headers should include the wpe headers, except the platform-specific ones, of course.

> > How does the user know which bakends are available? how to create them?
> 
> That depends on what platform-specific WPEBackend implementation (which
> provides its own headers) the user is leveraging.
>
> > who owns it once passed to yhe new function? should it be manually
> > freed after being passed? or when the web view is destroyed? etc.
> 
> If it's passed to the constructor, ownership is not passed. If WPE::View has
> to load the interface-implementing object manually, then it's owned by that
> WPE::View object. Note this isn't currently implemented in such a manner,
> and should be fixed.

We need to clarify that. But my point in general is that if we expose wpe objects in our public API, wpe libraries should be documented too.

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


More information about the webkit-unassigned mailing list