added: Inhibit screensaver builtin

[arnova]

Description

This implements a new builtin to prevent the screensaver from starting. Currently there are other "hacks" out there to accomplish this, but with this builtin there is a "proper" way now.

Motivation and Context

It implements a new feature

How Has This Been Tested?

Some very sophisticated Python scripting ;-)

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[lrusak]

I'd rather not add to the complexity of the screensaver stuff until we can properly break out the screensaver (and dpms) from CApplication (which is what #16269 intends to solve)

[arnova]

@lrusak : No problem. Will rebase on your work as soon as it's in mainline

[AlwinEsch]

Maybe make it a more detailed, e.g.:

///   \table_row2_l{
///     <b>`InhibitScreensaver(yesNo)`</b>
///     ,
///     Inhibit the screensaver
///     @param[in] yesNo   value with "true" or "false" to inhibit or allow screensaver (leaved empty force to true)
///   }

[AlwinEsch]

Otherwise I find this request very good and helpful for my web browser addon 😊 (to avoid screensaver on webvideo)

[arnova]

@AlwinEsch : Thanks for the review I'll incorporate your suggestions in this PR.

[garbear]

A good next step would be to turn the inhibition into a context manager so that multiple clients could use the builtin

[arnova]

@garbear: Not sure what you mean by that. Why isn't it possible now to use it by multiple clients?

[eigendude]

Alice: inhibit
Bob: inhibit
Alice: uninhibit
-> Bob still thinks shutdown is inhibited

[eigendude]

(work account)

to fix this, you can use an object with context that reserves a "handle" given to it by an inhibitor. Both Alice and Bob would acquire a handle, and shutdown is inhibited as long as handles are outstanding. that way, Alice and Bob can operate without knowing about each other

[arnova]

(work account)

to fix this, you can use an object with context that reserves a "handle" given to it by an inhibitor. Both Alice and Bob would acquire a handle, and shutdown is inhibited as long as handles are outstanding. that way, Alice and Bob can operate without knowing about each other

You simply mean using a refcounter then, right? Do note that we need to do this for other stuff as well then like the shutdown inhibiter builtin.

[garbear]

Yes, I recommend adding refcounting where two agents want to access the shared state.

[arnova]

Yes, I recommend adding refcounting where two agents want to access the shared state.

@garbear : After some thought, I think this should be done separately from this PR since it also affects several other builtins (like the shutdown inhibiter).

[garbear]

sounds good