Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor JCEF to match CEF structure and functionality #55

Closed
GoogleCodeExporter opened this issue Feb 18, 2016 · 5 comments
Closed

Refactor JCEF to match CEF structure and functionality #55

GoogleCodeExporter opened this issue Feb 18, 2016 · 5 comments

Comments

@GoogleCodeExporter
Copy link

This is a meta-issue for tracking the overall JCEF refactoring effort.

Overall plan document: 
https://docs.google.com/document/d/1CFihrGcU504yv2Xogt3Pll9L2b9E8MVYmwpQlCT17Do/
edit?usp=sharing

Step 1 document (issue 45 - issue 54):
https://docs.google.com/document/d/1NcrgjCugOpYFvb-HtVsP5xrVYsvEtda7uPhn_bPdRsY/
edit?usp=sharing

Original issue reported on code.google.com by magreenb...@gmail.com on 12 Mar 2014 at 9:50

@GoogleCodeExporter
Copy link
Author

Thanks for all this JCEF/CEF work and publishing this document about future 
intentions.

> I would like CefBrowser to behave as much like a normal Java UI control as 
possible. It should encapsulate the canvas implementation and expose 
control-like functionality. Maybe we can identify an existing Java UI control 
to use as a model for the interface? For example, it would be cool if it 
extended Component (or similar) so that users could subclass it and override 
functionality like preferred size, etc.
What you and Kai say are both true. Why not giving the end-user a widget class 
that extends java.awt.Container? Internally, the Container will be filled with 
a Canvas or GLCanvas based on the osr value. Canvas/GLCanvas is an 
implementation detail of no particular interest to the end-user. Container is 
more generic and allow us to decide what to use internally. Since it's a 
Container, user can still treat this widget pretty much like a regular AWT 
widget.
I know we're talking about AWT and Swing here. This approach is similar to how 
the org.eclipse.swt.Browser widget is structured - it extends Composite (sort 
of Container equivalent in AWT) which gives users a generic way to deal with it 
while making us free to implement it however we need it to be. I was the 
original committer/creator of the SWT Browser widget so I certainly have a bias 
:-)

e.g.

public class ChromiumBrowser extends Container {

public ChromiumBrowser(Window parent, boolean osr) {
...
cefClient = new CefClient(clientDelegate, false, osr);
Canvas canvas = cefClient.getCanvas();
setLayout(new BorderLayout());
add(canvas, BorderLayout.CENTER);
...
}
.. other APIs to access CEF functionality
}

Thanks for any feedback, and great work pushing this out. The native window 
rendering mode is so impressive by its performance.

Original comment by christop...@gmail.com on 14 Mar 2014 at 2:41

@GoogleCodeExporter
Copy link
Author

Original comment by magreenb...@gmail.com on 23 May 2014 at 6:31

@GoogleCodeExporter
Copy link
Author

All sub-issues are now complete.

Original comment by magreenb...@gmail.com on 17 Jun 2014 at 5:36

  • Changed state: Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant