[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 #10 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(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. 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?)

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. 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.)

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

-- 
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/20200614/cbe01dc9/attachment-0001.htm>