LabVIEW

cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

Modern embedded web browser

Solved!
Go to solution

@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.

Message 11 of 19
(2,302 Views)

πŸ˜€


@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.


 

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

0 Kudos
Message 12 of 19
(2,300 Views)

Hi Rolf,

 

Thank you for your detailed answer. I don't totally agree with you.

 

Let me add some precision about what I'm doing in my development :

 

I'm already distributing a CEF based WebBrowser toogether with a LabVIEW based application. There is no installed runtimes an no conflict with Google Chrome (Chomium and Chome are not the same, like Gecko and Firefox). You just need to add dll dependencies in your distribution and check compatibility of licenses.

The main problem I'm facing with is the LabVIEW integration (nowadays it's an external executable integrated in my front panel with MDI, communicating only using command line arguments).

 

On a more philosophic way:

 

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.

 

We are already accustomed to compatibility ruptures and bug introduction or fixes following the different versions of drivers, so why not adopting the same life cycle for a web browser component ?

 

Regarding the usage of ActiveX, I think it was a quick way to introduce connectivity with external applications and it was the good technology to use at that time. I'm not an ActiveX lover, I just ask for a way to get an embed a Web Browser.

 

We are at the era of Industry 4.0, seeing the invasion of connected devices and cloud based application. It's mandatory for an IDE/language to include or allow the integration of last web communication technologies. I see SFTP arriving in the last version of LabVIEW : that's a good improvement. Web sockets, server side events and new HTML5 features are going in the same direction.

 

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.

 

Regards,

 

Amaury LAURENT.

Message 13 of 19
(2,267 Views)

@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?

Rolf Kalbermatter
My Blog
0 Kudos
Message 14 of 19
(2,263 Views)

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


Seeing the huge developments around the gwebvi, systemlink cloud, and the usage of web technologies to simplify cross-platform deployment and access to embedded systems, I can't imagine a major actor like NI miss this technology turn.


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 ?


The question may not be 'Is it difficult to do it?' but 'Do we have to do it?'. Of course it's difficult : our work is difficult, otherwise we won't do it πŸ˜‰

 

Message 15 of 19
(2,240 Views)