right subcell as first responder!
This fixes the following bug: when selecting a cell whose content is too
long to be displayed, the scrolling is broken
There was a lot of code duplication.
I removed the initialization of xLabel{} and yLabels{} because those are
scratch buffers that shouldn't be accessed before being written to
anyway.
scroll "smartly" when scrolling to a too-big-to-be-displayed rect
This fixes calculation history navigation on big cells (that are bigger
than the displayed table)
This fixes crashes: indeed, in the way it was done before, we called
scrollToSubviewOfTypeOfCellAtLocation after setting the new selected subtype
and before reloading the data. However, selecting a new subtype might expand
the selected cell which can temper with the cell repartition. If so, we need to
reload the data to be able to call 'selectedCell' for instance.
table. Otherwise, the Poincare pool store useless layouts for cells that
aren't displayed.
This fixes the following issue: input "(transpose([1 2 3 4 5 6][1 2 3 4 5
6])^8", the computation works, clear the history, input the same
calculation again, it fails with a memory error.
At the moment ViewController::viewWillAppear doesn't do anything, so
there is no real impact. But if we want to use it it needs to be called
from subclasses.
When each Calculation had its own text buffer, the Expression of an
overflowing output text was Undefined. Hence that Expression could have
been Undefined without the corresponding text being 'undef'. That situation
may not happen anymore since Calculation are stored in a shared buffer.
The most common case where only the approximate output is displayed
happens when the exact and the approximate outputs are equal, more
precisely when the exact output is equal to the approximate output with
the number of significant digits taken from user settings. That
clarification matters for the Poincare::Integers which have more digits than
the number of significant digits set by the user.
Besides, an Expression containing Units is simplified as
Multiplication(Float, Unit...) recorded identically into the exact and
the approximate outputs (except perhaps the number of significant
digits). Generally, the case where the number of digits in the output is
smaller or equal to the user setting would be matched by the condition,
stated above, that exact and approximate output are equal. But that
should also be the case whatever the number of significant digits. That
is why the presence of Units is matched specifically.
and 2 approximate outputs - one with the maximal number of significant
digits and one with the number of significant digits asked by the user.
This enables to find the approximate output without going through the
approximation routine again.
only when the calculation is actually expanded (when the output is
selected and the display output is ExactApproximateToggle)
This avoid blinking when changing input/output selection
AbstractScrollableExactApproximateExpressionsView children classes
reload scroll after reloading the subview selection when entering the
responder chain and when cell becomes first responder. We don't reload
scroll when setting content of cells as this is done every time we
relayout - when scrolling in the table for instance.
three expressions but no more BurgerMenuView.
ScrollableExactApproximateExpressionsView and
ScrollableInputExactApproximateExpressionsView inherit from it.
If nextFirstResponder is nullptr, it means we are exiting the app, so
there is no need to relayout, reselect, ...
We did it bbefore because a long time ago, we used to keep all apps side
by side so they had to be thouroughly cleaned when exiting
Complex model parameters are computed.
Sometimes, approximation without simplification doesn't not give the
same results as approximation after simplification. As we decided to
display the additional results from an approximation without
simplifcation (done in Expression::hasDefinedComplexApproximation), we
compute the model parameters the same way (to ensure that both
parameters are defined)
