I believe there is already a method to open a URL in the user’s browser...

The former might happen soon. The latter is just a suggestion for now.

I believe there is already a method to open a URL in the user’s browser...

What I mean, is a way to render a webpage inside the GUI.

Looks like IE can be embedded, and WebKit is easy to integrate on macOS, but how would the GTK implementation work? WebKitGTK+ might be an option.

I don't want to expose different rendering APIs on each platform. It'd have to be WebKit or XUL or Servo on all three. WebKit can be embedded on Windows, but the only way to actually get WebKit for Windows is to build it yourself :| (Still wondering how the Servo stuff is going =P )

You already are exposing different rending APIs with the drawing functions. Using a non-native web engine would seem to go against libui's model of using native platform controls. If the user knows that the web component is wrapping native WebKit and native Trident and knows the limitations of those engines, then they should be able to work around those without issue.

FWIW wxWebView works this same way.

I suppose you have a point there. My concern was more how the different rendering APIs render differently and give you different levels of control over the browsing process. With the drawing APIs I expect the same end result regardless of the drawing; that might not be the case for the web APIs. And does mshtml give me the same level of control over loading resources, navigating pages, handling specific protocols within the program (without needing to register with the OS), etc. that WebKit on OS X does? A web control will be more than just the web view itself. I can tell you from experience that even WebKit on OS X offers different types of control than WebKitGTK!

If I do make a WebKitGTK-based thing it'll have to be a separate library due to the extra dependency; libui-web or libui-webkit or something.

I'd say use what's native to keep the package size down. Having to include all of WebKit seems it'd really increase package size. Although if you have to include something on Linux, WebKit seems like a good idea.

I like the notion of using the native interface on each platform (and it seems to meld well with how libui currently works), however, I am not against the notion of having the same rendering engine for this. If it does go in that direction, I would certainly vote for servo; webkit is massive and has a bunch of really unfortunate legacy cruft; QtWebEngine is kindofalittlebit a thing, but does not appear to be particularly stable yet (and it's based on Chromium's blink, which now also has a bunch of cruft).

Servo seems like the lightest-weight, fastest and most powerful option. So, it seems like the best candidate to me for a cross-platform solution.

@andlabs, you don't have to expose different APIs on each platform; you can just wrap each platform's own APIs. This is what wxWidgets does, I believe. On Windows for instance you could wrap Trident (or maybe EdgeHTML on Windows 10), on OS X WebKit, etc etc... though this does of course have the concerns you mentioned here, but I suppose the user will need to determine their own application's needs and whether this would be appropriate vis-a-vis shipping WebKit, for example.

I've run servo and it doesn't seem ready for production yet. It definitely is lightweight, but it's missing a lot of features.

So with the new nightly builds of Servo, I decided to try it out. It's very fast and definitely tiny (compared to other browser engines) however it's very incomplete. Some webpages don't render at all (duckduckgo) and others render with issues (GitHub, YouTube, even Reddit!)

I'm confident now that it'd be a terrible choice until they fix a lot more of their issues.

I really don't see a reason to package a full browser into the application. I think using the one "native" to the system is fine. I know that this causes all sorts of incompatibility issues and differences on platforms, but this is something web developers have been handling for a while now. In my use case, I already have data as HTML that will render fine in any browser (even very old ones). I assume my use case is not unique. If a specific browser is needed I could see that as an alternative option.

Even if I do decide to just use whatever native browser that comes with the OS, this would still be a separate library to avoid every program needing to depend on WebKitGTK+ on Linux. (And which version of WebKitGTK+ do I use, 1 or 2? Their APIs are very different.)

Ideally a "your choice" thing would be nice, with mshtml/webkit on one hand, webkit everywhere on another, and servo on a third

You could add support for Servo, but it's not usable at all in its current state. Looking at the project it'll be at least several months before it works decently.

Yeah, giving choice definitely would be a good idea. As for using WebKitGTK+ (I suggest v2) allowing a separate library is probably the best way to proceed.

https://github.com/litehtml/litehtml :)

Wow that's a pretty cool lightweight browser. There's definitely a lot of stuff that doesn't work in it though. For instance I can't click inputs or even visit my own site ("Something Wrong")

I think it could be used to draw HTML in a uiAreaHandler struct implementation.

We could also listen for keyboard and mouse events to create a rich text editor as asked #174

Embedded WebKit would enable the use of very sophisticated rich text editors (for example CodeMirror), fulfilling the needs of #174 . That is, if there was a way to interact with its JavaScript engine, in addition to just rendering HTML.

So my final thought is, a webpage component should probably be a separate library instead of being included due to there not being a cross platform engine that's small enough to embed.

Oh I don't think I mentioned it, but regardless of what I do choose to do, I want to provide a complete API for controlling the web view in arbitrary ways based on my experience with writing ohv; as a consequence this would be a separate library due to sheer API bloat.

No. I haven't pushed anything because the uiTable implementation isn't finished yet; I still need to write it on Windows, and I'm back in a motivational lull. I have an IRL job that saps most of my time and remaining motivation now as well. The project is far from dead, though. (Of course, even after uiTable is done I have to convert it to uiTree, so there might be another long delay before another push assuming I don't push the uiTable stuff alone first.)

Are you now in the uiTable -> uiTree phase?

Merged with #315.