A browser is a sound suggestion based on what was posted
Yes! I feel you are right...
Even if Tk is a better option to start with, a browser solution will be much quicker and easier to modify later if and when the scope of the project expands.
| [reply] |
| [reply] |
I understand that kiosk mode opens the browser in full screen, but that's not the main issue here. A browser window is not sufficient when a GUI requires constant live communication with the Perl program. Sure, you can write a webpage that sends stuff over the internet, and then somewhere your perl program captures that. And you could even install a web server package. But you said you didn't want to install anything extra, so... Anyway, can you imagine a paint software or a stock chart viewer where live data communication is required, and your perl program fetches the data and has to display it live on the screen? I don't know how that would work. In the case of the original post, maybe a live connection isn't necessary, because the temperature doesn't fluctuate or change so rapidly, but still... I'm not sure how one would solve this problem if more data was involved and live display was required. | [reply] |
A browser window is not sufficient when a GUI requires constant live communication with the Perl program.
It is if the web service is running on the localhost. I did this years ago. I created a Dancer2 app with SQLite backend that was a full blown indoor grow operation. The front end was a browser window with a single page. All calls were made with jQuery to the webapp. The front end had several widgets that you could move around and organize, and interacted with the GPIO to turn on/off lamps, humidifiers, fans etc.
All this ran on a Raspberry Pi with a 5" screen, but I could also connect to it remotely which is a big plus.
I never did completely finish or polish the project, but it can be seen at RPi::EnvUI.
| [reply] |
"A browser window is not sufficient when a GUI requires constant live communication with the Perl program."
False. Front end using web sockets or pushing/pulling JSON from a perl back end, updating the GUI in real time. This is incredibly common.
"And you could even install a web server package."
My web perl framework of choice (Mojolicious) ships with everything needed to develop and run, including a web server.
"But you said you didn't want to install anything extra, so..."
Quote where I wrote this?
"Anyway, can you imagine a paint software or a stock chart viewer where live data communication is required, and your perl program fetches the data and has to display it live on the screen? I don't know how that would work"
Well, we've been round this loop a few times, you're not particularly knowledgeable and push back against any suggestions regarding modern software or development methods.
| [reply] |
| [reply] |
