@amaury74 wrote:
For me, it's not a problem (technically, not legally : I'm a complete noob in that domain) if NI tags a version of a component based on CEF or Gecko for each LabVIEW version, as they already do with hardware drivers (DAQmx for instance). They could distribute this package using the Package Manager.
Well, it's not about you here! 😀 I have in the past worked on a Java project that needed web browser integration. And as you may be aware, Java doesn't really come with a working WebBrowser component either. You need to buy some third party library. I used back then JxBrowser, which was a considerable expense but worked quite well except that it needs to be upgraded continuously to track the latest web standards. Back then (around 2010) it used either the Firefox binary API or Safari on Mac underneath and if you wanted to display a newer website that used new features you continuously had to update the JxBrowser component to be able to display that website properly. In the meantime they rearchitected their entire library to use CEF instead but that did not change anything on the continuous upgrade requirements.
Your solution of bundling a specific CEF library with LabVIEW is therefore not really an option. It would mean that if you build an application with such a component now with LabVIEW 2020, it would have used CEF 80 or so and will have trouble to display certain content from today. So the CEF based LabVIEW plugin should be instead a central component that can be installed somewhere in a shared location that all LabVIEW versions use, but that would be a huge effort. Such version independent plugin structures are a total pita to design and develop.
Basically NI is not going to develop such a thing at all. If they would do something it would be fully integrated in a LabVIEW component but integrating anything like CEF in such a component is a really terrible project to manage. And writing their own browser component would be even worse and anyone considering such a capital sin nowadays should be punished until the end of the universe for that.
As an extra obstacle, LabVIEW works on three very different platforms in terms of how the OS and GUI work. And while they have released Windows only features in the past, it would be suboptimal to say the least, to only release such a feature for Windows.
If it would be easy to do there would be a OS system component that can be simply integrated through an ActiveX Control or .Net Container. But not even Microsoft seems to be able to pull that trick, so why do you think NI could?
I can't image that NI not thought of putting these features in LabVIEW NxG. And I hope NI will really take time to add LabVIEW NxG best features in our beloved traditional LabVIEW.
They had some plans with NXG, but in this specific case I'm pretty sure they bet on .Net having that support at some point simply built in. It still hasn't so that may tell you a thing or two about how simple it is.
I have been pondering about how to make a CEF based component that could be used in a LabVIEW front panel. But while I see the technical possibility of this, it's simply a very huge undertaking to tackle and I have other things in my life than this. Simply out of curiosity, how much would you be willing to pay for such a library if it existed? And how much of a yearly subscription would it be worth to you to have this component regularly updated to the newest CEF version?