[PATCH] support battery-charge-state-dependent battery frame icon
Martin Dengler
martin at martindengler.com
Thu Apr 17 06:19:10 EDT 2008
[apart from some feedback on your first two comments I can get a new
patch out later today -- so can you focus on those sections please?]
On Thu, Apr 17, 2008 at 12:00:48AM -0400, Eben Eliason wrote:
> So, I'm not the authoritative source on this, but I'll toss in my thoughts...
>
> > + lvl = self._level
> > + secondary_text = ''
> > + status_text = '%s%%' % lvl
>
> I would avoid declaring variables unless they really make serve a
> purpose.
The purpose of this variable (lvl) is twofold:
1) Read things once: it's not threadsafe to access self._level twice
and expect to read the same value. Yes, python doesn't have the same
thread support as other languages, and maybe self._level doesn't
change very often at all, but why write code that once in a while, for
one or two people, is going to make the text show "50%" and the slider
show "49%"? It'd be messy, and it's easy to avoid by just reading the
_level once;
2) once I started getting a little (yes, overly) paraoid by #1 (I
originally wrote the code just as you've recommended, FWIW :)), I
realized some would think it's a bit nicer to not have multiple reads
for the same value, and that a shorter variable name would make the
code indentation a bit nicer. This point is admittedly very minor,
but adds a tiny bit of weight to #1.
The purpose of status_text and secondary_text is different: rather
than set them in each branch of the conditional, or (I think worse,
but IIUC you prefer), do something with it "inline" in each branch, I
just mutate it in the (few) branches of the conditional as appropriate
and then do something, once, with it.
Compare these structures:
1.
sometext = ''
if a:
...
elif b:
if b1:
...
else:
sometext = 'foo'
dosomething(sometext)
...is, all other things being equals, better than (less duplication):
2.
if a:
sometext = ''
...
elif b:
sometext = ''
if b1:
...
else:
sometext = 'foo'
dosomething(sometext)
...and probably even "more better" (ugh, but perhaps you know what I
mean) than:
3.
if a:
dosomething('')
...
elif b:
dosomething('')
if b1:
...
else:
dosomething('foo')
I think #3 is particularly bad because you now make a maintainer do
this:
if a:
dosomething('')
dosomethingelse('')
...
elif b:
dosomething('')
dosomethingelse(') <-- haha look...found this bug when proofreading!
if b1:
...
else:
dosomething('foo')
dosomethingelse('foo')
rather than just:
sometext = ''
if a:
...
elif b:
if b1:
...
else:
sometext = 'foo'
dosomething(sometext)
dosomethingelse(sometext)
Am I overlooking some other consideration(s)?
> > + if lvl <= 15:
> > + secondary_text = _('Very little power remaining')
>
> This is probably the correct place to fire off a notification, and
> perhaps even badge the icon with a warning badge. Of course, all of
> the necessary components aren't in place for this to work perfectly
> just yet...not sure if it's worth adding at this point. It would
> depend, at a minimum on Eric Burns' forthcoming notification patch for
> specifying the appropriate screen corner.
I could add the badge and the notification, sure. Do you want that in
a separate patch? Adding a badge is trivial (you want the
emblem-warning.svg, I guess, not emblem-notification.svg or anything
forthcoming, right?). It'd be a bit quicker if I could do the
notification in a separate patch, I think, as I'm not sure how to do
that yet.
> > + minutes = _('m')
> > + hours = _('h')
> > + #TODO: make this less of an wild/educated guess
> > + minutes_left = int(lvl / 0.59)
> > + if minutes_left < 60:
> > + guess_text = '%s%s' % (minutes_left, minutes)
> > + else:
> > + hours_left = minutes_left / 60
> > + mins_leftover = minutes_left % 60
> > + guess_text = '%s%s%s%s' % (hours_left, hours,
> > + mins_leftover, minutes)
>
> I think I'd prefer the format "1:23 remaining", without the extra 'h'
> and 'm' business.
Ok -- your design had the "3 hours remaining", so I probably shouldn't
have played with your design without asking you first. I'll change it
to just H:mm (as you also request with your code below).
> Also, I'd use a more descriptive variable name like
> time_left; guess_text is somewhat ambiguous, apart from the context.
Sure -- I wanted the variable name to scream "this code knows that
it's not doing a good job of calculating the time remaining", but of
course it's a very tiny thing to change.
> In fact, I might forego that string completely in favor of calculating
> hours_left and mins_left variables, and then directly doing:
>
> self.props.secondary_text = '%d:%.2d %s' + (hours, mins,
> _('remaining'))
Cool! Will do.
> > + mins_leftover = minutes_left % 60
>
> I would personally just overwrite the minutes_left variable here
> instead of creating a new one.
Yeah, I was close to doing that too and felt for some reason it was a
bit sloppy, but happy to have confirmation that it's preferable!
> Of course, many of my changes depend on whether or not people think
> that the guesswork employed here is worth implementing.
Exactly. I think we've given enough people enough time to object, and
I haven't heard any (though have received some excellent suggestions
as to where The Right Way might be being implemented), and - as I
noted in my patch/commit comment - the algorithm is close to what a
non-techy human might do, so at least isn't going to be wrong in a
surprising (disappointing) way. So let's just do it. I've been using
it for a few days now and it's not offensive (I don't find myself
thinking "ooooh, I know that's wrong and it's wrong by...let's
see...just working it out..." etc. etc.).
> - Eben
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080417/bb4e3568/attachment.sig>
More information about the Devel
mailing list