GitLab

* commit '3fa10288':
  Force reevaluation if mChangedValue is true

* commit 'b9762f77':
  Force reevaluation if mChangedValue is true

* commit 'ae807e1d':
  Force reevaluation if mChangedValue is true

Bug: 22481292

This could result in display of an old result.

Factor out code to start a result evaluation.

Change-Id: I651d4386323c0abd7a86176b386072093345a1b1

* commit '9942e6f2':
  Import translations. DO NOT MERGE

* commit '3c46e939':
  Import translations. DO NOT MERGE

Change-Id: Ic4484a9655f7ace9bf03b310b6ee97ac5819c185
Auto-generated-cl: translation import

* commit 'c2269122':
  Support pasting of scientific notation numbers

* commit '8f4a8c73':
  Support pasting of scientific notation numbers

* commit '0b9806f6':
  Support pasting of scientific notation numbers

Bug: 21470972

Support pasting of numbers using scientific notation with 'E'.  This
is intentionally very restricted to dodge ambiguities with the
constant e.  We only accept a scientific notation constant if it is

1) Contained within a single pasted text element.
2) Uses capital 'E' to introduce the exponent.
3) Does not contain an explicit '+' in the exponent.

We do currently use the same notion of 'digit' as elsewhere, i.e.
Character.isDigit(), which might be too general.

For consistency, and to make sure that we can recognize machine
generated output, this also adds a few more aliases for text input
of arithmetic operators.

For consistency, always use 'E' internally for scientific notation as
well.

We ensure that a pasted numeric string is not concatenated with
a pre-existing constant.  This is a judgment call, but it means
that pasting a previous calculator result gets similar treatment
whether or not we are still running the same calculator instance.

We support limited editing on exponents.  Once an exponent is deleted,
the only way to restore it is via pasting.  The 10^x button
produces similar results, though with different operator precedence
behavior.

Change-Id: I2d0f3dceb641cdad327fd3c3540b5eea38030146

am 792e8388: am 63b08564: am a8f47d36: Merge "Have TalkBack announce results and formula changes" into mnc-dev

* commit '792e8388':
  Have TalkBack announce results and formula changes

* commit '63b08564':
  Have TalkBack announce results and formula changes

* commit 'a8f47d36':
  Have TalkBack announce results and formula changes

Bug: 21048155
Bug: 19189356

Incrementally announce additions to the formula.

Explicitly announce result after hitting equals.

Announce when display is cleared.

Remove old FIXME comment after a bit more testing.

Change-Id: I836ff6672de3f891888b2724470290c8721d4fcf

am 16171454: (-s ours) am 78d41d21: (-s ours) am b72e493b: (-s ours) Import translations. DO NOT MERGE

* commit '16171454':
  Import translations. DO NOT MERGE

* commit '78d41d21':
  Import translations. DO NOT MERGE

* commit 'b72e493b':
  Import translations. DO NOT MERGE

Change-Id: Ic2e154e85079caf915c8d10072ded3a08e7fec50
Auto-generated-cl: translation import

* commit 'b43e6810':
  Tweak text sizes and padding to prevent clipping

* commit 'b2c3e440':
  Always use "H" for formula text alignment

Bug: 22206007

Some languages contain oversized glyphs which may inadvertently be
clipped when displayed by AlignedTextView. The updated text sizes and
padding values should ensure that enough room is always reserved for
these glyphs (even when font scaling is set to HUGE).

Change-Id: Ic62df3104d033b1eafcf7d83f7e91d5329c8be70

Bug: 22208425

Most of the mathematical operators/symbols (e.g. "π") cannot be encoded
using "ISO-8859-1" however they still should be aligned using the
default capital letter height ("H").

Change-Id: I4ca6674de6e6a96b0ce513ecd8acea775f2e7081

* commit '6a83e391':
  Import translations. DO NOT MERGE

Change-Id: I631ffe9434ba119d50835247c1bd6cfcbc77355c
Auto-generated-cl: translation import

* commit 'a3723849':
  Reimplement overflow menu messages as DialogFragments

Bug: 20650813

This preserves fraction and "with leading digits" displays during
rotation.

It also turns out to easily support copy, which is a useful bonus,
since it was an obvious hole in the UI for the fraction display.
For the "with leading digits" display, this is similar to a
plain display copy, but it allows character-level selection.

Much of the code here was cloned from Justin's.

Change-Id: I4805280fa6a46f06833be0bde9563c3ce04dca45

* commit 'e8553769':
  Make trailing operator handling consistent with L

Bug: 246391

Only ignore trailing BINARY operators when computing instant results.
We used to be much more aggressive.

Also ignore trailing binary operators when the user hits "=".

This makes us consistent with the L design and ensures that instant
results don't turn into errors when the user hits "=".

Change-Id: I260e95d152168b70774330ac95d5bc567cf79b3d

* commit '19e93c98':
  Reflect conversion of CR to unchecked exceptions

Bug: 20667245

Update calculator code to reflect the fact that CR Errors have
become exceptions, and they are now delcared local to CR.

Change-Id: Ie9c9e10cef2f98a23856aa9e49328ae7ba52c9bc

* commit '79ffb522':
  Improve logic for evaluation/animation interruption

* commit '15a853dd':
  Restore original scroll position on =

Bug: 22041219

Restore default scrolling position when hitting enter after scrolling
an instant display result.

We could instead preserve the position and fix the display logic to
no longer get confused by a non-default initial position.  But this
feels more natural to me.

Change-Id: I43bb936b5bb1b5af7a7befb90fdfc0f745fb7729

Bug: 21471857
Bug: 20819212

End rather than cancel() in-progress animation in the event of user
interaction.

Discard input that interrupted a computation only for delete,
and clear, where it seems to make sense.

Use similar interruption logic for physical keyboard input as for
touch.

Make integer exponentiation more interruptible.  This remains
imperfect; the latencies in a single BigInteger multiplication
can be high. Filed b/21957088 to track that.

Clear "instant" result before launching reevaluation.  Otherwise the
example from b/21957088 shows incorrect instant results for an
uncomfortably long time as it's being entered.

Correct some of the state maintenance operations in Calculator.java.
The ANIMATE state was not being used correctly.

Remove redundant cancelAll() and onCancelled() calls.

Add an option to cancel without a message.  Use it for clear.

Change-Id: Ibab90dca0cb894e7985642f212ff41030f2fc52d

* commit '6e8087f4':
  Correct off-by-1 errors in display formatting code.

Bug: 21986868
Bug: 21960281

Fix and restructure the formatting and scroll-limit-calculation
code.  This code is inherently tricky, and has had more bugs than
we would like to admit to.  Use the opportunity to clean up the
code a bit, renaming variables consistently.

The good news is that the code seems to be getting slightly
simpler with each bug fix.

This fixes several separate off-by-one errors related to result
formatting:

The expLen() exponent string length calculation was off by 1
for exact powers of 10.

The dropDigits calculation in the formatting code was off for
negative exponents just shorter than an exact power of 10.

The exponent space calculation for a few results like -1.2*10^-8
was off by one.

For a result like -10^-500 we did not reserve space for the leading
minus sign, since that's not computed until after scrolling.

[Less serious] The ellipses were omitted when we had just barely
scrolled a leading minus sign off the screen.  (This only occurred
in exactly one position, which could never be the default one.)

Change-Id: If1bfbbb70a624998be3d996592d129b16aade745