Hi Lakshmi,
It could be possible to make it work in a similar way. Although I see the following problems:
- End user experience is impacted, because things don't work from start and requires extra manual steps. These problems already happen today with Webkit and XULRunner.
- App developer cannot ensure browser will work due depends on user actions.
- For Webkit and XULRunner there are (or there were) native OS packages available to install from package managers. There aren't for CEF. The only ready to use binaries are from opensource.spotify.com/cefbuilds/index.html as zips. And users should be instructed to download an specific version and distribution and extracted to the correct folder. Even more they will be downloading much more than required by SWT-Chromium integration, because even the minimal distribution contains lot of things not required at runtime. Downloading of a different version than required will result on runtime errors.
- Currently we are "tweaking" the CEF shared lib during fragments build to fix linking paths (rpath) and to work correctly on old linuxes (w/glibc<2.12) and to strip debug symbols. These steps are not entirely required, but provide a greater compatibility.
So, yes, it could be done, none of the items above are impediments.
But the question is do we really want to go that path?
Thanks!
Hi Guillermo,
Thank you for the detailed write-up!
My question is regarding the integration and distribution. With the Webkit and XULRunner browser integration, SWT doesn't distribute the third-party libraries (Webkit/XULRunner libraries). We require the user to have the required libraries installed on the system and SWT only provides the integration library which is required to talk to the third-party libraries.
Can the Chromium integration be made to work in a similar way, where we require the user to have CEF downloaded/installed on the system and the SWT-Chromium integration library can work with it?
Thanks & Regards,
Lakshmi P Shanmugam