Any clue how to reproduce that?

first: landscape mode and switcher menu. Then I rotate phone to portrait for about 1s (I have disabled rotation animation) and back to landscape just before hildon rotate.

I have a bug report or a feature request for the calculator (not sure how the stock one behaved).

I often find myself typing same expression multiple times because I keep forgetting that "Clear till roll" does not clear an unfinished expression (i.e. without "=") from memory. This can lead to strange looking results, and the uncertainty usually makes me use dc instead.

Here are some examples (C stands for "Clear till roll", B for Backspace):

input: 2 * 3 C B 4 =
result: 4 = 8

input: 2 * 3 C B 4 * 5 =
result: 4 * 5 = 40

input: 2 * 3 * C B 4 =
result: 4 = 24

input: 2 * 3 * C B 4 * 5 =
result: 4 * 5 = 120

What I am requesting is to make it obvious what has been typed into the calculator, for example by making the "Clear till roll" button clear the unfinished expression from memory (and probably making the input box clearable in one press of Backspace, for convenience) or not clear the unfinished expression from the till roll.

Well, I noticed strange behavior of the latest battery applet. It reports 5 mAh (of ~1250), but sometimes the battery icon is green (as if ~10% was left), sometimes, for a while, it gets partially red (as if <5% with advanced-power) Should it be like that?

Battery has been reading 0% 5/1215mAh for the last hour or so. Finally got low battery notification/audible beep but battery indicator is still green.

Just to clarify things - we must be using different versions then, as the one I use from beta-releases *never* show low-battery warnings, just a "charge your battery"&shutdown thing on flat.

So, it seems, that for some reason (lower version number?), latest CSSU battery applet version doesn't over-write ages-old ones released by Pali, alongside experimental BME replacement.

Or I'm just mixing things up - in this case, feel free to correct me.

/Estel

// Edit

Battery applet version:
status-area-applet-battery_1.0-3_armel
...here, as opposed to CSSU'ish:
status-area-applet-battery_1.0-8_armel.deb

I wonder what the changelog is

OOC I just checked behaviour of stock calculator. And it calculates correctly. Clearing the roll (menu/clear roll) cleares the current calculation.

[ot]What I like on this little calc is that it calculates 'Punkt vor Strich' correctly. Something the Harmattan one again unlearned.[/ot]

I've tested latest battery applet from cssu-t (status-area-applet-battery_1.0-8) and it immediately reminded me, why I had version 1.0-3 on "hold", set to custom-compiled, modified fork.

cssu's battery applet reports *absurd* values as battery max capacity, and for worse, it does so on purpose. It require some explaining, so bear with me:

Probably most of you are aware of the 3th pin of the battery, dubbed "BMI pin". There is a resistor between it and ground pin, which in theory, should provide information about "design capacity" of the battery - i.e. capacity battery should have, when new. It is *not* any form of measurement - it's just "hardcoded" by placing dumb resistor there, of set resistance value. Every value from reserved range is interpreted as some capacity.

The thing is, that no one - except Nokia - cares about that, and every 3rd party battery manufacturer in existence put there a random resistor of ~100kOhm value. Nor should they care, as it's dumbest way of giving *any* info about battery capacity - it doesn't compensate for battery aging, changes with temperature (as resistance changes), and overall, is completely and utterly useless. Heck, even Nokia doesn't seem to care much, as for batches of they upgraded BL-5J design, the sometimes correctly state ~1400 mAh, and sometimes, use same resistor as from older, 1300 mAh.
---

Now, back to battery applet - for some completely crazy reasons, Pali insisted on taking *this* info for applet's info about battery's max capacity. It is *worst* place to get that info - you could, as good, cat a /dev/urandom. Data used should be from bq27x0 chipset, and only from there.

At the same time, current capacity *is* pulled form bq27x00 (in case of someone, like me, using kernel-power and bme replacement), so it ends up in humorous, but completely crap'ish results. for example, currently, battery meter show that I have
...because current capacity is real (I'm using dual-scud battery), and max-capacity is taken from *** that resistor "hardcoded" value.

---

Long time ago, when I actively betatested Pali's BME replacement and userland bits (including battery applet), I tried to reason with Pali, to no avail. He is great coder, but stubborn as usual, and deaf to any arguments. IIRC, user kerio insisted on same fix without success, so settled down on changing one line in applet's source code, and compiling own version (which I was using up to date).
---

Summing it up - as battery applet arrived in CSSU, and it's not governed by Pali alone, please people - fix it, as it's shaming to exist in current state.

Cheers,
/Estel

// Edit

Sorry for a little emotional nature of this post (but the meaning, while absolutely true, is also humorous, so I hope everyone read it as intended), but I just got instantly reminded of all those nn hours of trying to reason with Pali on IRC. While highly anegdotical experience, it's also kinda-traumatic. You know, this kind of contributing/beta testing stuff, that can give you flashbacks 30 years later

Good to see people working on cssu. i have only one question: a lot of updates for testing (and thumb) but no updates for stable. when all the new features and fixes that are considered working properly in cssu testing will be added to cssu stable? as cssu stable users cannot install testing without flashing afaik. thanks

They can.
10 chars.