Embedded Chromium Brower into NetBeans

[lkishalmi]

Let's try to embed Chromium into NetBeans!

This is in a very early stage, most probably does not work at all. The reason I'm creating a draft, is that there are a few things to discuss here.

1. Do we want to do this? I hope it can be used for markdown previews, better JavaDoc renderer, who knows.
2. Are we Ok with the licensing? It is supposed to be a BSD like license, that gives us better compatibility than a JavaFX based WebKit renderer.
3. The native parts are big, ~100Mb per OS, per architecture. There is an option to download them on the fly from Maven Central, however, I'd prefer to create platform specific nbms, like JavaFX, though licensing would allow to bundle them.
4. What would be the target cluster? Initially thought of platform, then extra, later on, I'm thinking about to add this as it's own cluster, due to the size, and might not necessarily include this to the release right now.
5. This could change how we create the application binaries in the future... (just guessing here)

I've only played with the jcef standalone version so far. That one looked quite promising.

[matthiasblaesing]

I find this interesting and I'm surprised, that CEF has such a clean licensing situation. The price is high though as the size is huge (as already pointed out) and limits platforms to CEF supported ones (yes I know, that OpenJFX has the same problem).

The question is: Do we need it? I mean the JDK can render HTML and we already use that support. At this point in time my gut feeling is, that the price is to high.

If javadoc or markdown rendering should rely on it, this makes this a requirement of the IDE cluster.

[lkishalmi]

As I spent more time with it, better to say fighting with the module system, I'm leaning toward to put it in it's own cluster. Have a cleaner option to whoever would integrate it. (The price could be reasonable for architecture specific packages.)

Still, nothing works so far, just experimenting.

[neilcsmith-net]

Really interesting!

The price could be reasonable for architecture specific packages.

Which, aside from the current Windows installer, is none of the ASF packages. The ASF binary zip, deb, rpm and macOS pkg are all intended to support multiple architectures.

It could be an option for architecture specific community installers that bundle JDK runtimes I guess, but we'd have to add the ability to include the additional modules into NBPackage on top of the binary zip.

In another context, I was looking at Tauri recently, which is using WRY. Tauri is a lightweight Rust Electron alternative that embeds native webview components from the OS. I'm not sure if there's a Java library that can do similar, or how easy to replicate with JNA it might be???

[Chris2011]

For my POV, I would say YES, we need it defintely. We have more possibilities. We are not talking about just rendering plain old stuff, but everytime I'm using stuff to render HTML it looks odd and not full featured.

I dunno whether the JDK renderer is up to date with all current features of HTML, JS, CSS, etc. We then also have devtools intergration and probably has new features to work with IDE + the devtools. Debugging, etc.

Yes it is a huge stuff but step by step. We can have previews for almost everything what requires HTML. I also wanted to make a preview for SVG, I guess using HTML and a browser is better then smth else. Couldn't find it within batik. So as a frontend dev who wants to integrate more and more features for those techstack I definitely for this big feature.

I also kow tauri and the technic that neil mentioned and sure, when there is a possibility to use the underlying WebView from the operating system, that would be also fine.

[matthiasblaesing]

text, I was looking at Tauri recently, which is using WRY. Tauri is a lightweight Rust Electron alternative that embeds native webview components from the OS. I'm not sure if there's a Java library that can do similar, or how easy to replicate with JNA it might be???

The hard part is most probably not binding to the target engine and getting something on screen, but binding to the target engine and getting something into a swing component. If I remember correctly a long time ago someone complained, that JNA can't access the windows handle on mac OS, but nobody bother to implement it.

I also wanted to make a preview for SVG, I guess using HTML and a browser is better then smth else.

Are you looking for https://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/swing/JSVGCanvas.html ?

https://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/swing/JSVGCanvas.html

We are not talking about just rendering plain old stuff, but everytime I'm using stuff to render HTML it looks odd and not full featured.

I think there was a discussion about providing a base CSS to get better looking markdown rendering, but no one bothered to actually do the work.

The question that needs to be answered: Who does the heavy lifting when platforms should be added (Windows arm64, Linux riscv, Other OSes)? Swing is currently a pretty save bet, but Chromium porting? For Linux we will see a time where multiple windowing environments will coexist (X11 and Wayland), what will be the consequence for JCEF?

[Chris2011]

I looked for JSVGCanvas, this is what I found, but NetBeans said that this is not available. Maybe I imported smth wrong. Will check this again, thx for this.

The point for the PR with CSS for markdown is open and I wrote @lkishalmi today to check this up, due to your comment. I will do the CSS styling after we discuss what we really need and for what. This task is on my todo list on a good priority if things get clarified. For the others I can't say anything. Yes JCEF is a big part I understand and I'm with your thoughts, but what will be a handable alterntaive?

With flexmark, we got an webview which renders the html for the markdown. Is this enough to rely on? But it is just for markdown.