in reply to Perl GUI

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

Replies are listed 'Best First'.
Re^2: Perl GUI
by marto (Cardinal) on Dec 29, 2024 at 12:03 UTC

    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.

[reply]
      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]

        And accessible on other devices without modification. Note that home assistant exists, supports all sorts of sensors (as well as many other integrations) provides all of this functionally out of the box.

[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]
        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.

        Behold! I present unto thee, WebSockets!

[reply]

In Section Seekers of Perl Wisdom