LabVIEW
Modern embedded web browser
Solved!
@BertMcMahan wrote:
@Hooovahh, I think the OP wants to embed a webpage into a front panel. Not put a front panel on a webpage.
Oh geez, sorry. Yeah sorry I've been following technologies that go the other way for a bit now and so that's where my brain went.
😀
@Hooovahh a écrit :
@BertMcMahan wrote:
@Hooovahh, I think the OP wants to embed a webpage into a front panel. Not put a front panel on a webpage.
Oh geez, sorry. Yeah sorry I've been following technologies that go the other way for a bit now and so that's where my brain went.
@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?
@amaury74 wrote:
I totally agree with you that it's a pretty difficult problem. But let me recenter the debate:
Nowadays LabVIEW provide an IE based web browser that is deprecated. IE will be totally abandoned by the mid of June (or July). NI has two options:
1-Remove this functionality
2-Make things up to date
That functionality is just an example that ships with LabVIEW. It is not an officially sanctioned feature of LabVIEW. The ActiveX Container used for it is a LabVIEW feature, but not the example to use an IE WebView in it. That's simply a possible application of that feature.
Removing this example is a simple task, replacing it with something new, a huge undertaking. Guess what will be NI's choice if you point your gun at their head and force them on this!
Can you imagine a cRIO based application with embedded webVI to design front panels delivering light client interfaces? I believe it's the future (or the present?) of embedded systems. So why don't deliver a solution to take advantages of these impressive technologies and allow us to build composite user interfaces mixing traditional design and remotes panels hosted in an embedded web browser ?
What you talk here is the complete opposite of what you talked earlier. This is how to present data that is created on the cRIO to some other clients. The nicest way would be to have an interface that can send an HTML5 stream of a front panel to whatever web front end someone wants to use. This has certainly be looked into by NI and may have been considered, but I think it is to open for NI's taste. They want more tight control of who can view and maybe even take control of a VI running on a cRIO. Partly for security reasons and partly for revenue reason. Such viewer front ends are a gold mine if they can be monetized on a per client base, which you can't easily do with an open HTML5 stream.
And it's a developers nightmare to maintain, but that is another story!
@amaury74 wrote:
IE will be totally abandoned by the mid of June (or July). NI has two options:
1-Remove this functionality
2-Make things up to date
There is another option. NI can just leave things how they are. Last year NI was selling an embedded cDAQ device running Windows Embedded 7. I asked NI how they were going to handle the fact that Windows 7 wasn't going to be supported. I expected the answer to be either they wouldn't sell that anymore, or they were going to release a new version with the Windows 10 equivalent which requires more storage, processing, and ram. They did nothing and you can still buy a new almost $5k chassis, running an OS that won't get any security updates. Similarly when Silverlight was being abandoned I thought NI would come up with a replacement. They did remove Silverlight as a requirement for some devices but, several devices still need it for a web configurator, and Web Publishing Tool still uses it.
Still I'd rather NI just leave stuff in there, rather than remove it. Even if it only works in very small use cases.
@rolfk a écrit :
That functionality is just an example that ships with LabVIEW. It is not an officially sanctioned feature of LabVIEW. The ActiveX Container used for it is a LabVIEW feature, but not the example to use an IE WebView in it. That's simply a possible application of that feature.
Calling that an example is a point of view. For me, it's an included feature as it's in the standard palette, not in the example database.
@rolfk a écrit :
What you talk here is the complete opposite of what you talked earlier.
I don't think so. Here is a partial view of what I have in mind for just monitoring a batch of embedded systems :
The PC Application may have other things to do, which require more than just some web browsers. Embedded systems may be as diverse as cRIO, IP cameras, SoC, IOT Sensors, ...
@rolfk a écrit :
Guess what will be NI's choice if you point your gun at their head and force them on this!
I don't point a gun at anyone. I'm just asking my supplier for information to decide what to say to my customer so he can decide of his roadmap. This forum is officially the first step to ask technical questions. And for now, even if our conversation is interesting, there is no official clarification about the future of this feature.
@rolfk a écrit :
The nicest way would be to have an interface that can send an HTML5 stream of a front panel to whatever web front end someone wants to use. This has certainly be looked into by NI and may have been considered, but I think it is to open for NI's taste. They want more tight control of who can view and maybe even take control of a VI running on a cRIO.
Architecture of customers' application rely on customers' decisions. I have a case where the UI I should display must not be application based, but target based. It has a different life cycle, it's developed by a different team, in a different language and so on.... I have another case where my application uses a really good web framework to greatly enhance user experience. I have lots of good reason to ask about embedded web browser.
I see that we won't find a middle ground, but well... I asked my question and that's all.
Well Microsoft hasn't managed to do it so far. Sun/Oracle haven't either. So that makes me pretty sure NI won't do it either. They are playing in a little corner of the large house called software development, compared to these guys.
I'm however amused by the fact that you simply ignored my curiosity about how much such a feature would be worth to you to pay for. 😀
