Georg Baum wrote:
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?
By pressing down twice.
If navigating would be done logically and not visually it would be very
confusing IMHO.
Well it would not be confusing for me. It's a matter of taste I guess.
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?
XML could help us for that because we won't need to do the logic
calculation inside LyX. The logic would be embedded in the format.
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.
So, anyone remember is there was any plan to replace that.
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.
The problem here is that sometimes we need something that is not on
screen but that we should have calculated anyway. This happens for
example when you have a formula that is only half displayed at the
bottom of the screen. I am not sure how this is handled by the
CoordCache but it seems that only what is on screen is in the CoordCache
(I might be wrong here).
I don't know the
implementation too well,
I guess nobody really knows... except Andre' :-(
Abdel.
