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

Zigurana

@paffley
Hi!
The unlock passphrase is stored as a string (series of letters) in the EmulationStation settings file (I think: /home/pi/.emulationstation/es_settings.cfg).
Look for the item called 'UI_passphrase' or something like that.

The default value is 'uuddlrlrba', but you change that to any string you want. Note that you can only unlock with u (up), d (down), l (left), r (right), a, b, x, and y. So if you put a 'w' in there, you will not be able to unlock it at all.

But in any case, you will always have access to the settings file itself, to retain the possibility to change the value for 'UI_mode' to 'full' manually.

paffley

@Zigurana Thanks mate, spot on!

Zigurana

@akafox @R2dTOO @dunginhawk @Cjax08 @Capeman @EctoOne @paffley :
I've submitted a second Pull Request to introduce the Kid-UI functionality.
This will allow you to set two new metadata tags 'kidgame' and 'hidden' to either 'true' or 'false'. This value is then used to show or hide items based on the current UI-mode. For more info, see the PR.

If you want to contribute to the test-phase of this functionality, you can use the test-tool.

Repo: https://github.com/zigurana/EmulationStation
Branch: KidMode

Any and all feedback would be most appreciated!

Capeman

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

Personally, I do not see it as worthwhile to make this fully configurable via a resource file (when weighed against the extra complexity). If a good use-case arises, we could decide on another UI mode to support that.

I think having variables in the settings file where you edit your input code would be a great way to please everybody. I understand you don't want to disable adding/deleting favorites in kiosk mode by default (or at all), but a few of us really want that function without having to use a full on kids mode. Making text based variables for extra hidden content wouldn't add any complexity to the end user who would just use the defaults, but alot of us experienced users would appreciate the extra customizability.

But I may also be acting selfish, because I really, REALLY don't want my family to be able to edit my favorites, hahahahaha!

Regardless, great work and a fantastic addition to ES!

EctoOne

@zigurana Just to make this clear, i have two questions.
The UI Mode can be changed in the ES menu?
And if i want to hide the entire Retropie System, i have to add the hidden tag to all entries of that gamelist?

Zigurana

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

@zigurana Just to make this clear, i have two questions.
The UI Mode can be changed in the ES menu?

That is correct, under the UI settings, you will find a setting called UI mode, with possible values Full, Kiosk, Kid. Full is the default, normal ES interface with all menu's and options available. Choosing Kiosk will result in (most) ES menus being hidden, as well as GameListItems (games) that are explicitly hidden using the metadata Hidden=true. When Selecting Kid you get the same ES menu shielding as in Kiosk mode, but now only those menu items that are explicitly allowed via metadata tag kidgame=true are listed.

And if i want to hide the entire Retropie System, i have to add the hidden tag to all entries of that gamelist?

After reload, systems that no longer have visible entries, are not shown on the SystemListView at all. So to hide the Retropie system, you can simply 'hide' all entries (when running in kiosk or not set them to kidgame=true (=default) when running kid .
Note I just fixed a bug related to this: If none of the systems have anything to show (because you switched to Kid before setting any game to Kidgame=true), there will now be a popup after loading telling you that the system will revert to UImode = Full.

Please update before testing (run the test script again).

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!