add web widget

[easykoo]

add web widget such as webkit please

[asciifaceman]

cursory research seems to show the only webkit options are cgo bindings, so it may come down to maintainers choice of which binding set (or to roll their own) to use. Otherwise this should be a relatively trivial implementation.

[andydotxyz]

I have looked into this and I think you're right. Cgo is not a problem as we already need it, however the external dependency might be an issue.

On Windows we can rely on the system APIs. On macOS webkit is available so that's fine. On Linux, however, I can only find bindings to GTK-Webkit which means additional libraries, and also the GTK widget set would be used.

In an ideal world we would have a Fyne-Webkit that use our widgets but that is a lot of work. I don't know what a sensible intermediate step would be...

[asciifaceman]

I found another example with windows/mac/linux support here with a current C lib rewrite in progress that may be piggybackable in the future. however, more interestingly, are notes on operating system dependent implementation requirements.

Additionally, I realized it would become far less trivial if we wanted to support the content being served from the same app that is rendering it.

[andydotxyz]

That one linked pulls in GTK+ as a dependency amongst others. I don't know how to solve this yet but we can't add runtime dependencies to get this working as we haven't any beyond the GL graphics currently.

[conanchen]

perfect to integrate with lorca to show web pages. https://github.com/zserge/lorca

[andydotxyz]

After discussion with the Fyne contributors it seems unlikely that we will add support for embedding web pages. To do this properly we would ideally have a Fyne version of a rendering engine so that buttons and other controls are consistent with the app. Also it is not clear how to build this in a way that would support all the target platforms we aim to support.

We do intend to include markdown support (not including the embedded HTML probably) for marked up content so hopefully that will help in many scenarios.

Until we can understand a compelling requirement behind adding such functionality it is unlikely that we will progress this item.

[asciifaceman]

imho a webview is demanded long-term (remote-loaded application TOS/Privacy Policy is just one reason I can think of off the top of my head), but the implications of it's implementation definitely bump it down to "some day"

[andydotxyz]

Hmm. I'm still of the view that I can't see the use-case. I'd want all Fyne apps to work offline by default and if content is on a remote server then that's going to break in no-internet situations.

Of course that's just one opinion and I agree that even if we did decide to do this it would not be soon ;)

[ohir]

IMO there is no place for such a huge bloat as 'webview' in Fyne. If someone feels uneasy doing app outside his or her 'html/css' comfort zone, he or she will not be able to make proper desktop app in Fyne. For webdev people vanilla Go acting as a local webapp server is more than enough for having a webview inside appview ;) With or without Lorca. See here.

[andydotxyz]

OK we're being courageous on this one and saying it's not going to happen. Please feel free to open new tickets that require some kind of web integration if required, but in general we're not going to add a web view if it can be avoided.

[forcemeter]

hi there, the CEF project is a nearly solution, maybe this will be a big help.

https://bitbucket.org/chromiumembedded/cef/src/master/

[andydotxyz]

Unfortunately as well as adding 3 hours to build (according to their docs) it also does not support mobile devices.

[polotto]

IMO the only reason that webview is needed in the Fyne is to make some type of authentication, OAUTH2 or something like that, but, this can be done calling the system Browser. I don't how complicated is that, but make some kind of abstraction with the system browser and Fyne can be a solution.

[macfisherman]

Hmm. I'm still of the view that I can't see the use-case. I'd want all Fyne apps to work offline by default and if content is on a remote server then that's going to break in no-internet situations.

Of course that's just one opinion and I agree that even if we did decide to do this it would not be soon ;)

I have a use case. An email client. Many messages use HTML as the markup. What component in Fyne could provide that functionality?

[andydotxyz]

That is a valid use-case, but I don’t think enough to change our decision. It is possible to build an HTML renderer and it may even make it into an extensions repo, but no need for it in core.

[swm888]

@andydotxyz hi，go-echarts will render html. maybe add web widget for watch echart is useful.

[andydotxyz]

Any chart library that can export HTML would surely be able to export SVG or PNG instead. Going via a web language is wasteful of resources.

[ghost]

Please add webview support, this is really needed

[andydotxyz]

Can you expand on why it is needed @dragonDScript, if so then open a new issue, this one was concluded? Mixing web and native content risks a very bad user experience so unless there is a use-case that is clearly needed we continue to think this should not be added in core. If you want to display marked up text use widget.NewRichTextFromMarkdown and markdown content instead of HTML.

[ghost]

Can you expand on why it is needed @dragonDScript, if so then open a new issue, this one was concluded? Mixing web and native content risks a very bad user experience so unless there is a use-case that is clearly needed we continue to think this should not be added in core. If you want to display marked up text use widget.NewRichTextFromMarkdown and markdown content instead of HTML.

Yeah, mixing web contents and native content is bad unless you're making a browser. That's my use case. >_<

Other than that, webviews are very useful lots of things. VSCode isn't a bad user experience, isn't it? Atom?

[Jacalz]

VSCode isn't a bad user experience, isn't it? Atom?

In my opinion, any time you are diving into the web components, it is a bad user experience. Not directly noticeable all the time with VSCode and Atom but if you just peel off the top layer and look at install size as well as cpu, energy and memory usage, you will see that it honestly is utterly atrocious. Not to mention that each electron app comes bundled with its own web browser and is often behind on security fixes. We are developing a native toolkit and thus I think we should stay as far as possible from web technologies like HTML and CSS.

[andydotxyz]

It is also important to note here, a full-window web component is not the same as an embedded web view. If you want a whole window that is web (like VSCode etc) there are many other toolkits. They are not mixing native and web as we expressed as a poor experience above.

If however you would like to build a browser specifically using Fyne for its benefits in other areas then you have a large item of work ahead. All existing web views use different toolkits for the rendering, so you would be looking at a mixed-toolkit solution unless it is built from the ground up.

[ghost]

VSCode isn't a bad user experience, isn't it? Atom?

In my opinion, any time you are diving into the web components, it is a bad user experience. Not directly noticeable all the time with VSCode and Atom but if you just peel off the top layer and look at install size as well as cpu, energy and memory usage, you will see that it honestly is utterly atrocious. Not to mention that each electron app comes bundled with its own web browser and is often behind on security fixes. We are developing a native toolkit and thus I think we should stay as far as possible from web technologies like HTML and CSS.

Think about browsers, they have web components and native components. I just want that, I think it would make this framework much more flexible. You do t need to necessarily use web if you don't want to. It should be optional for me. E. g. as a separate module

[ghost]

It is also important to note here, a full-window web component is not the same as an embedded web view. If you want a whole window that is web (like VSCode etc) there are many other toolkits. They are not mixing native and web as we expressed as a poor experience above.

If however you would like to build a browser specifically using Fyne for its benefits in other areas then you have a large item of work ahead. All existing web views use different toolkits for the rendering, so you would be looking at a mixed-toolkit solution unless it is built from the ground up.

Yeah, it is to note that a webview implementation in go already exists.

[andydotxyz]

I don't think there are any new use-cases here other than "it would make it easier to build a web browser". If you feel we have missed something please open a new feature request with the use-case added there.

[ghost]

Not easier, possible. Right now it's not possible to make a browser in Go.

[andydotxyz]

It is currently possible to build a web browser with Fyne. Just because there is not a pre-built component does not make it impossible. We do not have built-in video support but there is a movie player app…

[fbaube]

A use case might be, we have a website or CMS and we wish to render content that is not authored in Markdown and not necessarily viewable raw. For example, XML-based (like DITA) or some other text-based format (such as AsciiDoctor or reStructuredText). Typically such formats have tools to render them as HTML, and if not, then Pandoc may be able to do the job. To display such content in Fyne, rendered-as-HTML, an embedded HTML widget would be nice. However the ability to easily launch a new window for displaying the content using WebKit might also be useful.

[andydotxyz]

However the ability to easily launch a new window for displaying the content using WebKit might also be useful.

You can call app.OpenURL to launch web content in a new (browser) window.

Typically such formats have tools to render them as HTML, and if not, then Pandoc may be able to do the job.

I understand that HTML is commonly exported from such tools - but if you are transforming then you could export to markdown and achieve a similar, but more semantically useful, result.

[fbaube]

Opening a new browser window is kind of a heavyweight operation for viewing bits of HTML, isn't it ? And also, consider the lengths Fyne goes to to deal with rich text - RichTextSegment etc. Might an embedded HTML viewer be a win for both simplicity and functionality ? It might also open the door to JS-based in-browser editors. Also, not to quibble but I'm not sure about the "semantically useful" part. If HTML is light on semantic tagging, Markdown is even more aggressively so, being tagless.

[andydotxyz]

Opening a new browser window is kind of a heavyweight operation for viewing bits of HTML, isn't it ?

Sorry, I was intending to answer the how to open a new window to display web content

Might an embedded HTML viewer be a win for both simplicity and functionality

Not really, not all target platforms have a web renderer already installed - so it would either not be present on all OS or would require us to bundle a browser engine.

Also, not to quibble but I'm not sure about the "semantically useful" part. If HTML is light on semantic tagging, Markdown is even more aggressively so, being tagless.

Sorry, but tags are not semantics - the semantic web shows how HTML could have become more semantic but it did not progress well. Markdown is almost pure semantics - "header" is a semantic meaning, however CSS with "font-size: 48; font-weight: bold; font-family: ..." is not semantic information. We use markdown to get semantic information about the rich text so that the GUI toolkit can render it according to the theme so that it matches the rest of the UI.

[chenzhekl]

Can we at least have a small example of how Fyne can be integrated with existing web views (e.g., CEF)?

[andydotxyz]

I don't really know what you mean here @chenzhekl, Different rendering technologies rarely mix well.

[Bluebugs]

@chenzhekl it is likely a good amount of work to integrate CEF with Fyne. My main issue at the moment is that CEF itself require very powerful computer to build it and it still takes a lot of time iterating with it. Basically not something I can see myself doing as a side project. If it is something you really want to see, I think the best path forward is to get support through a company. This might be something you could contact Fynelabs for.

[chenzhekl]

Thanks for your replies. I underestimated the workload.

[Kukulkano]

I plan to re-write desktop clients for message encryption and decryption (Win, Lin, Mac) in go. The decrypted messages are usually in HTML (created by Outlook or Thunderbird). I need to display them inside of my client app. It was previously done in PureBasic using its Webgadget, but if I want to re-write in golang with Fyne, I have no such option?

At least I need to render HTML including CSS (no JS) for Display and Print (CSS media query). How to do that?

[andydotxyz]

There is no builtin web component. We use Markdown for marked up text - this does not have the complexity or security issues of an HTML renderer and allows the app theme to define its look instead of being baked into the payload. I would recommend taking this approach if you can.

[Kukulkano]

Thanks for your quick answer, but we use HTML format since 16 years and messages origin from Outlook, Thunderbird etc. I do not get markdown and I can not break compatibility with millions of messages since then... So I have to look for something else. Wails looks promising so far...

[Bluebugs]

Maintaining a cross platform webview widget by the community is, I think, really hard. If you have a very strong need for html and your company is interested to support the development of the fyne ecosystem, I think you could request support for this from fynelabs: https://fyne.io/support/ .

[af913337456]

@andydotxyz +1 need webview widget

[kant-li]

Also considering the possibility of webview support. In my use case, it's an instant message app:

1. msgs sent by users may contain urls. it will break the exprence if they have to open the link in a system browser and come back to continue the chat. (it's possible to convert the content to markdown, but not likely the best option)
2. I want to support third-party extensions on my app, so that users can add widgets or other interactivable components. It seems the easiest and most common way to do this is using a webview.

There may be work arounds for this kind of scenarios, still thinking about this.

[andydotxyz]

I would disagree with 1. as web browsers are designed for consuming web content, by opening it alongside your app the user is much better able to continue the conversation whilst looking at the link that was opened. For 2. This seems like an unwise approach, it basically guarantees that user-added content will not look or behave the same as the main app. I would recommend exploring a more declarative / domain specific format of extension that you can render through Fyne widgets and the standard theme.

[jspraul]

Andy I appreciate what you're doing with Fyne very much.

A web widget may be out of scope for Fyne right now, just like an advanced data grid and other technically complex widgets. However, arguing against potential users' use cases is a bad look. I recommend documenting the available alternatives as you have done but leaving out why you think they are better. Also, the commenter recommending commercial support has the right idea.

Continued success to everyone making contributions to Fyne!

[fgm]

I happen to have two of the use case mentioned in this dicsussion:

• OAuth2 browser flow (but maybe there could be an alternative without a webview ?)
• displaying the output of go-echarts: I currently start the default browser using a copy of https://github.com/golang/go/blob/master/src/cmd/internal/browser/browser.go but that is definitely not smooth UI-wise

[andydotxyz]

As you say there are alternatives to opening a web browser for OAuth.

The go-echarts library is for web display. The fix is not to embed a webview but to use a charts library designed for Fyne or native app display.

[ilius]

I have a dictionary application, and dictionary entries / content are usually a limited subset of html (though sometimes a full html page), and I'm using Qt with QTextBrowser. But unfortunately the Qt binding is discontinued and it has many problems, and it doesn't even run in FreeBSD. So I'm looking for alternatives. It's fine if it does not support JavaSript at all. I don't need buttons or forms. Just a rich text. But it has to support CSS pretty well.

[andydotxyz]

Please don't comment on closed issues, they have been closed for a reason. Go read the docs for the RichText widget and move your theming to the Theme type, converting from css if you must. Fyne will not be pulling in a web rendering engine.