It did access par_metrics_[] directly because there was no non-const
parMetrics().
This patch adds one and unfriends BufferView. The code is equivalent
since in all these cases, the metrics have just been computed with
redoParagraph().
The 20px space on top and bottom of document have traditionally been
obtained by adding the to the ascent/descent of the first/last row.
This reads to annoyances like selections that are drawn in these
margins and issues with the nesting marker.
The change is to add the values to a separate member of the Row
object, and to add new Row::total(Ascent|Descent) methods that add the
effect of this padding.
Moreover, some methods are added to TextMetrics to simplify the
BufferView code.
Fixes bug #9545.
This is done by declaring unimplemented private copy constructor and
assignment operator.
This breaks compilation in BufferView::textMetrics, which does a copy when
inserting a TextMetrics object in the cache. Some C++11 wizardry I will not
pretend to completely understand saves the day.
See the following page for details:
https://en.cppreference.com/w/cpp/container/map/emplace
This avoids real world bugs like #11512.
The goal of this commit is to simplify the logic in TextMetrics::draw.
Now, rows are repainted depending on their changed() status.
Instead of checking whether rows have been scrolled horizontally at
draw time, the code marks the row as changed when testing for
horizontal scrolling.
To this end a new method TestMetrics::setRowChanged is added, that
searches a row in the text metrics cache and marks it changed if
found.
The old code that remembered the previously scrolled row can now be
removed.
When several lines of text are in the same variable-width tabular
cell, it is not possible to align properly the rows until the cell
width is known.
Therefore a parameter is added to redoParagraph to skip this
computation, so that it can be done later in TextMetrics::metrics.
Other calls to redoParagraph in the code are not affected. It is not
clear at this point whether they may create artefacts.
computeRowMetrics has been renamed to setRowAlignment to better
reflect its use.
Fixes bug #11447.
This effectively enables linebreaks, multipars and layout changes in
non-fixed width (i.e., standard) table columns.
Fixes: #6577
TODO: metrics are wrong (too wide) on screen with linebreaks.
This patch makes sure that, every time a ParagraphMetrics has its
position set, the inset positions for the insets held by this
paragraph are remembered too.
This is complementary to BufferView::updatePosCache, but I do not have
hard evidence that this is required other than to increase robustness.
It may help in some cases when scrolling the document (scrollbar,
cursor up/down, page up/down).
In some (not yet understood) situations, the paragraph metrics cache
is empty in generateSyntheticMouseEvent(). We just avoid a crash in
this case, but there is probably an underlying problem that deserves
being fixed.
Fixes bug #10324.
The test added at 359aef92 was incorrect. Actually, Inset::editXY
returns the inset when it is edited and also when it is not, which
can be confusing. So if we are unlucky and the slices positions in the
text area and in the inner inset match, the code below triggers and
many bad things can happen.
Also improve the documentation of Inset::editXY and TextMetrics::editXY.
Fixes#10691.
The new functions parBottomSpaging and parTopSapcing return below/above each paragraph.
This allows to remove the TopBottomSpace argument and makes the code a
bit clearer.
Now that Row has a pit() member, it is possible to use it instead of passing an extra pit_type parameter to a function which already has access to a Row.
Let breakRow return a boolean indicating whether an additional row is
required (after a newline) and use that to replace the code that added
an extra row when a paragraph ends with a newline.
If we do not do that, it is not possible to position the cursor after
a long inset with the mouse.
To do this, it is necessary to add the pit information to the Row
object. This is a good idea in any case, and will allow to simplify
some code later on.
Fixes bug #10094.
This is done by implementing contentAlignment() for this inset.
In order to display properly 'stretch' alignment, the code for TextMetrics::getAlign is rewritten to include some code that was in computeRowMetrics.
New method TextMetrics::findRowElement, excerpted from CursorX.
Reimplement getSurroundingPos using Row information. This is easy when
the cursor is inside a row element. At row element edges, different
situations can occur; hopefully all these situations are taken into
account.
Rename the old getSurroundingPos to getSurroundingPosOrig and
transform getSurroundingPos into a wrapper that compares the two
methods. This will be removed when we are confident that the new
function is equivalent to the old one.
It will then be possible to remove also the Bidi class (at last!).
These were all found by cppcheck. Even in constructors that are there "only
because of std containers" the class should be initialized correctly. You can
never know whether such an object does not get used, and then a nice crash
caused by dereferencing a NULL-pointer is better than undefined behaviour.
* convert cursorX to new scheme; old computation is still there for the sake of comparison.
* use Row to compute separator width in computeRowMetrics; again, the old code is retained for now.
* Get rid of rowWidth()
This fixes a crash in examples/fa/splash.lyx when selecting text
representing menu entries. This happens because menu names are in LTR
English, while the inset itself is in RTL.
The problem is that the current code relies on the fact that
1. getColumnNearX and checkInsetHit share the same idea about cursor
position.
2. pos and pos + 1 are in general consecutive on screen.
It seems that 1. is wrong here (for reasons I did not try to
understand); the second assumption is definitely false with
bi-directional text. This makes editXY very fragile.
The new code should be more robust in this respect. The logic is:
* if checkInsetHit finds an inset, use its position,
* otherwise, ask getColumnNearX for the cursor position.
Fixes: #9142
If we correct the row where we put the cursor after a PgDn or PgUp command, then we should also adjust the y-coordinate that is used later for checkInsetHit and inset->editXY.
However, this code doesn't function like it should, but that is bug #4382.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31007 a592a061-630c-0410-9148-cb99ea01b6c8
The row in editXY is corrected when we're scrolling with PgUp and PgDwn to make sure that the row where the cursor is places, is completely in the view.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29752 a592a061-630c-0410-9148-cb99ea01b6c8
1. When a listing is inserted in a bit of text, the line above the listing is not drawn over the full width like it is done for lines above other insets. This is because InsetListing has a AlignLeft alignment. Now, if you start selecting downwards with the mouse in this empty area, strange selection drawings appear (see attachment).
This is caused by the fact that starting your selection at such a place, causes beg.boundary() to be true in TextMetrics::drawRowSelection(..). This is correct, but this value is true for _all_ selected lines. Now, the selection acts as if it is RTL text. Therefore, just like for end.boundary, this value needs to be reset for every line.
2. Starting your selection in an end margin often causes the selection in this end margin to be painted later. This is because when starting your selection in an end margin, you may have set a (possible empty) selection before really selecting the end margin. The problem is that the checksum (computed later) is the same for this empty selection and for the end margin selection. Therfore, we need a call to cur.setSelection() before evaluating cur.selection().
3. In the following two lines, it is assumed that there is only an end margin to be painted if the selection extends to the next paragraph. This is not true for the above described case of an AlignLeft Inset. Then, the margin has also be drawn within a paragraph
4. The end and begin margins are only painted when the selection extends into the following or previous paragraph. This difference is not resembled in the checksum if you first select a row completely and then procede to the next or previous paragraph as the selection remains at the end of a row. This also holds for the AlignLeft case. Therefore I added a term to the checksum to monitor whether the end and begin margins need to be drawn.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@26399 a592a061-630c-0410-9148-cb99ea01b6c8
* completion support for mathed
* experimental completion support for text
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23104 a592a061-630c-0410-9148-cb99ea01b6c8
