C API for libcef_wrapper utility classes

Think CEF could benefit from a new feature or capability? Discuss CEF feature requests here.

C API for libcef_wrapper utility classes

Postby tml » Sun Nov 19, 2017 10:37 am

There are a couple of classes in libcef_wrapper which are implemented in C++ and are only accessible by consuming the libcef_dll_wrapper library. I'd like to be able to provide some of these utilities in a companion library to CEF.swift but, as the C++ interop is nonexistent in Swift, I'd need a C API for that (or I'd have to reimplement everything but that's out of scope).

I set out to implement a bridge that closely mimics how the CEF C API is bridged to C++ using the CefCToCpp and CefCppToC adapters. I created a C interface for e.g. CefMessageRouterRendererSide and a corresponding CefMessageRouterRendererSideCppToC implementation. There were however 2 issues that I had to fix:

1. I had to manually add a new WT_MESSAGE_ROUTER_RENDERER_SIDE value in wrapper_types.h
2. there is a mismatch between base::RefCountedThreadSafe (base of CefMessageRouterRendererSide) and CefBaseRefCounted (expected by CefCppToCRefCounted) as the Release() in the former is void while in the latter returns a bool. This caused template instatiation problems in CefCppToCRefCounted which I rigged by making UnderlyingRelease() void (return value was not used anyway).

Now, with these hacks in place the code compiles. I could go ahead and patch each CEF release as it comes out, but I think these changes could as well be applied to the main codebase. Namely:

1. adding a CefWrapperType value for any potentially bridgeable utility class
2. making CefCppToCRefCounted::UnderlyingRelease() void by discarding the return value from the Release() of the wrapped struct (as I said, the result of UnderlyingRelease() is not used anywhere).

This would make it possible to write C++ => C bridges for the mentioned classes. What do you think? If you agree with the general direction, I can submit a PR.
tml
Techie
 
Posts: 11
Joined: Thu Jul 31, 2014 7:55 am

Re: C API for libcef_wrapper utility classes

Postby magreenblatt » Sun Nov 19, 2017 11:42 am

For #1 how about adding a WT_LAST at the end of the enumeration, and then you can use WT_LAST + X in your code. For #2 your proposed change sounds fine.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: C API for libcef_wrapper utility classes

Postby tml » Sun Nov 19, 2017 1:20 pm

I'm fine with the WT_LAST approach, although it requires a forced cast when assigning to kWrapperType. I'll submit a PR soon.

As for the C APIs, I can contribute those as well if there is interest.
tml
Techie
 
Posts: 11
Joined: Thu Jul 31, 2014 7:55 am

Re: C API for libcef_wrapper utility classes

Postby magreenblatt » Sun Nov 19, 2017 7:36 pm

Your creation of C++ to C wrappers for libcef_dll_wrapper classes is perhaps reasonable given your swift wrapper's requirements but not something that we would want for the core project. The C++ implementations in libcef_dll_wrapper were placed there intentionally (they all use lower-level APIs already exposed by libcef). Some argument could be made for moving those C++ APIs into libcef if a C API was desireable for them in the core project, in which case the translator tool could generate the wrapper bindings automatically. The counter-argument is that the translation layer adds unnecessary overhead and perhaps other non-C++ languages could implement similar functionality in a more language-efficient/appropriate manner.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: C API for libcef_wrapper utility classes

Postby tml » Mon Nov 20, 2017 3:32 pm

I didn't mean to move the utility classes from the wrapper to the core lib. I'm just saying that, since I'm going to create a C API for some of those classes, I'm happy to contribute the bridging API and implementation into the CEF repository if you consider that appropriate. It could live on as a supplement to libcef_dll_wrapper, somewhat similarly to the core lib CAPI that is not the main interface but e.g. it alone made CEF.swift possible. Otherwise, no hard feelings, I'm fine with having it just in my project.
tml
Techie
 
Posts: 11
Joined: Thu Jul 31, 2014 7:55 am


Return to Feature Request Forum

Who is online

Users browsing this forum: No registered users and 12 guests