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
* Select() did not adjust fClickOffset, which resulted in the cursor
position not being where on would expect (noticable when pressing
cursor-up/-down)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30184 a95241bf-73f2-0310-859d-f6bbb57e9c96
other situations. Basically, I made DeleteText() adjust the selection according
to the deleted range. Some places where DeleteText() was called forgot to
adopt the selection. Other places adopted the selection. Maybe some of those
could be removed now, but some also change fClickOffset, so I just left them
as they are.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30076 a95241bf-73f2-0310-859d-f6bbb57e9c96
it's ready. For now, I just tried to fix stuff like breaking before
punctuations. I had trouble wrapping my mind around the wrapping code, so I
didn't include as much cases as I wanted. Basically, the wrapping code assumes
that a spot where CanEndLine() returns true must be a white space character,
which wouldn't be the case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30075 a95241bf-73f2-0310-859d-f6bbb57e9c96
needs more testing before I can do that, but in principle, I think the idea
was an ok one... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30048 a95241bf-73f2-0310-859d-f6bbb57e9c96
triggering auto-scrolling in BTextControls...
* _BTextInput_::MinSize() added 1 to the line height, but when aligning the
text rect, at least one pixel is added at the top and bottom, which makes
for at least two extra pixels.
* BTextView::_PerformAutoScrolling() had some code which was supposed to
prevent from out-of-bounds scrolling, but the bottom maximum coordinate
was not correctly calculated. This and the above item led to the ping-pong
effect.
* Additionally, I prevented scrolling vertically for one-line text views
completely.
* On mouse-up, reset the cursor. It may have to be the I-Beam cursor again,
for example after de-selecting.
* While mouse tracking the selection, always use the I-Beam cursor.
* Also when mouse tracking, do not use the minimum/maximum text offset when
the mouse is above/below the text rect. Do this only when it's also outside
on left/right sides. This is less irritating and works like on other
platforms. It means the first/last line can still be selected, without
having to constrain the mouse to the inside of the text view.
* When calculating the selection region, don't make the bottom one pixel too
far up. Lines which contain glyphs that extend below the base-line have
one more pixel below the glyphs that is inverted now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30046 a95241bf-73f2-0310-859d-f6bbb57e9c96
* renamed _FindXXXWordBoundary() methods to _Previous/_NextWordBoundary()
since the respective per-char methods are named this way
* started to work on improving the behaviour of page-up/page-down
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30012 a95241bf-73f2-0310-859d-f6bbb57e9c96
* reverted my recent change that caused Mail to always show the end
of mails 8-) and now invoke ScrollToOffset() wherever it was missing
(mostly in keyboard-related methods)
* _DoInsertText() only moves the caret if the text has been inserted
in front of the caret, not after it
* overhauled selection by char/word/line and their extension mechanism
(which now behaves as the haiku shell)
* use strnlen() instead of strlen() in those versions of Insert() which
accept a length parameter, as strlen can potentially waste a lot of
cycles skipping the whole string, when all we want is to clamp the length.
* cleanup (some of it automatic removal of trailing whitespace)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29995 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Select() did not re-show the caret when it should
* GoToLine() must hide/show the caret to avoid drawing artefacts
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29983 a95241bf-73f2-0310-859d-f6bbb57e9c96
we request the drawing via Invalidate() - this make use of the app-server's
potential double buffering, whenever that is active. This change reduces
flickering in VESA mode considerably.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29962 a95241bf-73f2-0310-859d-f6bbb57e9c96
with large contents:
* when searching for tab characters in DrawLine(), we now limit the search
to the current line, too (not only the end of the style) - this avoids
scanning to the end of large contents repeatedly
* there's no need to refresh from the edit location to the end of the
content in _DoInsertText(), we only need to refresh the part that has
changed
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29960 a95241bf-73f2-0310-859d-f6bbb57e9c96
NOTE: There are some more problems with regard to this, if you resize
DeskCalc (which sets a new font size on the expression view, and then type
something, the newly typed stuff will have the old font still...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29911 a95241bf-73f2-0310-859d-f6bbb57e9c96
the buffer when Ctrl-Home is pressed and to the end when Ctrl-End is pressed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29476 a95241bf-73f2-0310-859d-f6bbb57e9c96
overheard that they looked too ninety-ish.
TODO: The code behind this is work in progress. The basic idea
is to extract all drawing code into a new class BControlLook,
of which there is a global instance be_control_look, instantiated
in InterfaceDefs.cpp. At the moment, all the old drawing code is
still there, and the usage of be_control_look is inside if-bodies
checking the instance against NULL. In another words, by not
instanitating be_control_look, you can revert back to the old look.
BControlLook's job is to provide reusable methods for drawing
certain types of frames, backgrounds and labels, so that application
developers can make controls that re-use the same drawing code
as built-in controls and adopt to changes made there. I have added
the notion of "borders". Each of the frame drawing methods can be
made to draw certain borders only, which is supposed to help when
controls shall visually attach. This feature is not fully explored
at all ATM.
TODO: Update BColumnListView header view and BStringItem text
spacing. Update other apps where it makes sense to use BControlLook.
For the moment, only Tracker and LaunchBox are updated. More...
NOTE: The new look is not very radically different, so that existing
apps do not immediately look too ugly or out of place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29221 a95241bf-73f2-0310-859d-f6bbb57e9c96
gWidthBuffer.
* Tracker PoseView now uses BPrivate::gWidthBuffer instead of it's own
instance.
* TextView.h and PoseView.h are now a little cleaner.
* InterfaceDefs.cpp now deletes gWidthBuffer in _fini_interface_kit_().
* Added binary compatibility support for NetPositive in WidthBuffer.h and .cpp.
Obviously it kind of defeats the purpose of having WidthBuffer neatly tucked
away in the BPrivate namespace, but Haiku should run NetPositive, I guess.
Fixes#2879.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28532 a95241bf-73f2-0310-859d-f6bbb57e9c96
window this fixes the tool tip size/layout in apps that use BubbleHelper
(Beam, WonderBrush, ...). Thanks to Rene and Stefano for sending me a test
application.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28489 a95241bf-73f2-0310-859d-f6bbb57e9c96
tool tips in WonderBrush. The reason was that the text rect is getting
smaller and smaller each time the tool tip is shown (even though there
is only one word), and the line break moves one char towards the beginning
each time. After four times, the busy loop would kick in reliably. I cannot
really say that I understand the code, though. But that's the spot anyways.
Stefano, could you have a look?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28471 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed LineHeight() for the case when the textview does not yet contain
anything - instead of returning 0 we now return the lineheight of the
default style (or the textview's font).
Fixes#2231
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28194 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix the calculation of the fTextRect member. The BeOS behavior (and also the
previous Haiku behavior) was to recalculate the "bottom" always. This was not
taken care of in SetTextRect() (needs to override the passed bottom).
* The insets are already tracked in fLayoutData, use this in
_UpdateScrollBars() to calculate the correct data width/height (an
improvement over the BeOS behavior it seems).
* Try to minimize the need to call _Refresh(), which reduces flickering a whole
lot.
* Fix several instances where fTextRect was recalculated based on Bounds() and
the saved insets, where it was broken when the BTextView was scrolled.
Fixes#2784.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28151 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed a general problem with respect to overriding of the reserved
virtual function slots: instead of statically invoking the method
that corresponds to the reserved slot on the class that contains the
slot, we now invoke the virtual Perform() method. Perform() then dispatches
the method invocation to the "proper" class, i.e. the highest class in the
hierarchy that actually implements the requested method.
This fixes a crash in apps that use liblayout's MSlider class and
should fix one or other spurious bug with old apps or libraries, too.
* added new header folder 'binary_compatibility' that contains files that
define the method codes and data structures required by Perform()
* looked for and implemented all used reserved virtual slot functions to
invoke Perform() where necessary or to pass on the method call statically
(for slots that were already maintained by Be)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28124 a95241bf-73f2-0310-859d-f6bbb57e9c96
a BTextView via GetPreferredSize() if it is large enough. (Have not
confirmed this is necessary... gut feeling.)
* Calculate a minimum line height even if the BTextView is empty yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27828 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The class calculates a minimum width now, which is based on the line height,
this may also fix the bug with the small text inputs in the Pe Find window.
* Added TODOs about implementing GetHeightForWidth(), which may be a good idea
when a BTextView is used as non-editable informative text in an interface,
and one wants to make sure that the entire text is shown.
* Replaced the call to _Refresh() in Draw(), which recalculates all the line
breaks for no reason with _DrawLines() again. The TODO mentioned that text
will be drawn without drawing the background first, but maybe this is a
relict from times where Draw() was invoked directly? At least I cannot see
any negative consequences, and this should be much more efficient.
(Other than that, this patch should hopefully have no potential negative
side effects...<crosses fingers>)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27670 a95241bf-73f2-0310-859d-f6bbb57e9c96
BTextView classes:
* Declared the directly used BTextView helper classes as private BTextView
classes and changed all affected files.
* Realized that Tracker's BPoseView was (accidentally?) using what used to
be _BWidthBuffer_. It had declared it's own class with the same name and
same members/size in headers/private/tracker/TextViewSupport.h, but the
implementation was nowhere to be found. I can only explain this that
the BTextView implementation was then actually linked and used. But the big
problem was that it was used without locking (unlike in BTextView)! When
many Tracker windows opened during system startup or later and they happened
to each request characters not yet in the cache, I imagine things could have
gone bad and corrupted memory. Anyways, since I can see the usefulness of
the cache, BPoseView uses BTextView::WidthBuffer on purpose now. And I moved
the locking inside BTextView::WidthBuffer::StringWidth().
* Adjusted InterfaceDefs.cpp accordingly.
* TODO: Move subsequent classes into BTextView namespace as well, ie derived
classes that BTextView doesn't directly know about. All stuff in src/kits/
inteface/textview_support/
* Added preliminary and not yet implemented layout friendly BTextView
constructors.
* I will try to handle the insets imposed by BTextView::fTextRect a bit
differently when used inside the new layout management framework. For this,
I added BTextView::SetInsets() and GetInsets(). SetInsets() doesn't do
anything yet.
So far, everything seems to work still... ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27654 a95241bf-73f2-0310-859d-f6bbb57e9c96
line will be scrolled out of view. (Fixes text jumping one pixel up/down in
Vision with each new char you type into Visions text box.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24136 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renaming things in Tracker list mode no longer magically grows the text view.
* ScrollToOffset() is not supposed to depend on the existence of any scroll
bars, in R5 text views simply scroll to where they need to. This fixes
renaming things in Tracker when hitting the window bounds (text widget stops
growing and starts to autoscroll) and also the Text tool in WonderBrush.
* _ScrollToOffset() is therefor no longer needed.
* The insets of the text rect are not so interesting as the original width.
In auto resizing mode, the original width is important when there is no
container view. In this setup, the text rect auto resizing is mainly needed
for auto scrolling, but it should never shrink below the original size.
* Further improved auto scrolling for right aligned and center aligned text
views, it works like R5 now. Also take the line height into account when
checking for the bounds bottom. Removed extra spacing for vertical
scrolling.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24130 a95241bf-73f2-0310-859d-f6bbb57e9c96
Oliver Tappe