[Webkit-unassigned] [Bug 210422] [GTK][WPE] Add API to expose UIClient::requestStorageAccessConfirm

[bugzilla-daemon at webkit.org]

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

--- Comment #11 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #10)
> (In reply to Carlos Garcia Campos from comment #8)
> > We are already adding another header for the cases where gtk4 needs a
> > different API. I don't think it's worth using a different header for all
> > classes in gtk4 just to me them final.
> 
> At the risk of getting a bit off-topic for this bug, we've probably reached
> the point where it would be useful to have a "control header" to allow us to
> use conditional compilation in the public headers.

Headers include gtk so I guess we can use #if GTK_CHECK_VERSION. I still don't like condition compilation in public headers, though. What's exactly a control header?

> Then, we only need to
> duplicate the control header for GTK4, rather than every such header. In
> fact, if we were able to use preprocessor guards we should be able to
> eliminate duplication between WPE and GTK headers as well and just have one
> header for WPE, GTK3, and GTK4. Is there any reason we cannot do that? (I
> guess there is some reason I cannot think of, or you would have done this
> already?)

I don't understand the proposal, TBH.

> Then we can guard all the GObject boilerplate in every header behind #if
> !USE(GTK4) and use either G_DECLARE_FINAL_TYPE or G_DECLARE_DERIVABLE_TYPE
> for the USE(GTK4) case, so we have a path to eventually removing the
> boilerplate 5-10 years from now when dropping GTK 3 support. We can also
> more aggressively remove all deprecated APIs from the USE(GTK4) case.

The plan is to remove all deprecated APIs for GTK4 in any case.

> And we
> can add more class struct padding to the types that remain derivable, most
> urgently to WebKitWebView. (It would be a shame to release the new GTK 4 ABI
> with only a single byte of padding in the WebKitWebView class struct.)

That's also the case, no matter how we do it, we won't reuse the same header in those cases.

> I think the main challenge in supporting different APIs is gtk-doc, but
> gtk-doc looks at the source files, not the header files.

It looks at headers 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/20200615/5444425b/attachment.htm>