Georg Baum wrote:
Abdelrazak Younes wrote:
Why is it that we use LCursor::goUpDown() to go down within a formula?
Logically, we should know where we are within the formula and we should
be able to descend inside the formula using that information.
How would that work? The only position information that is available are
screen coordinates. Only the logical structure is known in mathed, e.g. in
$\frac{1}{2}$ we have three insets, frac, 1 and 2, and 1 and 2 are the
first and second cell of frac, respectively. In normal fracs 2 is below 1,
but if you have a nicefrac, 2 is right of 1.
The only information we need to know is what is next logically, in the
case of nicefrac, 'right' and 'down' would mean the same thing logically
and I think that 'down' should in any case results in 2.
Of course we could extend the
insets to know this information, but that would essentially be a duplicate
of the metrics calculation.
If the info is in the metrics (and it is obviously) I would rather say
that we should split the metrics calculation between logical positioning
and screen positioning. I mean, a fraction is a fraction, you read 1
over 2 independently of the way you put it on screen. We should maybe
think about putting some relationship between insets. XML (MathML?)
could help us for that because we won't need to do the
Therefore it is not a bad idea IMO that screen
coordinates are used for navigating formulas.
I agree that, as it is now, we have no choice but to use the screen
information but this is not a good way to find the position of the
cursor. It is slow and bug prone.
There
should be no need to use screen oriented information at all within a
formula.
Well, if you can show us how this can be done without duplicating the
metrics stuff I am all ears, but I don't see why it is bad to use screen
oriented information.
Because we don't need screen positions but logical positions. Right now,
if the screen information is not here we are f***d up.
Abdel.
