[platform-swt-dev] Chromium Browser

Discussion:

Guillermo Zunino

2017-11-12 22:49:12 UTC

Hi SWT Team!

I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during EclipseCon
Europe and asked me to write to the list. As you show willingness to
integrate the work in SWT, I'm writing to start discussing some of the
challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
https://medium.com/@mikael.barbero/chromium-eclipse-swt-integration-c61f416e97d1
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
possible):
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing

I describe below an overview and some of the points which I believe are the
biggest challenges.
Please ask if you want to know more about the selected tools and libraries,
or any other technical or non technical question.

*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper executable
required by CEF to spawn subprocess (CEF is multiprocess).

*- Binaries (and sizes):*

- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely required
(depending on browser usage), or could be delivered as separate fragments,
for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF

Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of the
build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.

- Build time dependencies

- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit

- Run time dependencies and licenses:

- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we are
depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from crates.io
to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)

- CEF lifecycle

- The first created Chromium browser extracts the binaries to ~/.swtcef
(similar to how swt does) and initializes CEF (renderer and gpu subprocess
are started). CEF has a memory footprint of ~20MB per process plus the web
pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.

- CEF versioning

- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).

- Integration

- I think the best developer experience, would be to provide this as a
new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned to
be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to be
download during build (http://opensource.spotify.com/cefbuilds/index.html
is the "official" release channel of CEF and they keep all historical
versions).

- Distribution

- Distribution wise I envision this as separate .jars from main swt .jar
given the size of the binaries and the third party dependencies. The java
implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users wishing
to use Chromium should opt-in for it, instead of making everyone pay the
size and third party dependencies cost.

As said the idea here is to trigger discussion and know your opinions to
move forward.

Best regards, and sorry for the large email!

--
Guillermo Zunino
***@gmail.com

Thomas Singer

2017-11-14 07:07:13 UTC

Permalink

so adding 150MB of CEF binaries to ensure that our users will get the
exact behavior we expect from local testing is a huge win.

For us who don't use the Browser control it would be a showstopper to
add 150MB of additional (for us) useless stuff. So at least make this
optional - or even better - a separate library (not part of SWT).

--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog

As an app developer, the big problem with Webkit/XULRunner is that it's
impossible to know if our app will run correctly on the user's machine,
because we can't control what browser versions will be present. Our users
basically don't care about disk space - look at the size of any iPhone app
- so adding 150MB of CEF binaries to ensure that our users will get the
exact behavior we expect from local testing is a huge win.
https://trends.google.com/trends/explore?date=today%205-y&q=electron%20js,xulrunner
We don't use SWT browser, because it causes too many bug reports for us.
Shipping a known version of CEF will allow us to use cutting-edge features
- WebGL, WASM, etc. - without testing for broad cross-browser compat.
ᐧ
Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043 (cell)
888-513-6870 (fax)
340 S Lemon Ave #3433, Walnut, CA 91789
On Mon, Nov 13, 2017 at 12:45 PM, Lakshmi P Shanmugam <

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

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
bero/chromium-eclipse-swt-integration-c61f416e97d1
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
possible): https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_
PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html
<http://opensource.spotify.com/cefbuilds/index.html>. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as
a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned
to be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (http://opensource.spotify.com
/cefbuilds/index.html is the "official" release channel of CEF and
they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Aleksandar Kurtakov

2017-11-14 11:24:47 UTC

Permalink

Post by Guillermo Zunino
Hi SWT Team!

Hi Guillermo,
My main concern is maintenance, so whenever I ask a question don't
take it as advertisement of one approach or bashing another - it's
simply trying to keep consistency in the project so if/when this
enters SWT it's smth maintainable in the long term and not one time
thing which can't be easily changed and adopted to new CEF or
toolchain.... And browsers are known to be especially bad in stability
so my concerns are just bigger for anything related to them.
See inlined comments for details.

Post by Guillermo Zunino
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com) and
project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during EclipseCon
Europe and asked me to write to the list. As you show willingness to
integrate the work in SWT, I'm writing to start discussing some of the
challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are the
biggest challenges.
Please ask if you want to know more about the selected tools and libraries,
or any other technical or non technical question.
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.

I fully understand the preference to use JNR over plain JNI. But SWT
has a design requirement that it should be usable as standalone
graphics library for apps without enforcing any other dependencies.
While this can be discussed it also opens the question of using
multiple means to achieve similar results in one project. Additionally
SWT has a generator for JNI which hides a lot of the JNI complexity so
it's by no means like working with plain JNI. To the state people
extracted in standalone one see http://fusesource.github.io/hawtjni/
for details. Have you tried this approach? If yes, what were the
showstoppers. I don't imply it's better or even comparable to JNR but
for the means of the bindings as used in SWT it's quite sufficient.

Post by Guillermo Zunino
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper executable
required by CEF to spawn subprocess (CEF is multiprocess).

This is yet another concern for me. Rust has it's advantages but this
means current maintainers to learn one more language, deal with yet
another buildsystem(cargo), maintain yet another toolchain on all the
different platforms for the native builders and etc. And this
toolchain is evolving quite fast now IIRC. So keeping up with that
will be constant drain of resources. Do you plan on maintaining it in
the long term?
While trying compiling https://github.com/maketechnology/cefrust I
noticed a real showstopper from Linux POV. It compiles against GTK2
while SWT by default uses GTK3 and there is noone supporting GTK2
port. Mixing GTK 2 and 3 in the same app eventually leads to crashes.
Chrome(ium) has GTK3 port since 59.x why is it not used? I would guess
there are reasons for that but GTK2 is on it's path out of SWT so
adding a module with hard dependency on it seems a no-go.

Post by Guillermo Zunino
cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely required
(depending on browser usage), or could be delivered as separate fragments,
for example devtools (5MB) and cef_extensions (3,5MB)
cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo
(https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of the
build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.

These sizes are really huge so they can't be shipped as part of swt.
There must be some way to ship it separately as an optional part of
SWT. Having part of it in SWT with some clever mechanics to redirect
work to a fragment seems the likely way to do it.

Post by Guillermo Zunino
- Build time dependencies
Rust (used to code and build the native lib and helper)
This is actually not required during the bundle and fragments build, as the
shared libraries are part of the git repo.

Even if part of the repo there is a certain group of contributors that
build Eclipse SDK from source incl. the native parts and the ease of
setting up for this group is always important.

Post by Guillermo Zunino
Gradle (to automate the many build steps)

Certain part of your gradle script would have to be rewritten in maven
way to integrate with existing swt build system.

Post by Guillermo Zunino
Tycho (to build the bundle, fragments and p2 repo)
Jboss Reddeer (or SWT Bot) for testing
JUnit
SWT
JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we are
depending on latest)

That would require CQ and Orbit build at some point if this is a must
have, although I would prefer to not ship jnr with swt.

Post by Guillermo Zunino
ASM (BSD) (already in Orbit, existing version should work)

By exisging version do you mean 6.0 (as this is the one the eclipse
platform dev stream uses)?

Post by Guillermo Zunino
CEF (BSD) (bundled in our fragments)
Native libs (coded in Rust, we use some third party libs from crates.io to
develop it)
rust std lib (MIT/Apache-2.0)
libc (MIT/Apache-2.0)
X11 (CC0-1.0)
nix (MIT)
winapi/user32 (MIT)
cocoa (MIT / Apache-2.0)

these shouldn't be problematic from legal POV but they will require
CQs too. These are all linked in the same library, right?

Post by Guillermo Zunino
- CEF lifecycle
The first created Chromium browser extracts the binaries to ~/.swtcef
(similar to how swt does) and initializes CEF (renderer and gpu subprocess
are started). CEF has a memory footprint of ~20MB per process plus the web
pages.
A new subprocess is started for each different domain url.
CEF is shutdown using a java shutdown hook or explicitly by the client.
Can't be shutdown after the last browser is closed, due it doesn't support
reinitialization. This one is tricky, because shutdown is not a SWT Browser
API, and CEF shutdown must be called in the main thread. The java hook is
called too late sometimes. For eclipse rcp, is better to explicitly call
shutdown on app exit hook.
- CEF versioning
Currently we are targeting a single CEF/Chromium version, 59 and should be
able to update to 60, 61 and 62 without major issues based on our analysis.
And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a single p2
repo.
But I see somewhere in the future that we may be forced to support multiple
CEF versions and build CEF ourself. For example if CEF drops GTK2 support,
we may have to provide separate CEF binaries (maybe targeting different CEF
versions also depending on API breakage) compatible with gtk2 and gtk3.
Similar could happen when Wayland support lands on Chromium and CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).

IMHO, providing GTK3 only is the way to go as GTK2 will soon be dead
from SWT POV. So even is Chromium has GTK3 support CEF still not has
it? Am I reading this well? With GTK3 providing switchable backends
(x11 or wayland) SWT has no issues with Wayland or X11 other than the
places where the swt code is using x11 api directly.

Post by Guillermo Zunino
- Integration
I think the best developer experience, would be to provide this as a new
SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned to be
implemented and tested using the existing SWT browser test suite.
The small integration libs can be put into eclipse.platform.swt.binaries.git
repo maybe.

How small are they?
In order for integration libs to enter swt.binaries we must know that
producing them is properly hooked in the existing build system
including needed toolchains available on build servers for
consistency of the builds.

Post by Guillermo Zunino
Given the size of CEF binaries probably they should be continue to be
download during build (http://opensource.spotify.com/cefbuilds/index.html is
the "official" release channel of CEF and they keep all historical
versions).

That would be a legal issue for SWT as we will need IP team to approve
every version we use.

Post by Guillermo Zunino
- Distribution
Distribution wise I envision this as separate .jars from main swt .jar given
the size of the binaries and the third party dependencies. The java
implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users wishing to
use Chromium should opt-in for it, instead of making everyone pay the size
and third party dependencies cost.

I like the approach of separate download, the usual approach is to
fallback to provide maximum feature to users when possible. E.g. when
one requests SWT.CHROMIUM Browser and the fragment is not availabla a
warning should be logged in some way but the app shoud not fail but
rather the OS browser will be instantiated and returned.

Post by Guillermo Zunino
As said the idea here is to trigger discussion and know your opinions to
move forward.

Have you tackled the hard features like Java<->JS interaction? As we
are in the process of migrating to Webkit2 API it's these features
that takes times more time than the initial port to just embed the
html renderer. I'm interested in seeing a list of missing features(API
not implemented) to get a feeling of how featurefull the port is.

Post by Guillermo Zunino
Best regards, and sorry for the large email!
--
Guillermo Zunino
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
Alexander Kurtakov
Red Hat Eclipse Team

Guillermo Zunino

2017-11-14 16:17:48 UTC

Permalink

Hi Alexander,

Post by Guillermo Zunino
Hi SWT Team!

Post by Guillermo Zunino
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)

and

Post by Guillermo Zunino
project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during

EclipseCon

Post by Guillermo Zunino
Europe and asked me to write to the list. As you show willingness to
integrate the work in SWT, I'm writing to start discussing some of the
challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if

https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing

Post by Guillermo Zunino
I describe below an overview and some of the points which I believe are

the

Post by Guillermo Zunino
biggest challenges.
Please ask if you want to know more about the selected tools and

libraries,

Post by Guillermo Zunino
or any other technical or non technical question.
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And

this

Post by Guillermo Zunino
native layer talks to CEF framework C APIs.

benefits of JNI without the manual efforts to implement it.
When we started with the project we looked at previous attempts to bring
cef to java and identified as a source of failure the difficulty to
maintain and build the C binding code (and C glue code also). Even if jni
portions are auto generated they still need to be build on each platform.
Removing this extra build step and removing C form the equation (see
rationale about rust also) reduces the complexity on maintaining and
updating the code to to new cef versions.
Choosing JNR was a deliverable decision at that time because looking at
previous attempts we had the goal to simplify maintenance and updating for
java developers. And together with the usage of rust it meant that we could
completely eliminate the need to build C code and install C toolchains.
We are also autogenerating CEF JNR binding clases that are used from java.
With that said, there is no technical impediment to use SWT JNI generator.

Post by Guillermo Zunino
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper

executable

Post by Guillermo Zunino
required by CEF to spawn subprocess (CEF is multiprocess).

I understand the concerns here.
It's true that rust evolves quickly but old toolchains are available and we
don't really require to be on latest, we can stick to a stable version for
long time probably.
We (http://wemaketechnology.com) plan to maintain this effort in the long
term due is a key technology for us.
The choose for Rust is aligned to the choose of JNR, simplify maintenance
and cef updates for java developers. Setting up rust toolchain is
infinitely simpler than C (rustup and your are ready to go), and provides a
consistent environment, dependencies and builds across platforms.
From the code perspective, even if java/native binding portions are auto
generated at build time (jni) or runtime (jnr) there is a considerable
amount of code than needs to be written at the native side, and those
portions are the ones that are most difficult. C is specially bad at
pushing errors to runtime while rust does a great job to move those errors
to build time, which means less bugs and better memory management. When we
started we evaluated doing the native side on C, on Go and on Rust, and
Rust was the clear winner. It really simplifies things at the native side,
and also allows us to remove C completely which was the biggest problem
with existing cef<>java solutions. In general we saw that Java developers
where much more comfortable with rust than C.

While trying compiling https://github.com/maketechnology/cefrust I
noticed a real showstopper from Linux POV. It compiles against GTK2
while SWT by default uses GTK3 and there is noone supporting GTK2
port. Mixing GTK 2 and 3 in the same app eventually leads to crashes.
Chrome(ium) has GTK3 port since 59.x why is it not used? I would guess
there are reasons for that but GTK2 is on it's path out of SWT so
adding a module with hard dependency on it seems a no-go.

Chromium and CEF supports GTK3, but CEF "official" builds have GTK2 enabled
by default for now. It will switch to GTK3 eventually. Meanwhile CEF can be
build with GTK3 without problems.
I think the port is linking to GTK2, just because we were using prebuilt
cef binaries, but should be fairly easy to move it to GTK3. I think we are
just calling 2 APIs from GTK, and those exists on gtk2 and 3.

fragments,

Post by Guillermo Zunino
for example devtools (5MB) and cef_extensions (3,5MB)
cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo
(https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of

the

Post by Guillermo Zunino
build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.

I agree.

Post by Guillermo Zunino
- Build time dependencies
Rust (used to code and build the native lib and helper)
This is actually not required during the bundle and fragments build, as

the

Post by Guillermo Zunino
shared libraries are part of the git repo.

Even if part of the repo there is a certain group of contributors that
build Eclipse SDK from source incl. the native parts and the ease of
setting up for this group is always important.

Sure, the rust code is super easy to build (cargo build) and that's it,
although the gradle build takes care of copying things to the correct
places and so.
That code should also be moved together with the java code. Currently is in
a separate git repo (just personal preference), but could be put in same
git repo also.

Post by Guillermo Zunino
Gradle (to automate the many build steps)

Certain part of your gradle script would have to be rewritten in maven
way to integrate with existing swt build system.

The gradle scripts mainly takes care of downloading things, unzipping and
copying files to corresponding places and invoking cargo and maven. It uses
gradle wrapper so it doesn't require gradle to be installed. I imagine it
can be ported to mvn, but gradle is good for scripting while mvn is not.

That would require CQ and Orbit build at some point if this is a must
have, although I would prefer to not ship jnr with swt.

Agree, I think SWT should remain free of third party dependencies. But
maybe SWT-Chromium could be a separate optional library that has
dependencies, and users and app developers can opt-in for those.

Post by Guillermo Zunino
ASM (BSD) (already in Orbit, existing version should work)

By exisging version do you mean 6.0 (as this is the one the eclipse
platform dev stream uses)?

ASM is used by JNR. These are asm requirements:
org.objectweb.asm.analysis;bundle-version="5.0.3";
org.objectweb.asm.commons;bundle-version="5.0.3";
org.objectweb.asm.tree;bundle-version="5.0.3";
org.objectweb.asm.util;bundle-version="5.0.3";

I couldn't find 6.0 on Orbit, I found 5.2 and did a quick test and seems to
be fine.

Post by Guillermo Zunino
CEF (BSD) (bundled in our fragments)
Native libs (coded in Rust, we use some third party libs from crates.io

Post by Guillermo Zunino
develop it)
rust std lib (MIT/Apache-2.0)
libc (MIT/Apache-2.0)
X11 (CC0-1.0)
nix (MIT)
winapi/user32 (MIT)
cocoa (MIT / Apache-2.0)

these shouldn't be problematic from legal POV but they will require
CQs too. These are all linked in the same library, right?

Yes, those are dynamically linked in our native shared library. Those
crates only provide the rust binding to the C apis of those shared
libraries. Except for the first two, the others may have 2/3 methods beings
used, so could be removed easily by proving our own binding just to the
used functions.
And X11 should probably be removed entirely and replaced by Gtk calls
directly.

Post by Guillermo Zunino
- CEF lifecycle
The first created Chromium browser extracts the binaries to ~/.swtcef
(similar to how swt does) and initializes CEF (renderer and gpu

subprocess

Post by Guillermo Zunino
are started). CEF has a memory footprint of ~20MB per process plus the

web

Post by Guillermo Zunino
pages.
A new subprocess is started for each different domain url.
CEF is shutdown using a java shutdown hook or explicitly by the client.
Can't be shutdown after the last browser is closed, due it doesn't

support

Post by Guillermo Zunino
reinitialization. This one is tricky, because shutdown is not a SWT

Browser

Post by Guillermo Zunino
API, and CEF shutdown must be called in the main thread. The java hook is
called too late sometimes. For eclipse rcp, is better to explicitly call
shutdown on app exit hook.
- CEF versioning
Currently we are targeting a single CEF/Chromium version, 59 and should

Post by Guillermo Zunino
able to update to 60, 61 and 62 without major issues based on our

analysis.

Post by Guillermo Zunino
And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a

single p2

Post by Guillermo Zunino
repo.
But I see somewhere in the future that we may be forced to support

multiple

Post by Guillermo Zunino
CEF versions and build CEF ourself. For example if CEF drops GTK2

support,

Post by Guillermo Zunino
we may have to provide separate CEF binaries (maybe targeting different

CEF

Post by Guillermo Zunino
versions also depending on API breakage) compatible with gtk2 and gtk3.
Similar could happen when Wayland support lands on Chromium and CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).

CEF does support GTK3, but the builds are GTK2 enabled by default.
I partially agree with this, the port should align to SWT plans. But many
linux systems still use GTK2. I believe SWT provide both versions GTK2 and
3. Is this going to change? Will SWT continue to work on GTK2 only systems?

eclipse.platform.swt.binaries.git

Post by Guillermo Zunino
repo maybe.

cefrustlib (.so|.dll|.dylib) ~2MB
cefrust_subp (.exe) ~0.5MB
If we do some size optimizations I think they would be cut in half at least.
Building those is fully automated with cargo (requires rust toolchain and
libcef present to link against). Currenlty gradle script takes care of this.

Post by Guillermo Zunino
Given the size of CEF binaries probably they should be continue to be
download during build (

http://opensource.spotify.com/cefbuilds/index.html is

Post by Guillermo Zunino
the "official" release channel of CEF and they keep all historical
versions).

That would be a legal issue for SWT as we will need IP team to approve
every version we use.

Is it the same if we build our own CEF binaries, right?

Post by Guillermo Zunino
- Distribution
Distribution wise I envision this as separate .jars from main swt .jar

given

Post by Guillermo Zunino
the size of the binaries and the third party dependencies. The java
implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the

existence

Post by Guillermo Zunino
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users wishing

Post by Guillermo Zunino
use Chromium should opt-in for it, instead of making everyone pay the

size

Post by Guillermo Zunino
and third party dependencies cost.

Post by Guillermo Zunino
As said the idea here is to trigger discussion and know your opinions to
move forward.

The port is by no means complete! It lacks all the browser features now...
Currently it only loads urls and no much more (although all html5 features
are working even opengl and hardware acceleration). But we have a solid
plan and (non written) design to implement all those features. Goal is to
be 100% SWT Browser API compliance, so for app developers, switching from
SWT.WEBKIT to SWT.CHROMIUM just work. We already evaluated the more
difficult ones like java<>js and we know how to tackle them based on cef
apis and so. We also did some proof of concepts of those ideas and we don't
see major blockers so far.
I wanted to start interacting with SWT team early in this process to see if
the contribution to SWT will be possible or not, and if we need to plan or
make technical changes in the way, but this is by no means ready to be
integrated. Sorry if I gave a wrong impression here.

Thank you very much for all the given concerns and feedback!

from

Post by Guillermo Zunino
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
Guillermo Zunino
***@gmail.com

Ivan Ooi

2018-01-11 07:51:52 UTC

Permalink

Hi,

As a developer, we should responsible on the libraries that our app
required. Not user.
Nice if Chromium can act like an optional library. We include that if we
need so.

Can't wait to get the Chromium for SWT. as our app some part will be web
base.
Best Regards,
Ivan

Post by Guillermo Zunino
Hi Alexander,

Post by Guillermo Zunino
Hi SWT Team!

Post by Guillermo Zunino
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)

and

Post by Guillermo Zunino
project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during

EclipseCon

integration-c61f416e97d1

Post by Guillermo Zunino
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_

PBnnBX8SFhgwIJPv7lg/edit?usp=sharing

Post by Guillermo Zunino
I describe below an overview and some of the points which I believe are

the

Post by Guillermo Zunino
biggest challenges.
Please ask if you want to know more about the selected tools and

libraries,

small

Post by Guillermo Zunino
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And

this

Post by Guillermo Zunino
native layer talks to CEF framework C APIs.

Post by Guillermo Zunino
There are 3 bundle fragments which provide the binaries for each

platform

Post by Guillermo Zunino
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper

executable

Post by Guillermo Zunino
required by CEF to spawn subprocess (CEF is multiprocess).

I understand the concerns here.
It's true that rust evolves quickly but old toolchains are available and
we don't really require to be on latest, we can stick to a stable version
for long time probably.
We (http://wemaketechnology.com) plan to maintain this effort in the long
term due is a key technology for us.
The choose for Rust is aligned to the choose of JNR, simplify maintenance
and cef updates for java developers. Setting up rust toolchain is
infinitely simpler than C (rustup and your are ready to go), and provides a
consistent environment, dependencies and builds across platforms.
From the code perspective, even if java/native binding portions are auto
generated at build time (jni) or runtime (jnr) there is a considerable
amount of code than needs to be written at the native side, and those
portions are the ones that are most difficult. C is specially bad at
pushing errors to runtime while rust does a great job to move those errors
to build time, which means less bugs and better memory management. When we
started we evaluated doing the native side on C, on Go and on Rust, and
Rust was the clear winner. It really simplifies things at the native side,
and also allows us to remove C completely which was the biggest problem
with existing cef<>java solutions. In general we saw that Java developers
where much more comfortable with rust than C.

Chromium and CEF supports GTK3, but CEF "official" builds have GTK2
enabled by default for now. It will switch to GTK3 eventually. Meanwhile
CEF can be build with GTK3 without problems.
I think the port is linking to GTK2, just because we were using prebuilt
cef binaries, but should be fairly easy to move it to GTK3. I think we are
just calling 2 APIs from GTK, and those exists on gtk2 and 3.

fragments,

the

I agree.

Post by Guillermo Zunino
- Build time dependencies
Rust (used to code and build the native lib and helper)
This is actually not required during the bundle and fragments build, as

the

Post by Guillermo Zunino
shared libraries are part of the git repo.

Even if part of the repo there is a certain group of contributors that
build Eclipse SDK from source incl. the native parts and the ease of
setting up for this group is always important.

Sure, the rust code is super easy to build (cargo build) and that's it,
although the gradle build takes care of copying things to the correct
places and so.
That code should also be moved together with the java code. Currently is
in a separate git repo (just personal preference), but could be put in same
git repo also.

Post by Guillermo Zunino
Gradle (to automate the many build steps)

Certain part of your gradle script would have to be rewritten in maven
way to integrate with existing swt build system.

That would require CQ and Orbit build at some point if this is a must
have, although I would prefer to not ship jnr with swt.

Post by Guillermo Zunino
ASM (BSD) (already in Orbit, existing version should work)

By exisging version do you mean 6.0 (as this is the one the eclipse
platform dev stream uses)?

org.objectweb.asm.analysis;bundle-version="5.0.3";
org.objectweb.asm.commons;bundle-version="5.0.3";
org.objectweb.asm.tree;bundle-version="5.0.3";
org.objectweb.asm.util;bundle-version="5.0.3";
I couldn't find 6.0 on Orbit, I found 5.2 and did a quick test and seems
to be fine.

Post by Guillermo Zunino
CEF (BSD) (bundled in our fragments)
Native libs (coded in Rust, we use some third party libs from crates.io

Post by Guillermo Zunino
develop it)
rust std lib (MIT/Apache-2.0)
libc (MIT/Apache-2.0)
X11 (CC0-1.0)
nix (MIT)
winapi/user32 (MIT)
cocoa (MIT / Apache-2.0)

these shouldn't be problematic from legal POV but they will require
CQs too. These are all linked in the same library, right?

Post by Guillermo Zunino
- CEF lifecycle
The first created Chromium browser extracts the binaries to ~/.swtcef
(similar to how swt does) and initializes CEF (renderer and gpu

subprocess

Post by Guillermo Zunino
are started). CEF has a memory footprint of ~20MB per process plus the

web

support

Post by Guillermo Zunino
reinitialization. This one is tricky, because shutdown is not a SWT

Browser

Post by Guillermo Zunino
API, and CEF shutdown must be called in the main thread. The java hook

Post by Guillermo Zunino
called too late sometimes. For eclipse rcp, is better to explicitly call
shutdown on app exit hook.
- CEF versioning
Currently we are targeting a single CEF/Chromium version, 59 and should

Post by Guillermo Zunino
able to update to 60, 61 and 62 without major issues based on our

analysis.

Post by Guillermo Zunino
And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a

single p2

Post by Guillermo Zunino
repo.
But I see somewhere in the future that we may be forced to support

multiple

Post by Guillermo Zunino
CEF versions and build CEF ourself. For example if CEF drops GTK2

support,

Post by Guillermo Zunino
we may have to provide separate CEF binaries (maybe targeting different

CEF

Post by Guillermo Zunino
implemented and tested using the existing SWT browser test suite.
The small integration libs can be put into

eclipse.platform.swt.binaries.git

Post by Guillermo Zunino
repo maybe.

Post by Guillermo Zunino
Given the size of CEF binaries probably they should be continue to be
download during build (http://opensource.spotify.

com/cefbuilds/index.html is

Post by Guillermo Zunino
the "official" release channel of CEF and they keep all historical
versions).

That would be a legal issue for SWT as we will need IP team to approve
every version we use.

Is it the same if we build our own CEF binaries, right?

Post by Guillermo Zunino
- Distribution
Distribution wise I envision this as separate .jars from main swt .jar

given

for

Post by Guillermo Zunino
plain java apps, to include the desired .jar and for osgi apps to

include

Post by Guillermo Zunino
the specific fragment. The java implementation can check for the

existence

Post by Guillermo Zunino
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users wishing

Post by Guillermo Zunino
use Chromium should opt-in for it, instead of making everyone pay the

size

Post by Guillermo Zunino
and third party dependencies cost.

Post by Guillermo Zunino
As said the idea here is to trigger discussion and know your opinions to
move forward.

The port is by no means complete! It lacks all the browser features now...
Currently it only loads urls and no much more (although all html5 features
are working even opengl and hardware acceleration). But we have a solid
plan and (non written) design to implement all those features. Goal is to
be 100% SWT Browser API compliance, so for app developers, switching from
SWT.WEBKIT to SWT.CHROMIUM just work. We already evaluated the more
difficult ones like java<>js and we know how to tackle them based on cef
apis and so. We also did some proof of concepts of those ideas and we don't
see major blockers so far.
I wanted to start interacting with SWT team early in this process to see
if the contribution to SWT will be possible or not, and if we need to plan
or make technical changes in the way, but this is by no means ready to be
integrated. Sorry if I gave a wrong impression here.
Thank you very much for all the given concerns and feedback!

from

Post by Guillermo Zunino
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
Guillermo Zunino
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Ivan Ooi

2018-01-11 07:54:15 UTC

Permalink

for the donation support. Do you support PayPal?

that make thing much more easier.

Thanks

Post by Ivan Ooi
Hi,
As a developer, we should responsible on the libraries that our app
required. Not user.
Nice if Chromium can act like an optional library. We include that if we
need so.
Can't wait to get the Chromium for SWT. as our app some part will be web
base.
Best Regards,
Ivan

Post by Guillermo Zunino
Hi Alexander,

Post by Guillermo Zunino
Hi SWT Team!

Post by Guillermo Zunino
I'm Guillermo Zunino (from Make Technology,

http://wemaketechnology.com) and

Post by Guillermo Zunino
project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during

EclipseCon

gration-c61f416e97d1

Post by Guillermo Zunino
and here is more information of the background, design and original

plan

Post by Guillermo Zunino
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_

PBnnBX8SFhgwIJPv7lg/edit?usp=sharing

Post by Guillermo Zunino
I describe below an overview and some of the points which I believe

are the

Post by Guillermo Zunino
biggest challenges.
Please ask if you want to know more about the selected tools and

libraries,

small

Post by Guillermo Zunino
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And

this

Post by Guillermo Zunino
native layer talks to CEF framework C APIs.

Post by Guillermo Zunino
There are 3 bundle fragments which provide the binaries for each

platform

Post by Guillermo Zunino
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper

executable

Post by Guillermo Zunino
required by CEF to spawn subprocess (CEF is multiprocess).

I understand the concerns here.
It's true that rust evolves quickly but old toolchains are available and
we don't really require to be on latest, we can stick to a stable version
for long time probably.
We (http://wemaketechnology.com) plan to maintain this effort in the
long term due is a key technology for us.
The choose for Rust is aligned to the choose of JNR, simplify maintenance
and cef updates for java developers. Setting up rust toolchain is
infinitely simpler than C (rustup and your are ready to go), and provides a
consistent environment, dependencies and builds across platforms.
From the code perspective, even if java/native binding portions are auto
generated at build time (jni) or runtime (jnr) there is a considerable
amount of code than needs to be written at the native side, and those
portions are the ones that are most difficult. C is specially bad at
pushing errors to runtime while rust does a great job to move those errors
to build time, which means less bugs and better memory management. When we
started we evaluated doing the native side on C, on Go and on Rust, and
Rust was the clear winner. It really simplifies things at the native side,
and also allows us to remove C completely which was the biggest problem
with existing cef<>java solutions. In general we saw that Java developers
where much more comfortable with rust than C.

Chromium and CEF supports GTK3, but CEF "official" builds have GTK2
enabled by default for now. It will switch to GTK3 eventually. Meanwhile
CEF can be build with GTK3 without problems.
I think the port is linking to GTK2, just because we were using prebuilt
cef binaries, but should be fairly easy to move it to GTK3. I think we are
just calling 2 APIs from GTK, and those exists on gtk2 and 3.

fragments,

of the

I agree.

Post by Guillermo Zunino
- Build time dependencies
Rust (used to code and build the native lib and helper)
This is actually not required during the bundle and fragments build,

as the

Post by Guillermo Zunino
shared libraries are part of the git repo.

Even if part of the repo there is a certain group of contributors that
build Eclipse SDK from source incl. the native parts and the ease of
setting up for this group is always important.

Sure, the rust code is super easy to build (cargo build) and that's it,
although the gradle build takes care of copying things to the correct
places and so.
That code should also be moved together with the java code. Currently is
in a separate git repo (just personal preference), but could be put in same
git repo also.

Post by Guillermo Zunino
Gradle (to automate the many build steps)

Certain part of your gradle script would have to be rewritten in maven
way to integrate with existing swt build system.

That would require CQ and Orbit build at some point if this is a must
have, although I would prefer to not ship jnr with swt.

Post by Guillermo Zunino
ASM (BSD) (already in Orbit, existing version should work)

By exisging version do you mean 6.0 (as this is the one the eclipse
platform dev stream uses)?

Post by Guillermo Zunino
CEF (BSD) (bundled in our fragments)
Native libs (coded in Rust, we use some third party libs from

crates.io to

Post by Guillermo Zunino
develop it)
rust std lib (MIT/Apache-2.0)
libc (MIT/Apache-2.0)
X11 (CC0-1.0)
nix (MIT)
winapi/user32 (MIT)
cocoa (MIT / Apache-2.0)

these shouldn't be problematic from legal POV but they will require
CQs too. These are all linked in the same library, right?

Post by Guillermo Zunino
- CEF lifecycle
The first created Chromium browser extracts the binaries to ~/.swtcef
(similar to how swt does) and initializes CEF (renderer and gpu

subprocess

Post by Guillermo Zunino
are started). CEF has a memory footprint of ~20MB per process plus the

web

support

Post by Guillermo Zunino
reinitialization. This one is tricky, because shutdown is not a SWT

Browser

Post by Guillermo Zunino
API, and CEF shutdown must be called in the main thread. The java hook

Post by Guillermo Zunino
called too late sometimes. For eclipse rcp, is better to explicitly

call

Post by Guillermo Zunino
shutdown on app exit hook.
- CEF versioning
Currently we are targeting a single CEF/Chromium version, 59 and

should be

Post by Guillermo Zunino
able to update to 60, 61 and 62 without major issues based on our

analysis.

Post by Guillermo Zunino
And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a

single p2

Post by Guillermo Zunino
repo.
But I see somewhere in the future that we may be forced to support

multiple

Post by Guillermo Zunino
CEF versions and build CEF ourself. For example if CEF drops GTK2

support,

Post by Guillermo Zunino
we may have to provide separate CEF binaries (maybe targeting

different CEF

Post by Guillermo Zunino
- Integration
I think the best developer experience, would be to provide this as a

new

Post by Guillermo Zunino
SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned

to be

Post by Guillermo Zunino
implemented and tested using the existing SWT browser test suite.
The small integration libs can be put into

eclipse.platform.swt.binaries.git

Post by Guillermo Zunino
repo maybe.

Post by Guillermo Zunino
Given the size of CEF binaries probably they should be continue to be
download during build (http://opensource.spotify.com

/cefbuilds/index.html is

Post by Guillermo Zunino
the "official" release channel of CEF and they keep all historical
versions).

That would be a legal issue for SWT as we will need IP team to approve
every version we use.

Is it the same if we build our own CEF binaries, right?

Post by Guillermo Zunino
- Distribution
Distribution wise I envision this as separate .jars from main swt .jar

given

for

Post by Guillermo Zunino
plain java apps, to include the desired .jar and for osgi apps to

include

Post by Guillermo Zunino
the specific fragment. The java implementation can check for the

existence

Post by Guillermo Zunino
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users

wishing to

Post by Guillermo Zunino
use Chromium should opt-in for it, instead of making everyone pay the

size

Post by Guillermo Zunino
and third party dependencies cost.

Post by Guillermo Zunino
As said the idea here is to trigger discussion and know your opinions

Post by Guillermo Zunino
move forward.

The port is by no means complete! It lacks all the browser features
now... Currently it only loads urls and no much more (although all html5
features are working even opengl and hardware acceleration). But we have a
solid plan and (non written) design to implement all those features. Goal
is to be 100% SWT Browser API compliance, so for app developers, switching
from SWT.WEBKIT to SWT.CHROMIUM just work. We already evaluated the more
difficult ones like java<>js and we know how to tackle them based on cef
apis and so. We also did some proof of concepts of those ideas and we don't
see major blockers so far.
I wanted to start interacting with SWT team early in this process to see
if the contribution to SWT will be possible or not, and if we need to plan
or make technical changes in the way, but this is by no means ready to be
integrated. Sorry if I gave a wrong impression here.
Thank you very much for all the given concerns and feedback!

unsubscribe from

Post by Guillermo Zunino
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Guillermo Zunino

2018-01-18 17:43:16 UTC

Permalink

Hi Ivan, thanks for the feedback and interest.

You can donate using Eclipse's donation page (
https://www.eclipse.org/donate/) and to indicate it is made specifically
for this topic, simply send an email to Paul White (
***@eclipse-foundation.org) and he will âearmarkâ it in this manner.

Regards,

Post by Ivan Ooi
for the donation support. Do you support PayPal?
that make thing much more easier.
Thanks

Post by Guillermo Zunino
Hi Alexander,

Post by Guillermo Zunino
Hi SWT Team!

Post by Guillermo Zunino
I'm Guillermo Zunino (from Make Technology,

http://wemaketechnology.com) and

Post by Guillermo Zunino
project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during

EclipseCon

plan

Post by Guillermo Zunino
(although the idea now is to integrate it to SWT instead of nebula if

https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing

Post by Guillermo Zunino
I describe below an overview and some of the points which I believe

are the

Post by Guillermo Zunino
biggest challenges.
Please ask if you want to know more about the selected tools and

libraries,

small

Post by Guillermo Zunino
integration layer (native lib) using JNR-FFI (instead of JNA/JNI).

And this

Post by Guillermo Zunino
native layer talks to CEF framework C APIs.

Post by Guillermo Zunino
There are 3 bundle fragments which provide the binaries for each

platform

Post by Guillermo Zunino
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper

executable

Post by Guillermo Zunino
required by CEF to spawn subprocess (CEF is multiprocess).

I understand the concerns here.
It's true that rust evolves quickly but old toolchains are available and
we don't really require to be on latest, we can stick to a stable version
for long time probably.
We (http://wemaketechnology.com) plan to maintain this effort in the
long term due is a key technology for us.
The choose for Rust is aligned to the choose of JNR, simplify
maintenance and cef updates for java developers. Setting up rust toolchain
is infinitely simpler than C (rustup and your are ready to go), and
provides a consistent environment, dependencies and builds across platforms.
From the code perspective, even if java/native binding portions are auto
generated at build time (jni) or runtime (jnr) there is a considerable
amount of code than needs to be written at the native side, and those
portions are the ones that are most difficult. C is specially bad at
pushing errors to runtime while rust does a great job to move those errors
to build time, which means less bugs and better memory management. When we
started we evaluated doing the native side on C, on Go and on Rust, and
Rust was the clear winner. It really simplifies things at the native side,
and also allows us to remove C completely which was the biggest problem
with existing cef<>java solutions. In general we saw that Java developers
where much more comfortable with rust than C.

Chromium and CEF supports GTK3, but CEF "official" builds have GTK2
enabled by default for now. It will switch to GTK3 eventually. Meanwhile
CEF can be build with GTK3 without problems.
I think the port is linking to GTK2, just because we were using prebuilt
cef binaries, but should be fairly easy to move it to GTK3. I think we are
just calling 2 APIs from GTK, and those exists on gtk2 and 3.

fragments,

Post by Guillermo Zunino
for example devtools (5MB) and cef_extensions (3,5MB)
cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git

repository

Post by Guillermo Zunino
(using git lfs). The rust source code for those is in separate git

repo

Post by Guillermo Zunino
(https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part

of the

I agree.

Post by Guillermo Zunino
- Build time dependencies
Rust (used to code and build the native lib and helper)
This is actually not required during the bundle and fragments build,

as the

Post by Guillermo Zunino
shared libraries are part of the git repo.

Even if part of the repo there is a certain group of contributors that
build Eclipse SDK from source incl. the native parts and the ease of
setting up for this group is always important.

Sure, the rust code is super easy to build (cargo build) and that's it,
although the gradle build takes care of copying things to the correct
places and so.
That code should also be moved together with the java code. Currently is
in a separate git repo (just personal preference), but could be put in same
git repo also.

Post by Guillermo Zunino
Gradle (to automate the many build steps)

Certain part of your gradle script would have to be rewritten in maven
way to integrate with existing swt build system.

The gradle scripts mainly takes care of downloading things, unzipping
and copying files to corresponding places and invoking cargo and maven. It
uses gradle wrapper so it doesn't require gradle to be installed. I imagine
it can be ported to mvn, but gradle is good for scripting while mvn is not.

That would require CQ and Orbit build at some point if this is a must
have, although I would prefer to not ship jnr with swt.

Post by Guillermo Zunino
ASM (BSD) (already in Orbit, existing version should work)

By exisging version do you mean 6.0 (as this is the one the eclipse
platform dev stream uses)?

Post by Guillermo Zunino
CEF (BSD) (bundled in our fragments)
Native libs (coded in Rust, we use some third party libs from

crates.io to

Post by Guillermo Zunino
develop it)
rust std lib (MIT/Apache-2.0)
libc (MIT/Apache-2.0)
X11 (CC0-1.0)
nix (MIT)
winapi/user32 (MIT)
cocoa (MIT / Apache-2.0)

these shouldn't be problematic from legal POV but they will require
CQs too. These are all linked in the same library, right?

Post by Guillermo Zunino
- CEF lifecycle
The first created Chromium browser extracts the binaries to ~/.swtcef
(similar to how swt does) and initializes CEF (renderer and gpu

subprocess

Post by Guillermo Zunino
are started). CEF has a memory footprint of ~20MB per process plus

the web

Post by Guillermo Zunino
pages.
A new subprocess is started for each different domain url.
CEF is shutdown using a java shutdown hook or explicitly by the

client.

Post by Guillermo Zunino
Can't be shutdown after the last browser is closed, due it doesn't

support

Post by Guillermo Zunino
reinitialization. This one is tricky, because shutdown is not a SWT

Browser

Post by Guillermo Zunino
API, and CEF shutdown must be called in the main thread. The java

hook is

Post by Guillermo Zunino
called too late sometimes. For eclipse rcp, is better to explicitly

call

Post by Guillermo Zunino
shutdown on app exit hook.
- CEF versioning
Currently we are targeting a single CEF/Chromium version, 59 and

should be

Post by Guillermo Zunino
able to update to 60, 61 and 62 without major issues based on our

analysis.

Post by Guillermo Zunino
And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a

single p2

Post by Guillermo Zunino
repo.
But I see somewhere in the future that we may be forced to support

multiple

Post by Guillermo Zunino
CEF versions and build CEF ourself. For example if CEF drops GTK2

support,

Post by Guillermo Zunino
we may have to provide separate CEF binaries (maybe targeting

different CEF

Post by Guillermo Zunino
versions also depending on API breakage) compatible with gtk2 and

gtk3.

Post by Guillermo Zunino
Similar could happen when Wayland support lands on Chromium and CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).

CEF does support GTK3, but the builds are GTK2 enabled by default.
I partially agree with this, the port should align to SWT plans. But
many linux systems still use GTK2. I believe SWT provide both versions GTK2
and 3. Is this going to change? Will SWT continue to work on GTK2 only
systems?

Post by Guillermo Zunino
- Integration
I think the best developer experience, would be to provide this as a

new

Post by Guillermo Zunino
SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned

to be

Post by Guillermo Zunino
implemented and tested using the existing SWT browser test suite.
The small integration libs can be put into

eclipse.platform.swt.binaries.git

Post by Guillermo Zunino
repo maybe.

cefrustlib (.so|.dll|.dylib) ~2MB
cefrust_subp (.exe) ~0.5MB
If we do some size optimizations I think they would be cut in half at least.
Building those is fully automated with cargo (requires rust toolchain
and libcef present to link against). Currenlty gradle script takes care of
this.

Post by Guillermo Zunino
Given the size of CEF binaries probably they should be continue to be
download during build (

http://opensource.spotify.com/cefbuilds/index.html is

Post by Guillermo Zunino
the "official" release channel of CEF and they keep all historical
versions).

That would be a legal issue for SWT as we will need IP team to approve
every version we use.

Is it the same if we build our own CEF binaries, right?

Post by Guillermo Zunino
- Distribution
Distribution wise I envision this as separate .jars from main swt

.jar given

for

Post by Guillermo Zunino
plain java apps, to include the desired .jar and for osgi apps to

include

Post by Guillermo Zunino
the specific fragment. The java implementation can check for the

existence

Post by Guillermo Zunino
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users

wishing to

Post by Guillermo Zunino
use Chromium should opt-in for it, instead of making everyone pay the

size

Post by Guillermo Zunino
and third party dependencies cost.

Post by Guillermo Zunino
As said the idea here is to trigger discussion and know your opinions

Post by Guillermo Zunino
move forward.

The port is by no means complete! It lacks all the browser features
now... Currently it only loads urls and no much more (although all html5
features are working even opengl and hardware acceleration). But we have a
solid plan and (non written) design to implement all those features. Goal
is to be 100% SWT Browser API compliance, so for app developers, switching
from SWT.WEBKIT to SWT.CHROMIUM just work. We already evaluated the more
difficult ones like java<>js and we know how to tackle them based on cef
apis and so. We also did some proof of concepts of those ideas and we don't
see major blockers so far.
I wanted to start interacting with SWT team early in this process to see
if the contribution to SWT will be possible or not, and if we need to plan
or make technical changes in the way, but this is by no means ready to be
integrated. Sorry if I gave a wrong impression here.
Thank you very much for all the given concerns and feedback!

unsubscribe from

Post by Guillermo Zunino
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
Guillermo Zunino
***@gmail.com

Guillermo Zunino

2017-11-13 23:01:34 UTC

Permalink

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!

On Mon, Nov 13, 2017 at 5:45 PM Lakshmi P Shanmugam <

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as
a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned
to be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the "official"
release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Guillermo Zunino
***@gmail.com

Guillermo Zunino

2018-09-09 22:06:06 UTC

Permalink

Hi,

A new version of the Chromium Widget is available with most of the APIs
(except javascript)

Instructions and code here:
https://github.com/maketechnology/chromium.swt

And some discussion also here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405031

Cheers.

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during EclipseCon
Europe and asked me to write to the list. As you show willingness to
integrate the work in SWT, I'm writing to start discussing some of the
challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper executable
required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely required
(depending on browser usage), or could be delivered as separate fragments,
for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we are
depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as a
new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned to
be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the "official"
release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino

--
Guillermo Zunino
***@gmail.com

Guillermo Zunino

2018-10-08 00:39:53 UTC

Permalink

Hi SWT Team,

I'm writing about the Chromium browser implementation to bring some updates
on the development and start thinking the paths toward moving it to SWT
project.

The repository https://github.com/maketechnology/chromium.swt contains
latest code with most of APIs implemented, still some work required for
sync JS apis and gtk3.

Some highlighted changes were done since my first post, based on feedback
and to be more aligned with SWT:

- Native library code is part of the repo folder chromium-library/, with
readme and build instructions.
- Gradle is no longer used.
- No longer a separate widget, but a subclass of WebBrowser, to be used
with a new constant SWT.CHROMIUM. (Although some clases are copied from SWT
until it gets merged with minor change on BrowserFactory to allow
instantiation)
- Chromium implementation is a separate jar/fragment to not pollute SWT
with third party dependencies.
- We still use jnr/asm but those are now part of main eclipse repo now.
- Bundle fragments contains only our shared lib, and not the CEF
binaries. To reduce space and allow separate distribution of those.
- Fragments size is reduced to ~500KB
- CEF binaries can be pointed using the same SWT system property
mechanism.
- CEF binaries are provided as separate feature/fragments so we can
decide to make it part or not of SWT. If is not part of SWT, "Make
Technology" will provide ready to use binaries. Also app developers or
users can take care of making it available by their own means, and pointing
Chromium implementation to use those.
- Native code in rust is reduced to the bare minimum, with dependencies
removed and moving as much as possible code to java.
- Most SWT browser unit tests already passing.

Besides finishing the implementation, what things do you think should be
addressed before starting the contribution process.

Thanks in advance!

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during EclipseCon
Europe and asked me to write to the list. As you show willingness to
integrate the work in SWT, I'm writing to start discussing some of the
challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper executable
required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely required
(depending on browser usage), or could be delivered as separate fragments,
for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we are
depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as a
new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned to
be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the "official"
release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino

--
Guillermo Zunino
***@gmail.com

Lakshmi P Shanmugam

2018-10-09 17:44:48 UTC

Permalink

Hi Guillermo,

Thanks for the update!
We'll try out the code on Windows and Mac. We can further discuss on how to
integrate the feature with SWT after that. Please see the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405031 for further
comments/questions.

The GitHub page for the project mentions that it only works with GTK2 on
linux. This is a blocker for Linux support as SWT support for GTK2 has been
dropped in 4.9.
What is the plan to the support Linux-GTK3?

Regards,
Lakshmi

Post by Guillermo Zunino
Hi SWT Team,
I'm writing about the Chromium browser implementation to bring some
updates on the development and start thinking the paths toward moving it to
SWT project.
The repository https://github.com/maketechnology/chromium.swt contains
latest code with most of APIs implemented, still some work required for
sync JS apis and gtk3.
Some highlighted changes were done since my first post, based on feedback
- Native library code is part of the repo folder chromium-library/,
with readme and build instructions.
- Gradle is no longer used.
- No longer a separate widget, but a subclass of WebBrowser, to be
used with a new constant SWT.CHROMIUM. (Although some clases are copied
from SWT until it gets merged with minor change on BrowserFactory to allow
instantiation)
- Chromium implementation is a separate jar/fragment to not pollute
SWT with third party dependencies.
- We still use jnr/asm but those are now part of main eclipse repo now.
- Bundle fragments contains only our shared lib, and not the CEF
binaries. To reduce space and allow separate distribution of those.
- Fragments size is reduced to ~500KB
- CEF binaries can be pointed using the same SWT system property
mechanism.
- CEF binaries are provided as separate feature/fragments so we can
decide to make it part or not of SWT. If is not part of SWT, "Make
Technology" will provide ready to use binaries. Also app developers or
users can take care of making it available by their own means, and pointing
Chromium implementation to use those.
- Native code in rust is reduced to the bare minimum, with
dependencies removed and moving as much as possible code to java.
- Most SWT browser unit tests already passing.
Besides finishing the implementation, what things do you think should be
addressed before starting the contribution process.
Thanks in advance!

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as
a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned
to be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the "official"
release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino

--
*Regards,Lakshmi P Shanmugam*

Guillermo Zunino

2018-10-24 02:23:40 UTC

Permalink

Hi,

We need to create builds for GTK3, and remove a few x11 api calls. It
should be straightforward.

Thanks,

On Tue, Oct 9, 2018 at 2:45 PM Lakshmi P Shanmugam <

Hi Guillermo,
Thanks for the update!
We'll try out the code on Windows and Mac. We can further discuss on how
to integrate the feature with SWT after that. Please see the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405031 for further
comments/questions.
The GitHub page for the project mentions that it only works with GTK2 on
linux. This is a blocker for Linux support as SWT support for GTK2 has been
dropped in 4.9.
What is the plan to the support Linux-GTK3?
Regards,
Lakshmi

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each
platform (mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after
optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream
project decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as
a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned
to be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the "official"
release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino

--
Guillermo Zunino

_______________________________________________

Post by Guillermo Zunino
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
*Regards,Lakshmi P Shanmugam*
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

--
Guillermo Zunino
***@gmail.com

Guillermo Zunino

2018-10-29 19:01:40 UTC

Permalink

Hi all,

New code and binaries have been pushed, with all javascript apis
implemented and tests passing across win, linux (gtk2) and mac.

All apis should be complete now, with a few bugs reported in:

https://github.com/maketechnology/chromium.swt

Cheers

Post by Guillermo Zunino
Hi,
We need to create builds for GTK3, and remove a few x11 api calls. It
should be straightforward.
Thanks,
On Tue, Oct 9, 2018 at 2:45 PM Lakshmi P Shanmugam <

Hi Guillermo,
Thanks for the update!
We'll try out the code on Windows and Mac. We can further discuss on how
to integrate the feature with SWT after that. Please see the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405031 for further
comments/questions.
The GitHub page for the project mentions that it only works with GTK2 on
linux. This is a blocker for Linux support as SWT support for GTK2 has been
dropped in 4.9.
What is the plan to the support Linux-GTK3?
Regards,
Lakshmi

Post by Guillermo Zunino
Hi SWT Team,
I'm writing about the Chromium browser implementation to bring some
updates on the development and start thinking the paths toward moving it to
SWT project.
The repository https://github.com/maketechnology/chromium.swt contains
latest code with most of APIs implemented, still some work required for
sync JS apis and gtk3.
Some highlighted changes were done since my first post, based on
- Native library code is part of the repo folder chromium-library/,
with readme and build instructions.
- Gradle is no longer used.
- No longer a separate widget, but a subclass of WebBrowser, to be
used with a new constant SWT.CHROMIUM. (Although some clases are copied
from SWT until it gets merged with minor change on BrowserFactory to allow
instantiation)
- Chromium implementation is a separate jar/fragment to not pollute
SWT with third party dependencies.
- We still use jnr/asm but those are now part of main eclipse repo now.
- Bundle fragments contains only our shared lib, and not the CEF
binaries. To reduce space and allow separate distribution of those.
- Fragments size is reduced to ~500KB
- CEF binaries can be pointed using the same SWT system property
mechanism.
- CEF binaries are provided as separate feature/fragments so we can
decide to make it part or not of SWT. If is not part of SWT, "Make
Technology" will provide ready to use binaries. Also app developers or
users can take care of making it available by their own means, and pointing
Chromium implementation to use those.
- Native code in rust is reduced to the bare minimum, with
dependencies removed and moving as much as possible code to java.
- Most SWT browser unit tests already passing.
Besides finishing the implementation, what things do you think should be
addressed before starting the contribution process.
Thanks in advance!

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original
plan (although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each
platform (mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after
optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to
support multiple CEF versions and build CEF ourself. For example if CEF
drops GTK2 support, we may have to provide separate CEF binaries (maybe
targeting different CEF versions also depending on API breakage) compatible
with gtk2 and gtk3. Similar could happen when Wayland support lands on
Chromium and CEF.
Things are not so clear for me here as it depends on upstream
project decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this
as a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned
to be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue
to be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the
"official" release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions
to move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino

--
Guillermo Zunino

_______________________________________________

--
Guillermo Zunino

--
Guillermo Zunino
***@gmail.com

Guillermo Zunino

2018-11-30 07:03:45 UTC

Permalink

Hi all,

New code and binaries (0.7.0) have been pushed. Most of the issues reported
where fixed and also failing tests. Some minor updates to readme were
applied.

https://github.com/maketechnology/chromium.swt

Cheers

Post by Guillermo Zunino
Hi all,
New code and binaries have been pushed, with all javascript apis
implemented and tests passing across win, linux (gtk2) and mac.
https://github.com/maketechnology/chromium.swt
Cheers

Post by Guillermo Zunino
Hi,
We need to create builds for GTK3, and remove a few x11 api calls. It
should be straightforward.
Thanks,
On Tue, Oct 9, 2018 at 2:45 PM Lakshmi P Shanmugam <

Hi Guillermo,
Thanks for the update!
We'll try out the code on Windows and Mac. We can further discuss on how
to integrate the feature with SWT after that. Please see the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405031 for further
comments/questions.
The GitHub page for the project mentions that it only works with GTK2 on
linux. This is a blocker for Linux support as SWT support for GTK2 has been
dropped in 4.9.
What is the plan to the support Linux-GTK3?
Regards,
Lakshmi

Post by Guillermo Zunino
Hi SWT Team,
I'm writing about the Chromium browser implementation to bring some
updates on the development and start thinking the paths toward moving it to
SWT project.
The repository https://github.com/maketechnology/chromium.swt contains
latest code with most of APIs implemented, still some work required for
sync JS apis and gtk3.
Some highlighted changes were done since my first post, based on
- Native library code is part of the repo folder chromium-library/,
with readme and build instructions.
- Gradle is no longer used.
- No longer a separate widget, but a subclass of WebBrowser, to be
used with a new constant SWT.CHROMIUM. (Although some clases are copied
from SWT until it gets merged with minor change on BrowserFactory to allow
instantiation)
- Chromium implementation is a separate jar/fragment to not pollute
SWT with third party dependencies.
- We still use jnr/asm but those are now part of main eclipse repo now.
- Bundle fragments contains only our shared lib, and not the CEF
binaries. To reduce space and allow separate distribution of those.
- Fragments size is reduced to ~500KB
- CEF binaries can be pointed using the same SWT system property
mechanism.
- CEF binaries are provided as separate feature/fragments so we can
decide to make it part or not of SWT. If is not part of SWT, "Make
Technology" will provide ready to use binaries. Also app developers or
users can take care of making it available by their own means, and pointing
Chromium implementation to use those.
- Native code in rust is reduced to the bare minimum, with
dependencies removed and moving as much as possible code to java.
- Most SWT browser unit tests already passing.
Besides finishing the implementation, what things do you think should
be addressed before starting the contribution process.
Thanks in advance!

Post by Guillermo Zunino
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology,
http://wemaketechnology.com) and project
https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael
and here is more information of the background, design and original
plan (although the idea now is to integrate it to SWT instead of nebula if
https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe
are the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each
platform (mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after
optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git
repository (using git lfs). The rust source code for those is in separate
git repo (https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part
of the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to
support multiple CEF versions and build CEF ourself. For example if CEF
drops GTK2 support, we may have to provide separate CEF binaries (maybe
targeting different CEF versions also depending on API breakage) compatible
with gtk2 and gtk3. Similar could happen when Wayland support lands on
Chromium and CEF.
Things are not so clear for me here as it depends on upstream
project decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this
as a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is
planned to be implemented and tested using the existing SWT browser test
suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue
to be download during build (
http://opensource.spotify.com/cefbuilds/index.html is the
"official" release channel of CEF and they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main
swt .jar given the size of the binaries and the third party dependencies.
The java implementation could be part of main swt, and the native binaries
as separate .jars per platform (valid osgi fragments). This should allow
for plain java apps, to include the desired .jar and for osgi apps to
include the specific fragment. The java implementation can check for the
existence of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions
to move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino

--
Guillermo Zunino

_______________________________________________

--
Guillermo Zunino

--
Guillermo Zunino
***@gmail.com

Continue reading on narkive:

Search results for '[platform-swt-dev] Chromium Browser' (Questions and Answers)

replies

Is the Chromium browser dead on ubuntu?

started 2012-08-23 22:19:08 UTC

internet

replies

Where to get chromium browser for linux?