How does JUCE accomplish its web browser component on each platform?

Following on from http://www.juce.com/forum/topic/using-html5-canvas/svg-gui I am digging further into the idea of using a JavaScript-rich .HTML for my JUCE UI.

How does JUCE accomplish its web-browser component on each platform?

This is pertinent because if you are coding up a webpage,  you have to be careful -- IE will have one way of doing things, Safari another, etc.

So how to ensure that content will display correctly cross-platform?

Web developers typically test a .HTML by feeding it into e.g. browsershots.org which displays it on each of the major browsers and returns you the screenshots.

If I knew e.g.  that JUCE-Mac/iOS  browser was basically Safari,  Win was IE,  Linux=Firefox, Android=Chrome,  I could just  examine those five screenshots.

π

The relevant platform-specific WebBrowserComponent implementation is in juce_gui_extra/native.

For OSX and iOS, it uses WebKit, which is the rendering engine used by Safari (it does *not* mean though that the result would be screenshot-identical with Safari).

On Windows, it uses the IWebBrowser2 interface (https://msdn.microsoft.com/en-us/library/aa752127%28v=vs.85%29.aspx), that is basically IE.

On Linux and Android, WebBrowserComponent is unfortunately not implemented yet.

Many thanks for the helpful reply, Timur!

Can anyone tell me whether implementation for the remaining 2 platforms is on the horizon?   Is it roadmapped?

I wonder whether it would be possible to leverage Chrome...

I suppose the problem is that there is no native web-framework that ships with Linux/Android.

I'm investigating because I'm seriously considering using an HTML5 Canvas on a fullscreen browser page for my UI. This would allow seamless consistency between my webpage and my apps.

π

Unfortunately the WebBrowserComponent implementation for Linux/Android is not on our roadmap at the moment.

But maybe this is something that you could implement for your app and then share here?

Can anyone suggest a way of achieving a browser window on Linux / Android?

How to go about providing this?

I'm guessing it is possible these operating systems do not ship with a browser, so the solution may require getting the user to install say Firefox or Chrome, and then making use of the new library.

π

On linux it shouldn't be too hard: Other processes are allowed to create child windows into parent windows of other processes. There is absolutely no restriction in doing this on linux. The idea would be for juce to fork a gtk-based sub-process which creates a GtkWebkitView in a window and adds this window as a child window of a juce window. All redrawing events will then be handled by the sub-process. To get things like keyboard focus tab order right, X11 specifies a protocol called Xembed. With Xembed, JUCE and the child process can communicate to each other about things like tab order. GTK offers some nice wrappers around the Xembed protocol.

The relevant documentation is:

WebKit View:

http://webkitgtk.org/reference/webkitgtk/stable/webkitgtk-webkitwebview.html

 

GTK wrapper around Xembed:

https://developer.gnome.org/gtk3/stable/GtkSocket.html

https://developer.gnome.org/gtk3/stable/GtkPlug.html

 

Xembed protocol:

http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html

 

Anybody feel like implementing this? :-)

 

2 Likes

The best way to do this would be to use the Chromium embedding framework: https://bitbucket.org/chromiumembedded/cef

It's supported on Linux, Mac, And Windows and will give you the HTML 5 functionality you want.

I did wonder about the idea of embedding Chromium.   Isn't there a downside, in that either you would have to ship your application with chromium,  or require the user to install Chromium prior?  And it is a big component!

Upside would be all your three desktop operating systems would be using the same component.

Windows using an IE component is a little scary to me; while the other major browsers dance around the new web standards, IE is in a sad world of its own.  Try looking at web audio, the other browsers have completed it -- IE doesn't even have it on the map (http://caniuse.com/#feat=audio-api).

Also if you can use the same component everywhere, you can pretty much guarantee HTML pages will look the same to everyone.  If you're using different browsers you have to work very hard for this,  but here you would get it out of the box.

Nobody's been mentioning Android...

I know I am late to the discussion, but please add a working WebBrowserComponent implementation for Linux. For some of us who chose Juce for being cross-platform this is an important limitation and as other users say, it shouldn’t be too hard to implement.

2 Likes

We’ve now added preliminary support for the WebBrowser component on linux. Please take it for a spin and let us know about any bugs you encounter.

2 Likes

Thanks for the feedback Fabian.

Could you please explain what do you mean by “preliminary support” and what version is the first we can start using it with?

Could you also explain whether it relies on third party components such as Chromium or other dependencies we’ll need to add to our projects.

Best,

Well “preliminary support” means that with such a big feature, I expect there to be bugs although there are no known issues that I found while testing.

The WebBrowserComponent uses GTK+ WebKit internally.

1 Like

I am working on a JUCE wrapper for the Chromium Embedded Framework, which seems like it’d be pretty useful for this.

However, I feel like a better avenue for web-ui style development is combining React Native with JUCE, which I know the JUCE team has looked into. I’m mainly using CEF with Encrypted Media Extensions to try to get a truly cross-playform way to stream spotify songs. Will post the repo when it is ready.

I’d like to do something capturing and processing audio inside of a browser in a JUCE application. Because you can’t access it using their native browser wrapper I realized that I’d probably have to wrap Chromium manually. If you pull this off please let me know. Thanks!

It’s a pretty big undertaking, but I’ll definitely be posting it here if I pull it off!

Been there. Done it. Do not advise doing it. Our stuff isn’t really shareable ! You should see the build process… :slight_smile: