- Arch xscreensaver unable to find any alternative code#
- Arch xscreensaver unable to find any alternative windows#
I just question whether that's a real use-case.
Arch xscreensaver unable to find any alternative code#
The only case I can think of where the reentrant style helps is when I'm trying to manage the screensaver bit and a piece of third-party code is also trying to manage the bit. They don't have to worry about calling disable-screensaver more than once, and they don't have to worry about calling enable-screensaver too many times. I think the non-reentrant solution is simpler for web authors.
Arch xscreensaver unable to find any alternative windows#
The interaction with other windows and iframes is exactly the same in both cases. In the non-reentrant case, a document's 'lock the screensaver' bit is unset as soon as you call enableScreenSaver once. The only difference AIUI between these two is that in the reentrant case, the document's 'lock the screensaver' bit becomes unset only if you call unlock() as many times as you've called lock(). Each document may choose to lock out the screensaver, and if any visible document has done this, the screensaver doesn't show. This is similar to the lock-based API you proposed (I'll call this the reentrant API, since it acts like a reentrant lock). So "disableScreenSaver" in some sense "locks out" the screensaver. In what I've been thinking, each document may "disableScreenSaver", and if any visible document has done this, then the screensaver doesn't show. Maybe we're actually talking about the same thing, Chris. I totally agree with you about preferring simplicity over generalization to possibly-uncommon cases, but in this case wake-lock isn't any more complex IMHO, is clearer about effects and more extensible. I don't know about the pushState() discussion, but in this case I don't think a wake-lock style API is more complicated at all. > design we chose being a problem in practice.) > without stomping on each other - but I haven't heard about the simpler > something which allows two independent pieces of code to call pushState > (People made the same argument with history.pushState - we should do > state, but is that really a common case we should design around? > change it) in a document both trying to manage the screen's lock/unlock
> I can imagine two components (one of which is third-party, so you can't Who gets to win, the power-wasters or power-savers? Why? The API doesn't make that clear. It's not obvious to me why an iframe shouldn't be able to stomp its parent's disableScreenSaver() request. The question is whether we need an API like > Obviously an iframe shouldn't be able to stomp its parent's > I was thinking that internally, we'd maintain such a data structure. (In reply to Justin Lebar from comment #10)
0 kommentar(er)
