Hi,
On 19 November 2015 at 19:05, Bill Spitzak <spit...@gmail.com> wrote:
> I feel like there is no need to tie it to a surface. In Wayland the client
> is always notified of any changes to it's state, so it can update the
> screensaver object to match. (destruction of the screensaver object would of
> course remove the inhibit).
>
> The surface may be necessary to indicate if only one output is to have the
> screensaver inhibited, but I think wayland clients are aware of which output
> their surfaces are on so instead the output could be indicated directly.
By default it should be tied to a surface.
>>>>>>> In X11, various getter functions are provided for the application to
>>>>>>> poll inhibition status. For Wayland, instead of getters, the current
>>>>>>> state is just be pushed to the client when the inhibitor global is
>>>>>>> bound, and then updates pushed if/when the status changes.
>>>>>>>
>>>>>>
>>>>>> This makes sense, and follows "standard" wayland practice
>
>
> I don't see any reason for a client to know about any other clients
> inhibiting the screensaver, and this might be a security leak too.
Yes, seems a bit pointless.
>>>>>>> A corresponding uninhibit API will be added as well. For example, a
>>>>>>> movie player may wish to inhibit while a video is playing but
>>>>>>> uninhibit
>>>>>>> when it is paused.
Just make the inhibit request return a new object, which upon destroy,
removes the inhibition. That way you don't even have duplicate
codepaths for client exiting uncleanly vs. client removed inhibition.
> The screensaver object should have several requests. One of them turns the
> inhibit on/off.
The screensaver object and the inhibition object are not the same thing.
>>>> Yes I think it makes sense to add this to its own extension. A
>>>> "wp_inhibiter" in a inhibiter XML file that inhibit things.
>
>
> Please don't use any name that does not have the word "screensaver" in it,
> because that is the word programmers are going to look for. My suggestion is
> "wpz_screensaver_v1" (or whatever the rules for experimental protocols are).
> I suspect this api will quickly get enhanced with other api (such as events
> when the screensaver turns on/off), so I would not use the word "inhibit" at
> all.
It's not a screensaver API, it's a screensaver/blanking inhibition
API. Everyone else already uses 'inhibit'.
I don't see the point in adding events until we desperately need them.
What happens if you only blank one screen but leave the others on? And
so on.
>>> Makes sense ("potentially" could inhibit other things depending on scope
>>> and how it grows)
>
> Absolutely it should by default inhibit any kind of notifier or any other
> changes to the display not triggered by the user (it also should NOT inhibit
> changes that the user triggers, such as hitting a shortcut key that creates
> a popup).
>
> Among these changes that must be inhibited are "things that have not been
> invented yet but may appear in a future desktop". Therefore a per-thing api
> to inhibit them is not going to work and this must inhibit them all.
>
> The api can be enhanced in the future if you want finer control over what is
> inhibited.
No. People want to receive notifications whilst they watch movies.
Presentation is something else altogether.
>>>> Not so sure about the scope though. If its not about surfaces on outputs
>>>> or input devices or focus or display protocol things it should just be a
>>>> D-Bus protocol.
>
> No please don't! It has to inhibit everything by default that you would
> think that a program trying to disable the screensaver is also trying to
> disable. It does not matter where or how they are implemented.
No, it doesn't.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
