Kids & Kiosk Mode, coming back [testers needed!]

Rion

@zigurana Will the kiosk and kids mode have the ability to hide shutdown and only show reboot?

paffley

Maybe in a future update, we could have a .cfg file with some true/false values to choose what menu/game items are displayed. Just a thought, that would prolly please everyone as it looks like different people are requiring different options to be displayed/hidden.

Keep up the great work @Zigurana ....everything's looking fab!

pjft

@rion I'm not going to answer for @Zigurana , but what's the use case here? An always on set up? Just curious.

Also, if you don't have a shutdown option, how will you shut down RetroPie? An external button or something?

Currently Kiosk mode already only shows Reboot and Shutdown.

@Zigurana a note, actually. Unsure if relevant or not, but I recall that "F4" on the keyboard will exit ES. Do you want to keep that in Kiosk mode, since you're no longer allowing the ability to exit from ES?

It doesn't affect me as I don't have a keyboard plugged in, but thought I'd raise it.

Thanks! :)

Rion

@pjft This is just so my kid don't accidentally shutdown the Pi when im not home.

It's always on behind the Tv and my Wife is not so tech savvy.

But i can see how this is not useful for everyone but useful for some.

If i wanted to shut it down i just input the code and I'm back to full for shutdown, F4 from wireless mini keyboard or SSH.

Zigurana

@paffley , @Rion ,
While I agree that working with a separate resource file (the settings.cfg or otherwise) is the most flexible way to go, it is not something I am considering for this PR.

I am somewhat debating to removing the start-menu altogether for Kid-mode, and let users define a custom system with an item for shutdown or reboot, if they want to. Not sure about that yet, as it would require many ( most?) of them to dig into how the systems work, and how to define a custom entry. Not a bad thing in and of itself (more ppl tinkering is more better ;-)), but a hassle nonetheless. I'd like some feedback on that.

One thing I want to prevent is to overload ES with a myriad of options / functions that are only used by a very select group, but complicate things for all. So a set of menu options just for further defining kid-mode behavior is not my preferred solution here. Expanding the settings.cfg file is (slightly) better.

Rion

@zigurana A settings.cfg is probably the best option. As you said these settings are for a selected few and not everyone.

It wouldn't be a problem at all if i have to define a few extra setting in an cfg file.

EctoOne

@zigurana I believe that i already asked if it would be possible to choose what can be hidden with a cfg file. Even tho i don't really use the ES menu anymore, it would be great if i could hide options that i (probably) never change again.

paffley

Thanks @Zigurana I totally agree. Good explanation. Keep up the super work! Maybe the defaults could be stored in a settings.cfg file as you say in a future update and more advanced users can edit as appropriate to there build. But for now I think its great as-is.

It was just a thought and I'm not expecting anything from you as you have done amazing already with all your work and we appreciate it al highly. Thanks again.

pjft

@zigurana said in Kids & Kiosk Mode, coming back [testers needed!]:

let users define a custom system with an item for shutdown or reboot, if they want to

Well... if you know that's a valid use case, I'm not sure this is the most reasonable approach. For that purpose, you might as well just have a setting in the settings file (and potentially not on the menu) to enable or disable the start menu altogether from the Kids menu. It's slightly more user friendly to just change a flag in the settings file (even better if it's on the menu, though I understand the "clutter" angle) than to have them create a custom system and entry to do something that's already natively supported by ES. Not to mention that that entry would then show up in all other views.

Just a thought. :)

Zigurana

@pjft yeah, but then we could have another setting like 'show only on Kid-mode' or another Metadata tag,.. Nah, just kidding! 😋 It's a dead end, I agree.

It only crossed my mind because my kids have some difficulty finding the small menus of ES on the handheld, and a separate system could make it nice and obvious.

I' think I'll go with an optional settings entry for hideShutDown

Regarding physical keyboards (pressing F4 to drop to cli), I had planned to keep that functionality intact. That issue is easily solved by removing the keyboard itself, or not?

pjft

@zigurana Yes, it's not an issue. I'm just wondering about people who might run this on a desktop (Xubuntu or Windows), or even a laptop.

But hey, it's minimal. I just raised it in case you hadn't considered the F4 alternative and whether that would or would not be an issue.

I have no problem whatsoever with that, as I run it on the Pi and I have no keyboard attached to it :)

I think it's safe to keep it, and then we see if people complain.

AmadhiX

First off, thanks for the great work on this! I can't wait for the PR to go through so this stuff is available on the master.

While you're locking out ES menu options, I'd like to humbly request a "scraper lock" option. This would disable the Scraper (and maybe "Edit This Game's Metadata"), but leave the other ES options alone.

My use case for this is setting up a system for reasonably savvy adults who might want to change their system volume, try out a new theme, or configure a different kind of controller. I wouldn't want to prevent those things by turning on Kiosk mode, especially if I don't know what controller they'll be using. Certain options, like the VRAM limit, might be potentially disruptive, but are basically recoverable.

But that Scraper... Unless they're familiar with ES setup, they aren't going to know what that does, and it's at the very top of the menu, innocent and enticing. It's capable of wiping out hours of hand curated, difficult-to-recover metadata, and it doesn't give much warning.

I think it would be good to be able to protect that with a setting that you have to deliberately turn off, ideally with some kind of "be careful with this" warning. Also, once the system is all setup, the Scraper just takes up space on the menus, but that's minor compared to the above.

Thanks again for the existing effort and for any consideration on this!

Zigurana

Hi @AmadhiX ,
Thanks for the feedback, did you encounter any issue while testing?

Regarding further flexibility of the items to either show or hide: While I understand the use-case you are describing here, the request is beyond the scope current PR.
What I am trying to cater for here is a limited set of the most common scenarios, and frankly, yours will not easily make the cut.

A better solution for you would be to introduce a separate resource file where all items can be manually selected/deselected, depending on the goal that the end-user has in mind. Like proposed by @Rion, @EctoOne, and @paffley earlier in this thread. That however, is a completely new addition to this PR, and I will not pick that up anytime soon. Sorry.
A quick fix would be to just make all gamelist.xml files read-only, that would prevent alterations from within ES. Or use backups, to restore the systems if/when folks destroy it. It will also affect the recorded play history though.

If you want to get your hands dirty, it's very easy to remove the scraper menu option altogether, just comment out this line, recompile ES, and you are good to go.

AmadhiX

Hi @Zigurana,

Thanks for the detailed response, even if the answer was no. :P

I haven't had a chance to test out the latest yet, but I've been keeping an eye on the kid/kiosk branch for a bit and am really glad someone is "bringing it home." I'll check it out with @meleu's tool and post my findings.

I don't think read-only xml files will prevent images from being overwritten, and I don't necessarily want to recompile as a one-off, but I really appreciate your taking the time to offer up those solutions. Maybe one of these days I'll have the time to actually dive into ES and put together a PR of my own. :)

Thanks again!

paffley

@Zigurana I'm now running the kiosk mode from the official repo and its 100% !

The only thing I would love to see (on my personal build) would be the 'Theme' select option as I like to flick through different themes depending on my mood ha!

If you ever decide to create the .cfg file for what is to be displayed (true/false) as discussed previously, please let me know and ill test for you.

Keep up the great work guys, retropie has come so far! You guys are a credit to the scene.

darknior

Woaw i miss this thread before, cool to see all you tests :D
The dream will become reality !!!
Winter is coming, and with it Kiosk Mode <3

Zigurana

This has just been merged into the master branch,~~so if you update from source, you will get it!~~

Edit: I was wrong, see BuZz's response below.

Thanks everyone, for testing this out!

BuZz

@zigurana They will need to update retropie-setup and install emulationstation-dev from experimental or else they won't get it since it's not yet merged to the stable branch which we track from the main emulationstation module

Cjax08

@buzz I’ve been trying to follow this the best I can and I know I already updated from source a while back and got the kiosk UI mode added to my build by just updating emulation station and retropie setup. What exactly is it that is still only included in the dev branch? At this point should I just wait and it’ll be merged to the master soon? I’m assuming it’s the finished kids mode and whatever goodies come with that.

dsstrainer

@paffley 100% agreed with paffley!