|
|
Created:
8 years, 6 months ago by Mike Mammarella Modified:
8 years, 6 months ago CC:
chromium-reviews, joi+watch-content_chromium.org, darin-cc_chromium.org, jam, jochen+watch-content_chromium.org, Randy Smith (Not in Mondays) Base URL:
svn://svn.chromium.org/chrome/trunk/src/ Visibility:
Public. |
DescriptionAdd a new version of the power save blocker class, to be implemented for all platforms in subsequent CLs.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=140460
Patch Set 1 #Patch Set 2 : #
Total comments: 2
Patch Set 3 : #
Total comments: 4
Patch Set 4 : #
Total comments: 5
Patch Set 5 : #
Total comments: 2
Messages
Total messages: 16 (0 generated)
https://chromiumcodereview.appspot.com/10511021/diff/1003/content/browser/pow... File content/browser/power_save_blocker2.h (right): https://chromiumcodereview.appspot.com/10511021/diff/1003/content/browser/pow... content/browser/power_save_blocker2.h:43: PowerSaveBlockerImpl* impl; I could also make this a scoped_refptr if it turns out that's what all the implementations want. I am pretty sure the Linux and Mac versions will want that, for instance.
https://chromiumcodereview.appspot.com/10511021/diff/6001/content/browser/pow... File content/browser/power_save_blocker2.h (right): https://chromiumcodereview.appspot.com/10511021/diff/6001/content/browser/pow... content/browser/power_save_blocker2.h:32: explicit PowerSaveBlocker2(PowerSaveBlockerType type); Can we get a string to describe why? https://chromiumcodereview.appspot.com/10511021/diff/6001/content/browser/pow... content/browser/power_save_blocker2.h:41: PowerSaveBlockerImpl* impl; Huh. I was going to go for #ifdef-ed member variables here, but I'm OK with this.
https://chromiumcodereview.appspot.com/10511021/diff/1003/content/browser/pow... File content/browser/power_save_blocker2.h (right): https://chromiumcodereview.appspot.com/10511021/diff/1003/content/browser/pow... content/browser/power_save_blocker2.h:43: PowerSaveBlockerImpl* impl; I have baggage per-blocker, so I'd prefer a scoped_ptr. Worst case I'll take the raw pointer and delete it in the destructor.
https://chromiumcodereview.appspot.com/10511021/diff/6001/content/browser/pow... File content/browser/power_save_blocker2.h (right): https://chromiumcodereview.appspot.com/10511021/diff/6001/content/browser/pow... content/browser/power_save_blocker2.h:32: explicit PowerSaveBlocker2(PowerSaveBlockerType type); On 2012/06/04 21:58:52, Avi wrote: > Can we get a string to describe why? Done. https://chromiumcodereview.appspot.com/10511021/diff/6001/content/browser/pow... content/browser/power_save_blocker2.h:41: PowerSaveBlockerImpl* impl; On 2012/06/04 21:58:52, Avi wrote: > Huh. I was going to go for #ifdef-ed member variables here, but I'm OK with > this. We could do that too I suppose. In the Linux version (which I haven't actually started on yet) I am pretty sure I'll want a refcounted delegate with a different lifetime to pass in messages to another thread, and that's where all the real state will be anyway. So I figured it's likely that other implementations could do that too...
https://chromiumcodereview.appspot.com/10511021/diff/4002/content/content_bro... File content/content_browser.gypi (right): https://chromiumcodereview.appspot.com/10511021/diff/4002/content/content_bro... content/content_browser.gypi:441: 'browser/power_save_blocker2.h', Can we just use the same file as before so that there's no need to rename the file at the end?
https://chromiumcodereview.appspot.com/10511021/diff/4002/content/browser/pow... File content/browser/power_save_blocker2.h (right): https://chromiumcodereview.appspot.com/10511021/diff/4002/content/browser/pow... content/browser/power_save_blocker2.h:16: class CONTENT_EXPORT PowerSaveBlocker2 { ... and I believe this now has to be part of the content namespace.
I'd be good implementing this. LGTM
https://chromiumcodereview.appspot.com/10511021/diff/4002/content/content_bro... File content/content_browser.gypi (right): https://chromiumcodereview.appspot.com/10511021/diff/4002/content/content_bro... content/content_browser.gypi:441: 'browser/power_save_blocker2.h', Clever! I like it, as long as we comment PowerSaveBlocker as "the deprecated way" and PowerSaveBlocker2 as "the way that doesn't work yet".
https://chromiumcodereview.appspot.com/10511021/diff/4002/content/browser/pow... File content/browser/power_save_blocker2.h (right): https://chromiumcodereview.appspot.com/10511021/diff/4002/content/browser/pow... content/browser/power_save_blocker2.h:16: class CONTENT_EXPORT PowerSaveBlocker2 { On 2012/06/04 23:34:48, rvargas wrote: > ... and I believe this now has to be part of the content namespace. Done. https://chromiumcodereview.appspot.com/10511021/diff/4002/content/content_bro... File content/content_browser.gypi (right): https://chromiumcodereview.appspot.com/10511021/diff/4002/content/content_bro... content/content_browser.gypi:441: 'browser/power_save_blocker2.h', On 2012/06/04 23:28:30, rvargas wrote: > Can we just use the same file as before so that there's no need to rename the > file at the end? Done.
LGTM
LGTM! Whoo! Ready to implement.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/mdm@chromium.org/10511021/9002
https://chromiumcodereview.appspot.com/10511021/diff/9002/content/browser/pow... File content/browser/power_save_blocker.h (right): https://chromiumcodereview.appspot.com/10511021/diff/9002/content/browser/pow... content/browser/power_save_blocker.h:96: scoped_refptr<Delegate> delegate; nit: this should be delegate_
On 2012/06/05 00:31:19, Avi wrote: > LGTM! Whoo! Ready to implement. I see what you did here. You need a shared refptr so you can toss the implementation objects across to a different thread... clever!
Yep, that's why I wanted scoped_refptr. :) https://chromiumcodereview.appspot.com/10511021/diff/9002/content/browser/pow... File content/browser/power_save_blocker.h (right): https://chromiumcodereview.appspot.com/10511021/diff/9002/content/browser/pow... content/browser/power_save_blocker.h:96: scoped_refptr<Delegate> delegate; On 2012/06/05 00:48:50, rvargas wrote: > nit: this should be delegate_ Ah yes, so it should. I'll wait for the bots to finish compiling, cancel the CQ, and commit by hand with the _ here.
On 2012/06/05 01:02:12, Mike Mammarella wrote: > Yep, that's why I wanted scoped_refptr. :) And I need it too, for the same reason. You, sir, are more forward-looking than me. |