<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 11:12 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class=""><br>
On 19 November 2015 at 19:05, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> I feel like there is no need to tie it to a surface. In Wayland the client<br>
> is always notified of any changes to it's state, so it can update the<br>
> screensaver object to match. (destruction of the screensaver object would of<br>
> course remove the inhibit).<br>
><br>
> The surface may be necessary to indicate if only one output is to have the<br>
> screensaver inhibited, but I think wayland clients are aware of which output<br>
> their surfaces are on so instead the output could be indicated directly.<br>
<br>
</span>By default it should be tied to a surface.<br></blockquote><div><br></div><div>Yes I believe that will work, but will it be possible to inhibit the screensaver without putting anything visible on the screen?<br><br></div><div>Probably not a big deal, actually. The only application I can really think of for this is to force presentation of some other application that does not use the inhibit api, and such a tool may still map some kind of (normally invisible) overlay for popup controls, so the inhibit could be tied to that.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
>>>>>>> In X11, various getter functions are provided for the application to<br>
>>>>>>> poll inhibition status.  For Wayland, instead of getters, the current<br>
>>>>>>> state is just be pushed to the client when the inhibitor global is<br>
>>>>>>> bound, and then updates pushed if/when the status changes.<br>
>>>>>>><br>
>>>>>><br>
>>>>>> This makes sense, and follows "standard" wayland practice<br>
><br>
><br>
> I don't see any reason for a client to know about any other clients<br>
> inhibiting the screensaver, and this might be a security leak too.<br>
<br>
</span>Yes, seems a bit pointless.<br>
<span class=""><br>
>>>>>>> A corresponding uninhibit API will be added as well.  For example, a<br>
>>>>>>> movie player may wish to inhibit while a video is playing but<br>
>>>>>>> uninhibit<br>
>>>>>>> when it is paused.<br>
<br>
</span>Just make the inhibit request return a new object, which upon destroy,<br>
removes the inhibition. That way you don't even have duplicate<br>
codepaths for client exiting uncleanly vs. client removed inhibition.<br>
<span class=""><br>
> The screensaver object should have several requests. One of them turns the<br>
> inhibit on/off.<br>
<br>
</span>The screensaver object and the inhibition object are not the same thing.<br>
<span class=""><br>
>>>> Yes I think it makes sense to add this to its own extension. A<br>
>>>> "wp_inhibiter" in a inhibiter XML file that inhibit things.<br>
><br>
><br>
> Please don't use any name that does not have the word "screensaver" in it,<br>
> because that is the word programmers are going to look for. My suggestion is<br>
> "wpz_screensaver_v1" (or whatever the rules for experimental protocols are).<br>
> I suspect this api will quickly get enhanced with other api (such as events<br>
> when the screensaver turns on/off), so I would not use the word "inhibit" at<br>
> all.<br>
<br>
</span>It's not a screensaver API, it's a screensaver/blanking inhibition<br>
API. Everyone else already uses 'inhibit'.<br></blockquote><div><br></div><div>Ok I think I see where you are going. I would still have the word "screensaver" in the name, ie "screensaver_inhibit". Though of course it is going to inhibit other things, but I'm afraid the fact that people searching for this api are going to look for the word "screensaver" about 100 times more often than they look for the word "inhibit" means it had better be in the name. Thus zwp_screensaver_inhibit_v1 is probably the name.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Absolutely it should by default inhibit any kind of notifier or any other<br>
> changes to the display not triggered by the user (it also should NOT inhibit<br>
> changes that the user triggers, such as hitting a shortcut key that creates<br>
> a popup).<br>
><br>
> Among these changes that must be inhibited are "things that have not been<br>
> invented yet but may appear in a future desktop". Therefore a per-thing api<br>
> to inhibit them is not going to work and this must inhibit them all.<br>
><br>
> The api can be enhanced in the future if you want finer control over what is<br>
> inhibited.<br>
<br>
</span>No. People want to receive notifications whilst they watch movies.<br>
Presentation is something else altogether.<br></blockquote><div><br></div><div>I may have been too specific about what is disabled. Let me try to be more careful:<br><br></div><div>There are two sets.<br><br>A = "things that a user watching a movie does not want to happen".<br><br></div><div>B = "things that exist in future wayland desktop environments but have not been invented yet and thus there is no api for".<br><br></div><div>I propose the following:<br><br></div><div>1. The intersection of these two sets is not empty.<br></div><div><br></div><div>2. It is desirable for the inhibit api to be capable of disabling everything in set A.<br><br></div><div>3. It is a lot easier to describe the set A than to describe this intersection, since the second description requires a date that determines the contents of set B (it reduces over time as things are invented).<br><br></div><div>Therefore there should be a way to inhibit all of A with a single api.<br><br>I propose that this be the default initial state of inhibit. As this contains everything, all remaining controls can be done by removing different subsets of A from the inhibit. New subsets can be added or new things added to existing subsets as they are invented, without breaking any clients expectations.<br><br><br></div></div></div></div>