Perl GUI

[Bod]

I am planning a "hobby project" based around a Raspberry Pi...

For this project, I need a relatively simple but aesthetically modern GUI to fill the complete screen, graphically provide some on-screen information (temperatures, lamp states, etc) and look more like a touch screen than a computer screen.

What do you suggest for the GUI?

I have dabbled with Tk in the past, but I know there are some more modern alternatives available, so I am open to suggestions please...

[bliako]

mid-late 90s I created a GUI based on java applets and "image maps" which was an image with sensitive areas which called a function callback when clicked. With this I created a gui for a central heating controller with knobs and sliders only. If you do not require textual user input, use this to create a unique look, organic i called it, totally unconstraint by the gui widgets on offer. Edit: of course java applets are long unsupported but you can create something similar with Tk i guess.

A more realistic approach is to use an html front-end with a mojolicious backend. Html offers all the widgets you need plus it is the easiest to create custom widgets. It can be accessed locally or remotely by any browser, hence any-OS.

[NERDVANA]

OpenGL::Sandbox and X11::GLX::DWIM, but I'm biased :-)

[harangzsolt33]

If this Raspberry Pi has Linux on it, you could download and install a program called "yad." It allows you to open a tiny web browser in window that has no "decoration" around it, which means it has no title bar and frame and status bar. It's just a page. If the web page contains a single image, then all you see is one image on the screen. You can tell it to place this webpage on top of all other windows. You can tell it where to place it on the screen. The only disadvantage is that when you interact with what's on the screen, the program "yad" doesn't fire a live signal to your perl program. Instead it can either collect all the activity you've done and then dump it to stdout when you close it or exit, OR you can tell it to exit immediately after a click, so the program will close each time you click a button or press an image. This means that you'll have to call yad again to open the window and show the next page or next activity. This wouldn't be ideal for a paint software or a temperature monitor where you have constant live communication between your perl program and the user interface, because yad doesn't do that. You can call yad and then interact with the GUI and then it closes and sends feedback to your perl program, and then it can do something with it, collect a bunch of data and build a dynamic webpage and call yad to display the new information. I don't think this is ideal for you, but I just thought I would mention it as an alternative idea. I am curiously waiting for some of the experts to chime in and share how this problem is supposed to be solved "the right way."

Read more about yad: https://www.systutorials.com/docs/linux/man/1-yad/
You may want to use some of these options: --html --uri --print-uri --undecorated --on-top --fullscreen --maximized

[marto]

No need to install anything extra, the default browser (like most) supports Kiosk mode and progressive web apps. A browser is a sound suggestion based on what was posted.

[Bod]

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.

[harangzsolt33]

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.