Abdelrazak Younes wrote:
> 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.
No. If the nicefrac is in an array I expect that pressing "down" in the
numerator goes to the next row of the array and not to the demoninator.
More specifically, I expect that the cursor goes to the inset in the next
row that is at the same x position. If it is not in an array I expect the
cursor to go out of the formula. If the down button would go right, how
would I be supposed to really go down?
If navigating would be done logically and not visually it would be very
confusing IMHO.
>> 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.
I don't agree, see above.
> 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
How was this sentence supposed to end?
>> 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.
That is then an implementation problem. I don't see why it needs to be like
that. IIRC the brutefind methods were introduced as a fallback hack and
never intended to be really used, because the normal find methods should
always work.
>> 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.
Yes. But we need the screen information anyway. For everything that is drawn
on screen we have already calculated the coordinates, so I don't see a
problem to use them for navigation in principle. I don't know the
implementation too well, so this could indeed be a problem, but that would
be a sign for a suboptimal design of screen coordinate calculation, and not
of formula navigation.
Georg
