WebView widget

Popular GUI frameworks all include a WebView widget. I think eepp should have one, too.

[SpartanJ]

This probably can be achieved by just implementing eepp as a backend over some of the existing libraries (I remember checking that a few years ago and it was possible, but I don't know if there's an up to date existing solution). I won't implement a multi-platform WebView myself, that seems to be a huge task. Also eepp supports too many platforms to make this an easy task, so I would say that this is simply not planned.

I'm not sure why @Alex2772 mentioned this thread, and how he referenced it as soon as this issue was created, now I'm curious.

A good designed WebView library could let any of these multi-media libraries implement some abstractions to render the WebView withing the library. Depending on the needs this could be solved with something as simple as litehtml which lets you add a backend really easily. But it's a very basic HTML engine. If you need something like WebKit/Chromium you'll need a library that renders the WebView intro a frame buffer and you just use that frame buffer, and the window+input should be also an abstraction that needs to be implemented by the consumer. There are some existing options for that: CEF, Sciter and Ultralight. But honestly if you're already using a full fledged browser engine, you shouldn't be using eepp GUI at all, it loses all its purpose. What I'm trying to do is to provide an alternative to heavyweight web engines in a first place.

Currently there are too many pending widgets to care about this particular topic, but I can understand the need of some very basic HTML+CSS support.

[Alex2772]

Hi @SpartanJ,

now I'm curious.

I have subscribed for updates on eepp.

I have exactly the same issue on my project as well so I'd happily participate in this discussion. I have shared my thoughts on the topic in that issue, they're essentially the same as @SpartanJ's. In addition:

• in some cases full fledged html is an overkill so something like a little markdown parser is a good way to go, it is handy and easy to implement. Qt does that.
• Also, Qt has minimal html support. It is enough to display formatted documents with links, i.e., for a license dialog.
• Also, Qt has a webkit widget, if you really need to display web content.

But honestly if you're already using a full fledged browser engine, you shouldn't be using eepp GUI at all, it loses all its purpose. What I'm trying to do is to provide an alternative to heavyweight web engines in a first place.

I agree with this. But, if an existing eepp/aui project needs to display web content, it simply can't, the only way is to drop existing codebase and rewrite it to CEF/Qt. To mitigate such risks, projects will not even give a shot to alternative UI frameworks.

[SpartanJ]

I have subscribed for updates on eepp.

Oh cool, I see. I've been taking a look at your project, very cool project, congratulations! I'll keep an eye for sure. Also let me know if there's anything I can help you with, since both projects have a very similar goal.

I have exactly the same issue on my project as well so I'd happily participate in this discussion.

Absolutely!

in some cases full fledged html is an overkill so something like a little markdown parser is a good way to go, it is handy and easy to implement. Qt does that.

This is the approach I'm going to take to display rich-text views. Basically I'll have a UIRichText view element and a markdown parser (I'll probably just use md4c) will convert markdown to eepp native rich text. This is one of my long standing pending tasks. I've been delaying this because I still need to finish implementing proper text-shaping and RTL text support. This could potentially be used to render some very basic HTML too.

Also, Qt has minimal html support. It is enough to display formatted documents with links, i.e., for a license dialog.

Exactly, they took that path too. I can also remember the Android TextView component has this same capability, it accepts some very basic HTML that can be used to style the text view. Most common use cases will be covered with this.

Also, Qt has a webkit widget, if you really need to display web content.

Yes, but it's also a huge library and dependency, it's far too much work for projects like ours. Unless we get a ton of collaboration (that didn't happen to me, C++ seems to be really a stopper for new devs) this is a dead end.

But, if an existing eepp/aui project needs to display web content, it simply can't, the only way is to drop existing codebase and rewrite it to CEF/Qt. To mitigate such risks, projects will not even give a shot to alternative UI frameworks.

Both libraries still have a good amount of pending work to match something like Qt (at least I'm sure about eepp ^_^). In my case I prefer to concentrate on those things first and then worry on more advanced use cases. That's in part why I'm working heavily in ecode, to force myself to test extensively eepp GUI and to continue to develop features based on the requirements of a complex GUI application. Although the decision of making something like ecode delayed a lot the development of eepp 😅.

[Alex2772]

very cool project, congratulations!

Thanks, it's mutual!

I think, in your case, you may want to ship markdown side-by-side preview to ecode, since you are using ecode as a battle test for eepp. Dogfooding is OP, for sure.

Android TextView component has this same capability,

Yes, exactly, and we both lack of it.

Yes, but it's also a huge library and dependency

On Android and iOS, you are forced to use system native WebView either way, which I'm not sure how to integrate the renderer with. On macOS and Linux (gtk) there's a way to use system webview as well, and on Windows you can use system's CEF, but depending on WebKit is a good way to go on desktops. Yes its huge, but not as much as CEF.

Just look at Telegram - it still benefits from being a Qt application with good system integration and performance, and webapps integrated to the client works relatively smooth. (although I'm not fan of them)

that didn't happen to me

It seems like you have more activity than mine. My email has more notifications from eepp compared to aui.

C++ seems to be really a stopper for new devs

I'm a C++ enjoyer and yes, that's sad. C++ developers are expensive and are kinda slower compared to a generic web/iOS/Android dev. We are definitely in a niche of a niche, which is acquired by Qt already.

[Curculigo]

Maybe something you can use:

https://github.com/CefView/CefViewCore

[Alex2772]

A similar thing https://github.com/paulocoutinhox/cef-sample/tree/master

[Curculigo]

I found this project on Google:

https://github.com/weolar/miniblink49

I don't know if it could be used or not, though.

[SpartanJ]

I think, in your case, you may want to ship markdown side-by-side preview to ecode, since you are using ecode as a battle test for eepp. Dogfooding is OP, for sure.

Absolutely, that's the plan. Also markdown is extensively used in LSPs for documentation, so it has plenty of uses in ecode.

 Just look at Telegram - it still benefits from being a Qt application with good system integration and performance, and webapps integrated to the client works relatively smooth. (although I'm not fan of them)

Yes, Telegram is probably the best example of good integration and mixing of the best of both worlds. Telegram's Qt GUI side is fantastic.

 I'm a C++ enjoyer and yes, that's sad. C++ developers are expensive and are kinda slower compared to a generic web/iOS/Android dev. We are definitely in a niche of a niche, which is acquired by Qt already.

Yes, even if we provide good language bindings it will be really hard to get collaborators for the core library.

Maybe something you can use:
 https://github.com/CefView/CefViewCore

 A similar thing https://github.com/paulocoutinhox/cef-sample/tree/master

Regarding the CEF links I would like to discard it due to the huge package size required but it seems to be the most probable and easiest solution. I like the neutralino approach but it's not possible to integrate. This site list all of those options that do not have an API to integrate the way we need, so we have to discard all of those.
Regarding CEF here is a complete off-screen rendering implementation example with OpenGL. It's quite easy. The hard part is distributing CEF within the package. As a side note: CEF is being used by Steam, steam is an SDL + Vulkan application, and does integrate the browser the same way we need to do it. This is probably the best argument in favor of CEF... if they're using it, it's probably because it's the best and most mature solution (and as far as I can see the only fully open-source one).

 The preferred compiler of this project is MinGW-w64. Does the usage of CEF or WebView2 forced the project to require MSVC on Windows?

No, it would be just an externally built dynamic library. There's no way we add CEF compilation to our pipeline. It can take hours to build.

 Another choice would be WebKit. But QtWebKit is currently in trouble and CsWebKit (CopperSpice WebKit) is not maintained, either.

What we need is not to decide which browser engine, but to find a library that allows us to consume one from within our environment. We need to be able to render the contents in a frame buffer that we own. Depending on a Qt solution would literally make us dependant on Qt which is ridiculous for our use case.

 I found this project on Google:
 https://github.com/weolar/miniblink49
 I don't know if it could be used or not, though.

That's just blink minified (but not much honestly). Sadly, not useful.

Regarding Servo: It would be an option if there where bindings for C++. Servo can be embedded in a similar fashion than CEF. Here's a Rust + OpenGL example.

Regarding Ladybird: It's actually a real option, but it needs maturing.

Depending on a Qt solution would literally make us dependant on Qt which is ridiculous for our use case.

Correction: If you want to use WebKit, you will have to develop EE::WebKit (WebKit for eepp). You can't use QtWebkit (WebKit for Qt) or CsWebKit (WebKit for CopperSpice). BTW, GTK people also have WebKitGTK (WebKit for GTK). WebKitGTK is the most actively maintained.

[SpartanJ]

 Correction: If you want to use WebKit, you will have to develop EE::WebKit (WebKit for eepp).

Yes, I understand but that was not what it was suggested, using QtWebKit or QtWebEngine is technically possible, it's just not a good idea (they can render to a frame buffer).

Forking any browser engine to add an eepp backend would be a massive job. It's technically possible and some people have done it for several different reasons, but it's a project that needs to be very actively maintained, it's not something I could do myself as another side-project. Regarding browser engine portability AFAIK historically WebKit has been easier, it has been designed with backends in mind so you can implement your backend, it's just that it's quite complex. For example the haiku port of WebKit is a good reference implementation.

[SpartanJ]

BTW, for the lightweight solutions there's also Netsurf, it's easy to add a new frontend (netsurf has frontends that implement the graphical part of the browser), but it's very limited browser.