Is there any tool to convert a photon application into HTML to view it from a browser? At least the most basic layout of the screen, the positions of buttons, labels, combo-boxes? The standard controls in a HTML page?
Thank you!
Best regards,
JM
Never heard of such a tool. However maybe there is a tool to convert postscript to HTML? You should be able to “print” to a postcript file. The next step would be to convert that postcript file to HTML?
Or write your own printer driver?
Hum, thanks for the idea… It sounds originally good… it’s not a bad start… but quite difficult and “unsolved” maybe… It could be a very cool tool… But is really a bit painfull that there isn’t a more direct way…
It seems to be something quite trivial nowadays, doesn’t it?
JM
I don’t know of any way to turn a Windows (XP) into html 
Grab a screen shot and embed the image into an HTML file…
Yes… maybe you are right… I want too much… I think in a near future this kind of application/migration will be more transparent… But this is science fiction… or a good job to do!!.. 
Yes a print screen embed sounds easy… but I need dynamic contents… (the 2nd part of the question)
Many print-screens… oh, no… I need to think a little more… 
I think the solution will be just double develop. One app in Photon AB, and the other identical in php with javascripts or something equivalent. I don’t know… This is what I was trying to avoid… other identical sencond development… but… I don’t see another option right now to see our beauty Photon apps with all it movements from a browser…
We just want to avoid phindows for many reasons (industrial security is the most important, bandwith is the second, a standard tool like a browser to access screens is the 3rd, there are many more)
Thank you anyway!!
JM
JM,
converting a native GUI application to HTML isn’t possible as there are so many differences between the two worlds. Even if such a tool would exist - you wouldn’t like the results (and therefore the motivation to write such a tool is not that big).
In my eyes there are the following approches you can consider:
-
Write two different GUI applications (one Photon - one HTML/JavaScript/PHP)
-
Use the same HTML/JavaScript/PHP GUI application also on the target with Firefox
-
Use an other technique that is available on both platforms (Flash, Java?, Qt??)
-
Try to decribe your GUI in a object model - then write transformers, which will generate a Photon GUI and a HTML GUI
-Peter
What do you mean by “industrial security”?
Ok, long history… but just to summarize, we use QNX in an heavy industrial plant (controlling and monitoring production proccess lines, starting motors, open and closing valves, and so on…). We have some security locks in order to avoid someone (perhaps somebody who knows the pwd of root) access via phindows and move some a machine innocently from 200 miles and not watching the equipment, not in the line proccess. So, we are migrating to a new approach to access QNX for clients not directly involved with the proccess itself, with a different (extremely harmless and innocuous) technology (HTML page). This is the short story…
As I mentioned, this is the main reason, but not the only one. The second is to achive a more integrated environment… It’s sound stupid maybe, but telling a high manager: “ok, look, if you want to see managment indicators (productivity, efficiency, etc) use IE, if you want to see the on line status of the proccess line, you’ve to use Phindows”… “Use what?? Ask later the high manager”… HEHE just kidding. Even for me, is not so comfortable and elegant move for one environment to another… So we are looking for an homogeneous point of view for clients, people who need data residing in QNX’s machines (realtime data) and in Windows Servers (managment indicators, historical data, etc… we have a huge amount of different integrated systems…)
I hope I have been clear enough…
Regards,
JM
Hard to tell what’s best, even with all the facts it’s hard
What we’ve done here is all of our GUI and database stuff runs on Windows ( they are Java based). We can run them on Linux if we need to. Can’t run them on QNX because they are based on Swing. But that’s not a real issue, our product are rather expensive, adding one PC to handle the GUI is a no brainer.
In the old days we used QWindows, but have learn the downside of using proprietary GUI. Because we don’t have to ( no embedded related constraint ) we stay away from Photon.
We do the same as Mario for the exact same reasons.
The only difference is our Windows GUI is in C++/C# instead of Java.
Tim
Funny this subject should come up. I’ve been building my own javascript toolkit for a few months. A lot of my ideas come from the Photon toolkit. The interfaces are totally different. I’m building objects (such as one may) in javascript. There’s an obvious difference that is a big deal. Javascript only provides a front end. In almost an case you would need to communicate back to a host, probably via the HTTPXMLREQUEST object. I can imagine finding a way to hide this via interface, but face it, we are talking about a lot of work.
I’ve read that Google has done something like this, joining Java and Web applications, but I know none of the details. I’m rather doubtful that this would include anything like Swing support.
Having to do it again I wouldnt go for Java (i wasnt there when the choice was made, portability between windows and linux was the main factor). The Java stuff is slow and it seems to me the development is also slow. Maybe I don`t have all the facts but seems like it takes the GUI group forever to come up with stuff.
Luckily being on Windows we can throw hardware at the problem. Our previous generation of system based on QWindows was able to run the GUI and the runtime part on the same machine ( QNX4 single processor ). Now with the Java interface, which does have a lot more features like cut and paste but basically provided the same feature set requires a dual core minimum and it barely can keep up and doesn`t have any of the real time stuff to handle.
Ouch.
We evaluated Java as a possibility for the portable Linux reasons you mentioned. But eventually rejected it for 4 big reasons:
- It’s much slower than C++/C# at runtime esp when doing any kind of graphical animations
- Most of the C++ code that was done on the QNX side for the core of our application TCP/IP communications/internal event handling easily ported to Windows (a surprisingly few ifdef’s) saving development time on the GUI. Best of all I now only have 1 code base of C++ code to maintain if there are bug fixes/feature additions to be made.
- It seemed to be much easier to find C# graphical people than Java graphical people when making an attractive GUI.
- I once attended a lecture at a C++ conference given by Bjarne Stroustrup the creator of C++ when Java was starting to become really popular. He opened the lecture by saying “If the answer is Java, the question isn’t very interesting”. That just killed the audience and the comment has always stuck with me for some reason when thinking about Java as anything other than a hand held/portable device GUI.
There are times I wish we had a Linux option when Windows gets tempermental when customers shut down improperly but the hardware benefits are as you mentioned really nice and it’s handy to have built in browers/PDF readers etc into our GUI and when we interface to 3rd party equipment they almost always offer a Windows interface/program where not so much in Linux.
You can see a sample screen shot here of our GUI.
Tim
Nice!
Isn`t managed C# similar to Java in performance.
Mario,
The managed C# is definitely no where near what C/C++ is in terms of speed. I think it’s better than Java but I could be wrong.
Our GUI nodes typically receive anywhere between 500-1500 events (1 event = 1 ethernet packet) a second containing updates from the real time QNX nodes. At those numbers we don’t notice any performance issues on a Dual Core cpu.
Lots of events are of course updating things not currently visible (other screens) or just updating numbers so they don’t chew much CPU. The guy who did the GUI wasn’t used to handling that many updates a second so I helped streamline a few performance issues during development. For example on that screen shot in the upper right you can see a pitch/roll animation of our vehicle. Originally the guy was rotating the image each time an update came in and that just ate CPU like crazy (given 20+ updates a second). Since memory is cheap, I had the GUI guy store every animation state in RAM and then just point to the right one saving all the rotation calculations. A few things like that go a long way in C# to getting good performance.
Tim
Well, well, well… First of all, thank you guys for feedback… I’m just reading the answers… Very very interesting…
I’m still trying to understand… sorry. So, just to summarize: As I can see, you run the real-time stuffs on QNX machines but all of your GUI Apps run on Windows (or Linux)… Maybe Java or C++/C# based?. Is this correct?. And the main reason for not doing so in QNX, is…? QNX doesn’t manage Swing class?..
So, how do you communicate with QNX?, HTTPXMLREQUEST object, tcp/ip with your own protocol… or ?
Tim, that picture you show us, is based on C++ development, isn’t it? And this application is communicated with QNX via tcp/IP?
I’m realizing that I have many more questions now than before… sorry.
Is very valuable for me to have other different points of view.
We have all running on QNX. A real time proprietary SCADA, acquiring process line data, and HMI GUI also in QNX. We obviously dont’t have problems of performance in HMIs, they are safe enough to operate industrial equipment, and GUI are very nice. We run databases engine (MySQL) in QNX too and we don’t struggle more than expected…
Everything goes fine, until this idea of showing things like Tim’s screen from a browser for people who is far away from the plant, as I mentioned early.
Well… in further comment will be appreciated!
And, thank you again!!.
Regards,
JM
All the GUI and database stuff runs on Windows, it’s written in Java. To make a long story short, system was based on QNX4/Qwindows and it was decided to moved to another OS which was suppose to be Linux. They still weren’t sure about which OS to move to bug one thing was certain, the GUI being based on QWindows has to be totally redesign and recode. Hence they chose Java for maximum portability and the work was started on the interface for a special project that was doing data collection only ( no real-time ). Almost 3 years later the switch of OS hasn’t begun for the simple reason that no one knew Linux or were to start. I had been here for a year, when I mentioned hey why not go QNX6 instead of Linux. Which we did, however the Java stuff was based on Swing which is part of the Sun’s JVM and the JVM available on QNX don’t support Swing instead it supports AWT… Java portability my as… That’s why today, interfaces run on Windows while the real-time part runs on QNX.
Simple TCP/IP . Data is formatted in XML.
Since you already have all the programs done and are happy with that I would be working VERY HARD not to change that. What you could look at is provide the ability to run/install phindows from a Web interface that would take care of security/user permission issue. It would then launch phindows automagicaly with the proper option (username/session).
With the lastest version of Phindows and 6.4.0 you can use a private key that could get generated automaticaly for each session started.
With the -s option the user won’t even notice he’s using Phindows.
Mario, your insights and suggestions are very valuable… thank you. To run phindows from a web browser could be a VERY GOOD idea. I’ll investigate this option…
Finally, what do you mean with this?
“With the -s option the user won’t even notice he’s using Phindows.”
Thanks again!
JM
When Phindows is started with the -s option, phrelay will use that info to start a specified program, says phcalc. So instead of having a typical photon session in Phindows, what the user will see is a window ( the phindows windows) with only phcalc in it, no shelf, no task bar, no pdm just phcalc. For the casual user it will look like a native, windows calculator.
JM,
The screen shot you saw was the C# part of the GUI. The C++ part runs in underlying threads to do communication and other under the hood stuff.
We communicate with QNX via TCP/IP or Serial (we had a requirement to support both). For 95% of our customers, they don’t care so TCP/IP is our obvious choice for more bandwidth. For 5% of our customer serial is what they ask us to use.
We use our own protocol since we have to support serial and thus we need to do our own error detection. Our typical packet size is quite small due to the serial support (about 10-20 bytes of data).
Tim