The trick is to remember in BufferView what has been done at the
previous draw, so that the row that contained the caret can be
repainted if needed.
To this end, add an argument paint_caret to BufferView, although
painting the caret is not the job of the BufferView (at this point).
BufferView::needRepaint will act as an interface with
TextMetrics::drawParagraph to know whether the painting of a given
row should be forced.
Currently everything is done at the top row level, so that, if the
caret is in a large table, the whole table will have to be repainted.
It is not clear yet that this is necessary.
Normally the two stages of drawing are
1/ compute metrics of insets/rows/paragraphs/mathrow...
2/ draw the elements and cache their positions
Now the three stages are
1/ metrics
2/ nodraw: do not draw the elements, but cache their position
3/ draw the elements (and store again their position; it does not
seems to hurt performance).
Revive the NullPainter: this replaces the setDrawingEnabled mechanism
with a painter that does nothing. The advantage is that updatePosCache
(renamed from setPosCache) does not need anymore to be invoked from
the frontend.
updatePosCache (the nodraw stage) is called at the end of
BufferView::updateMetrics.
Length::inPixels(MetricsBase const &) and VSpace::inPixels(BufferView
const &) should be moved respectuvely to MetricsBase and BufferView:
core file are not supposed to use GUI files.
This partially reverts commit 0f1fdaaa9, but only redraws the current
row when the value returns by getPos is obviously false. It would also
be possible to check whether the current cursor has all its insets in
cache instead.
A better fix should be found, but this is unfortunately not 2.2 stuff.
Fixes bugs #9796 and #9812.
These features are active in DEVEL_VERSION when Debug is set to LATEX.
1. The TexRow information is prepended to the source panel.
2. Clicking on any line in the source triggers reverse search. (This would be an
interesting feature to implement on the user side, but we need a proper LFUN.)
[This commit is the output of the "horizontal scrolling" GSoC 2013
project, by Hashini Senaratne. The code has been cleaned up, some
variables have been renamed and moved from the Cursor class to
BufferView::Private. This is the base from which I (jmarc) will polish
the feature for landing on master.
Below is the original commit log of Hashini, updated to reflect the
changes that have been done.]
This feature also applicable for other insets; graphics and labels.
This implementation is capable of scrolling a single row when reaching
its content which is beyond the screen limits, using left and right
arrow keys.
The attribute 'horiz_scroll_offset_' introduced in the
BufferView::Private class plays a main role in horizontal scrolling of
the wide rows that grow beyond the screen limits. This attribute
represents by how much pixels the current row that the text cursor
lies in should be get scrolled.
The main logic that is responsible for drawing the scrolled rows is
within the BufferView class, BufferView::checkCursorScrollOffset.
* The main logic is called via BufferView::draw.
* What this does is set the horiz_scroll_offset_ attribute in in order to
show the position that the text cursor lies in.
* To make sure that BufferView::draw gets involved when Update flag is
FitCursor, necessary changes are made in BufferView::processUpdateFlags.
Basically what the logic that used to set the horiz_scroll_offset_
does is,
* The row which the text cursor lies in is identified by a
CursorSlice that points to the beginning of the row. This is the
'rowSlice' variable used in BufferView::checkCursorScrollOffset. Acessors
are added to obtain this variable. Here row objects were not used to
identify the current row, because it appears that row objects can
disappear when doing a decoration update for example. This means that
comparing row pointers is not a good idea, because they can change
without notice.
* Stop calculations of horiz_scroll_offset_ variable, if metrics have not been
computed yet. Otherwise the calls to TextMetrics::parMetrics, calls
redoParagraph and may change the row heigths. Therefore vertical scrolling
feature may get disturbed. This is avoided.
* Using BufferView::::setCurrentRowSlice resets horiz_scroll_offset_
when changing cursor row. This is done in order to prevent unwanted
scrolling that happens when changing the selected row using up and
down arrow keys.
* Recompute inset positions before checking scoll offset of the row, by
painting the row insets with drawing disabled. This is done because the
position of insets is computed within the drawing procedure.
* Current x position of the text cursor is compared with the
horiz_scroll_offset_ value and the other variables like row.width(),
bv.workWidth(). Compute the new horiz_scroll_offset_ value in order
to show where the text cursor lies in. The basics conditions that we
check before recomputing it are, if the text cursor lies rightward to
the current right screen boundary, if the text cursor lies leftward
to the current left screen boundary, if the text cursor lies within
screen boundaries but the length of the row is less than the left
boundary of the screen (this happens when we delete some content of
the row using delete key or backspace key).
* Change update strategy when scrooll offset has changed. This allows to
redraw the row when no drawing was scheduled. By doing so, it was
possible to redraw a wide row when moving to the leftmost position of the
wide row, from the leftmost position of the row below, using the left
arrow key.
In TextMetrics::drawParagraph it is checked whether the current row is
what is drawing now. If it is so, the value used to the x value of the row
for drawing is adapted according to BufferView::horizScrollOffset.
The method used to pass boundary() was fixed to get row when cursor was in
a nested inset. This matter is considered in Cursor::textRow and it is
modified accordingly.
GuiWorkArea::Private::showCursor() is modified to show the cursor position
in a scrolled row.
http://marc.info/?l=lyx-devel&m=133876924408431&w=2
The problem here is that the copy_params() routine in FindAndReplace.cpp
created a new DocumentClass, but it never updated its Buffer to reflect
that new DocumentClass. So its Paragraphs still contained points to the
Layouts in the old DocumentClass which, since ead697d4b6, gets garbage
collected once it is no longer needed. So the Layout doesn't exist, and
we crash.
objects. The problem that led to the leak is that these objects can be held in
memory long after the Buffer that created them is gone, mostly due to their
use in the CutStack. So they were previously held in a storage facility, the
DocumentClassBundle. Unfortunately, they were now being created too often,
especially by cloning. It's not really a leak, because they're accessible, but
we weren't ever destroying them.
This new approach uses a shared_ptr instead.
Thanks to Vincent for pointing out const_pointer_cast.
When updating the screen, moving the mouse, or scrolling the buffer, we check whether the hovering status of the insets.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33908 a592a061-630c-0410-9148-cb99ea01b6c8
Split LyXFunc::dispatch into a wrapper that does the actual screen updates and
a worker method that updates a DispatchResult object.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33226 a592a061-630c-0410-9148-cb99ea01b6c8
The list of dialog edited inset is now stored in BufferView.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31472 a592a061-630c-0410-9148-cb99ea01b6c8
* I transferred local function loadLayoutFile() in LyXFunc.cpp to a LayoutFileList::load().
Richard, as I am not into this layout thing, please check that these LFUNs still operate correctly (except from an embedded work area of course).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31412 a592a061-630c-0410-9148-cb99ea01b6c8
This patch enhances the Buffer::dispatch() method to make it a full-fledged
member of the dispatch sequence. The most immediate payoff is that LFUNs that
are handled in Buffer::dispatch() can be used from the command line.
We make better use of the DispatchResult object and return error information
through it, rather than using return values. (This was JMarc's suggestion.) We
also introduce a corresponding Buffer::getStatus() method, and modify
BufferView::getStatus() to return a flag indicating whether a decision has been
made, as is already done in some other cases.
Finally, some LFUNs are moved to Buffer::dispatch(), including LFUN_BUFFER_PRINT.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29125 a592a061-630c-0410-9148-cb99ea01b6c8
Resizing can occur by toggling toolbars (bug 4733), or by creating or closing buffers which causes the tabbar to toggle (e.g. bug 4174, comment 5).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29066 a592a061-630c-0410-9148-cb99ea01b6c8
http://bugzilla.lyx.org/show_bug.cgi?id=4935
* GuiPrefs: Add an option to the Editing dialog.
* BufferView: Scroll below document if the option is set.
* LyXRC: Write/read the option from preferences file.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28947 a592a061-630c-0410-9148-cb99ea01b6c8
http://bugzilla.lyx.org/show_bug.cgi?id=4733
* GuiWorkArea: This adds "buffer_view_->scrollToCursor();" to GuiWorkArea::resizeBufferView() to make sure that the cursor remains visible.
* BufferView: Make sure that we can call the scrollToCursor function without causing a new repaint.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28946 a592a061-630c-0410-9148-cb99ea01b6c8
