This fixes#7022 and is mostly based on the patch attached to that ticket, with
these changes:
- The patch was adding this to the private _TextInput_ class, not BTextView.
- The patch had a Clear menu item too. I removed that due to the different
semantics between Clear in a BTextView and in a TextInput. The former just
clears the selection where the latter clears the whole view.
We could later add a virtual callback for adding menu items to this context
menu which could be used to add Clear with the two semantics in each class
(this is mainly needed for the enabling logic...each class could handle a clear
message in its own way.) This callback could also obviously be used for other
things, like a spell-check menu or whatever an application would want to add.
Since BTextView has 10 free virtual slots it seems reasonable to add.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40305 a95241bf-73f2-0310-859d-f6bbb57e9c96
default drawing mode for text rendering. Don't override it
with B_OP_COPY (still the default). Should not have any
consequences in any existing use-case. The MediaPlayer can
use BTextViews to render semi-transparent subtitles this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38823 a95241bf-73f2-0310-859d-f6bbb57e9c96
* when I changed InsertText() to adjust the caret position recently, I
forgot to drop that adjustment from all callers - _HandleInputMethodChanged()
was still doing it, leading to out of bounds access
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38243 a95241bf-73f2-0310-859d-f6bbb57e9c96
* _DoInsertText() must not assume that the text is actually being inserted
by InsertText(), since that's a virtual method meant to be overridden by
subclasses. So the updating of caret-position and selection start/end has
to happen in InsertText().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38006 a95241bf-73f2-0310-859d-f6bbb57e9c96
but which is outside the new text rect, when changing the text rect. Solves
dirty regions in BTextViews. For example the black bar along the top of the
URL input in WebPositive after starting it. Or random bits of text left-over
in Beam when switching emails.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36470 a95241bf-73f2-0310-859d-f6bbb57e9c96
* _NullStyleHeight() must return the height including the 1 pixel gap between
the lines, as that's how it's being used
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36469 a95241bf-73f2-0310-859d-f6bbb57e9c96
do what one would want. This closes ticket #5671.
* I'm not sure if we want to resurrect the pose view part of r35731 again; it
adds bitmap and text clips to dragged files. At least the bitmap change was
unrelated, but I'm a bit torn if that is the way this should be handled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36390 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Large cleanup in _FindLineBreak(), be a bit more clever by storing the found
offsets instead of calculating them multiple times, use
_TabExpandedStyledWidth() instead of _StyledWidth() and manual tab calculation
which was also broken (it assumed tabs were consequtive which was possibly not
the case).
* Modified CanEndLine() to also return true when going from non-whitespace to
whitespace and the other way around which is more logical (so we'd break after
the word and not after word + whitespace, even though we actually do that
in the end by eating whitespace after words in _FindLineBreak()).
* The TextGapBuffer is not necessarily 0 terminated, so RealCharAt() needs to
check if the index is at the end of the string and return 0 in that case.
Before it would access the buffer "out by one" which could've lead to a crash.
* Simplified the gap moving calculations by removing some no-op calculations.
* Added debugger calls in TextGapBuffer in case of invalid use.
* Some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36304 a95241bf-73f2-0310-859d-f6bbb57e9c96
All views which cache layout information need to call ResetLayoutInvalidation()
when they have updated the cached information. Otherwise calling
InvalidateLayout() once they are already attached to a layout may not have any
effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36217 a95241bf-73f2-0310-859d-f6bbb57e9c96
to parts of the caret being inverted:
* instead of always inverting the caret rect, we now invalidate when the
caret should be hidden
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36153 a95241bf-73f2-0310-859d-f6bbb57e9c96
honors drag messages containing entry refs and resolves the path of the first
one contained. Will work on a more sophisticated solution that would allow
optionally extracting the file text instead via right click drag context menu
when I have more time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35731 a95241bf-73f2-0310-859d-f6bbb57e9c96
would yield double inversion of the caret position, causing #5006
* cleanup with respect to when the selection can be highlighted and/or the
caret can be shown/hidden
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34944 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make word-wise navigation via cursor keys match Pe, such that it is consistent
throughout haiku (unless some applications brew their own)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33913 a95241bf-73f2-0310-859d-f6bbb57e9c96
which are now being used to implement the word-wise keyboard navigation,
fixing #4785
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33885 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Word selection via double-click now works like in R5, except that '_' is now
being considered part of a textual word, too. This fixes#4754.
* Adjusted CanEndLine() to make much more sense (at least for western
languages).
While I have tested the wrapping quite a bit, it is not unlikely that these
changes introduce regressions. If you spot one, please tell!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33882 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes#4894
* PointAt() now rounds x- and y-positions to the next integer instead of always
rounding them up - this yields improved caret-positions (e.g. before an 'f'
character)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33877 a95241bf-73f2-0310-859d-f6bbb57e9c96
(reported by Axel):
* _AutoResize() can no longer check the difference between the textrect and
the maximum line width, as the textrect is no being adjusted earlier during
the line-calculation code - instead, it needs to measure the difference
between the bounds and the textrect width plus the insets.
* MakeResizable(true) needs to reset the right inset, as otherwise the auto-
resizing would get confused about how large the textview needs to be
(seems to be an artefact of how Tracker creates the textview).
* GetInsets() doesn't need to compute the insets, as they're maintained in
fLayoutData.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33813 a95241bf-73f2-0310-859d-f6bbb57e9c96
* SetTextRect for non-wrapped textviews needs to update the insets,
as otherwise several misalignments occur within several apps - renaming
in Tracker was effected the worst, though
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33717 a95241bf-73f2-0310-859d-f6bbb57e9c96
during the width calculation
* used _TabExpandedStyledWidth() at all places that need to expand tabs,
fixing #4822
* removed _StyledWidthUTF8Safe() as it didn't make sense - we now perform
the same auto-scrolling horizontally as we do vertically
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33713 a95241bf-73f2-0310-859d-f6bbb57e9c96
* switching from wrapping to non-wrapping mode triggers a recomputation of
the text rect
* non-wrapping mode now triggers updating of the data rect for the horizontal
scrollbar as needed, fixing #4705
* corrected a couple of width computations that confused bounds and text
rect width, leading to drawing artefacts at the end of a line
* unified computation of text rect width to always take all lines into
account (not just the first one)
* some cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33703 a95241bf-73f2-0310-859d-f6bbb57e9c96
#4707, this is the BeOS behavior. I have not checked myself and the BeBook is
very brief on this, but similar methods do trim indices to be in range.
Another alternative would be returning an index indicating an error (-1).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33439 a95241bf-73f2-0310-859d-f6bbb57e9c96
break instead of after. Also whitespace after the cursor position wasn't
ignored.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32993 a95241bf-73f2-0310-859d-f6bbb57e9c96
although it should have been safe before, too, since BTextView neither
has inline methods nor any friends that live outside of libbe
* added new member fLastClickOffset in order to be able to restore the
triple-click handling (linewise selection)
* renamed fClickOffset to fCaretOffset, as that is what it really is
now
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32444 a95241bf-73f2-0310-859d-f6bbb57e9c96
else this won't work as is (this is something that could be done, better,
though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32077 a95241bf-73f2-0310-859d-f6bbb57e9c96
needed to show all of the text view's contents. No idea what the previous
solution was about.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32075 a95241bf-73f2-0310-859d-f6bbb57e9c96
next position of the caret and only scroll the distance between the current
and the next position. This fixes#3981
* When paging upwards, we need to compensate for the fact that the caret
position is always considered at the top of the line, as otherwise a
page-up would pass one more line than a page-down
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30933 a95241bf-73f2-0310-859d-f6bbb57e9c96
* when selecting via mouse, the caret position now follows the direction of
the selection - which is less surprising than not moving the caret at all
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30928 a95241bf-73f2-0310-859d-f6bbb57e9c96
has been given via the inline input method, but to feed the individual
UTF8-characters it contains to KeyDown() - this way special keys like
B_BACKSPACE and cursor keys will be handled correctly instead of producing
a "unknown char rectangle"
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30764 a95241bf-73f2-0310-859d-f6bbb57e9c96
textviews, such that the characters are drawn at their correct positions and
there are no longer any mismatches between caret and character positions
* fixed too large widths returned by LineWidth() for lines ending with a
newline: the newline character must not contribute to the width
This makes the textcontrol in DiskProbe work properly again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30762 a95241bf-73f2-0310-859d-f6bbb57e9c96
* non-editable textviews no longer draw the caret
* the cursor keys scroll immediately, not only when the (invisible) caret
reaches the views bounds
* HOME/END work more reliably
* any selection stays active throughout keyboard navigation
Tested with AboutSystem, Mail, StyledEdit and Beam - seems to work ok
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30756 a95241bf-73f2-0310-859d-f6bbb57e9c96
Keymap preflet:
* obscure the cursor only if the textview has the focus
* initiate a drag not only if the cursor has moved to another index, but also
when the cursor has moved more than three pixels, since otherwise it was
impossible to drag the first character to the left or top of the view
(as the corresponding index was always zero)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30698 a95241bf-73f2-0310-859d-f6bbb57e9c96
in order to maintain the null-style appropriately, if required
* finally fix#3040 for real (a single style is now maintained at all times
for non-stylable textviews)
* the caret is now being drawn with the correct size, even if it is on
the empty line at the end of the buffer and a specific font size has been
requested
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30532 a95241bf-73f2-0310-859d-f6bbb57e9c96
reported by kirilla, thanks!)
* when tracking the mouse in order to detect drags, it is not necessary to
check if the pointer is within the selection, as that causes problems when
you e.g. click on the border of the selection and then move the mouse outside
of it (we'd still want to initiate a drag in that case)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30519 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the textview now only initiates a drag after the mouse has been moved to
another offset, making it possible to click into the selection in order to
position the caret at the offset corresponding to the point of the click
(just as R5 does it)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30518 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed crash in StyleBuffer::SetStyleFromMode() if any of the given pointers
is NULL (which is perfectly valid)
* BTextView::SetFontAndColor() now syncs the null style before it sets the
range, thus making sure that there is only one style if the view is not
stylable
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30516 a95241bf-73f2-0310-859d-f6bbb57e9c96
* adjusted _FindLineBreak() to no longer expect that only whitespace can
end a line, as that is simply not true
* CanEndLine() returns true for characters that are followed by end-of-text
or a separator
* activated the commented lines in CanEndLine() that allow '...' to be treated
as a word
As I have nothing more relating to BTextView on my todo-list, I will start doing something else now, but please *do* send any complaints my way ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30473 a95241bf-73f2-0310-859d-f6bbb57e9c96
view's top and bottom if you moved the pointer above the view and reached
the top
* increased auto-scrolling speed to 40 scroll steps per second and changed
_PerformAutoScrolling() to behave as R5: do soft scrolling
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30463 a95241bf-73f2-0310-859d-f6bbb57e9c96
* pressing HOME on last line works again
* made public versions of LineAt() do what is required to pass back the
correct value even for the last line of the buffer (original implementation
has been moved to private _LineAt())
* PAGE_UP/PAGE_DOWN now moves the view by the bounds-height, making the
behaviour somewhat less confusing (IMHO, please shout if that's not
acceptable for you)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30458 a95241bf-73f2-0310-859d-f6bbb57e9c96
returned one less than it should, causing unexpected moves of the caret, for instance when pressing HOME on the last (empty) line:
* LineBuffer::OffsetToLine() and LineBuffer::PixelToLine() did not check
for the last line in their binary search
* removed a special case from TextView::PointAt() which now is no longer
necessary (not sure if it was, before)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30435 a95241bf-73f2-0310-859d-f6bbb57e9c96
and paging-keys, especially extending the selection via shift was more or
less broken
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30431 a95241bf-73f2-0310-859d-f6bbb57e9c96
Rene Gollent