in /boot/common/bin (why does it care where sed lives?)
* revert subversion to 1.6.2, as that does not depend on the expat optional
package
I think we (well, I) should be more thorough when testing new packages,
it would probably be a good idea to test each package on a new, minimal
image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31486 a95241bf-73f2-0310-859d-f6bbb57e9c96
it's signature indicates that it should - the callers just never use
the value currently, so it caused no harm
* squashed a TODO in the runtime_loader about the resolving strategy
for undefined symbols in add-ons: I've implemented the breadth-first
strategy (leaving out the add-on itself), as that one made most sense to
me.
This avoids loader problems with older optional packages of Pe on gcc4, as some
add-ons (e.g. "Expand Tabs") could not be loaded due to them containing undefined
symbols that are found in second level dependencies (libstdc++.so in this case).
Ingo: please review.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31465 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the default ABI for gcc2 builds should be B_HAIKU_ABI_GCC_2_HAIKU, not B_HAIKU_ABI_GCC_2, as the latter
is equal to B_HAIKU_ABI_GCC_2_ANCIENT and enforces the old symbol resolving behaviour.
If our build isn't ..._HAIKU, what is? ;-)
This fixes a whole lot of perl tests, which failed because the required shared libs could not be loaded
(as they contained undefined symbols that are only found in second level dependencies).
Note: the existing perl optional package works, since it does not contain any ABI specification symbol yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31464 a95241bf-73f2-0310-859d-f6bbb57e9c96
keeps its own idea about what a wchar_t is and that was still a short.
This of course made the data structure of a streambuf incompatible with the
"lower" half - the glibc part - causing (potentially all sorts of) crashes
when these classes were used.
This should fix the crash of gensyscalls when building haiku natively
on a gcc2-haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31462 a95241bf-73f2-0310-859d-f6bbb57e9c96
it (headers and library) from the image. The libiconv in our tree is
only used internally as a backend for libtextencoding. The real libiconv
is provided as an optional package.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31452 a95241bf-73f2-0310-859d-f6bbb57e9c96
* gcc-4.3.3 did contain too-far-stripped versions of static libraries, missing all symbols.
Now only the unneeded ones have been removed - fixing the build of the kernel on haiku natively
* libiconv was missing the shared versions of the libraries. I have updated the package to 1.13.1
and built it with shared libs (which took me considerable time to get right - the auto*-suite
basically sucks)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31450 a95241bf-73f2-0310-859d-f6bbb57e9c96
happens after the tokens have been declared - this fixes#3137 for good
(without ftpcmd.y depending on itself)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31401 a95241bf-73f2-0310-859d-f6bbb57e9c96
of trunk]
Fixed a bug exposed by changes in the locale kit branch:
* the signature of stringbuf::setbuf() wasn't matching the one from streambuf,
which caused the base version to be hidden instead of overridden - leading
to crashes during cleanup of stringstream objects
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31262 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added WCHAR_MIN and WCHAR_MAX - already as 32-bit values, since that's
what wchar_t is going to become, soon (and those values could not have
been used before, since they were missing)
* this is still work-in-progress though, I need to run more tests to find
out which of these functions are actually working, too
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31182 a95241bf-73f2-0310-859d-f6bbb57e9c96
several problems in our wchar-support - the worst of which being that
our compilers define wchar_t as short while the glibc-implementation
is relying on it being 32-bits wide ...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31180 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
haiku would support any of the declared functions (none of which are
provided by libroot)
These will come back once the locale kit has been integrated
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30883 a95241bf-73f2-0310-859d-f6bbb57e9c96
on an address in host-byte-order, not network-byte-order.
Basically this caused failure for all IP-traffic to any IP-address
where the last byte & 0xF0 == 0xe0.
Now we can surf www.pcre.org again ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30870 a95241bf-73f2-0310-859d-f6bbb57e9c96
(3-letter) and numerical timezones (e.g. -0700) are supported
This means that the workaround in mail_util.cpp of the mail kit could be
removed, but since I do not know if that should still support other versions
of BeOS, I have chosen to leave it alone.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30864 a95241bf-73f2-0310-859d-f6bbb57e9c96
* applied a patch suggested by kaliber that seems to fix the issue for good,
thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30861 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added TODO about a sanity check that should perhaps be dropped
I checked this change with both a haiku-BFS partition and one from R5
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30852 a95241bf-73f2-0310-859d-f6bbb57e9c96
and the signal stack must be copied into the new thread (at least that's
what I could make of IEEE Std 1003.1-2001 regarding the expected behaviour
of fork)
This brings down the failures of the rsync test suite from 24 to 18 ...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30807 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo / Axel: please shout if the Advantage isn't correct - I could only test
with my Ergo Elan (the international version).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30803 a95241bf-73f2-0310-859d-f6bbb57e9c96
made non-selectable on program start and selectable after the credits have
been added escapes me.
This fixes#2497 again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30796 a95241bf-73f2-0310-859d-f6bbb57e9c96
the dead key character map - both the dead key itself and the following
character are being sent.
R5 seems to do the same, at least the resulting behaviour in the terminal
is now identical: e.g. if you press ^ once, you see nothing, if you press ^ a
second time, you see '^^'.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30765 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
I've found it pretty silly that the Keymap preflet would document all my
keypresses although I'm doing something elsewhere
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30745 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed a couple of issues with respect to internal/external naming of
keymaps and the respective files, hopefully such that there's always one
keymap active in the view: either one that has been selected or (Current)
if any changes have been applied
* replaced the dead-key-menubar with a menufield (thanks Axel, looking much
better)
cleanup:
* removed remnants of Use-button (message constant and switch-case)
* dropped 'Save' menu item, as it wasn't implemented anyway and would now
never be enabled
* removed fFirstTime, as it caused problems, but did not serve any purpose
anymore
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30734 a95241bf-73f2-0310-859d-f6bbb57e9c96
mentioned that they tend to forget pressing it (including me, of course), in
effect losing all changes.
The way the code currently works, having it didn't really make sense IMO,
as any change will only ever be applied to the "current" keymap. If you want
to keep your keymap more persistently, you need to save it into a named file,
anyway.
Please give it a try and shout if this is unacceptable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30723 a95241bf-73f2-0310-859d-f6bbb57e9c96
offering two choices for acute and diaeresis as well as allowing to switch
off each dead key completely.
* moved the textview on a line of its own such that the dead key menu and
the modifier-switching button live together on one line
* added enum dead_key_index and used it at a couple of places instead of
having to use the magic numbers 1-5
* refactored the actual updating of the fChars buffer from SetKey() into
_SetChars(), which is now being invoked by SetDeadKeyTrigger(), too
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30718 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fDragKey must be reset in MouseUp() as otherwise it is not possible to
drag a key from one keymap to the textview and then from the textview to the
same key of another keymap
* _HandleDeadKey() now ignores modifier keys as otherwise dead keys that
required pressing a modifier (like the tilde on the German keyboard) failed
to highlight the resulting characters
What's still missing is a way to edit the resulting characters for each dead key, but I am not yet sure how to do that in an elegant way
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30699 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
* fixed a couple of memory leaks in the BeOS-specific (attribute related)
code of zip
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30653 a95241bf-73f2-0310-859d-f6bbb57e9c96
(missing spaces after commas) that were pointed out by Stephan
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30636 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added resource definition file which adds proper declarations and an icon
to the Locale prefs (the icon is the world used for HTML-files, too)
* I removed a garbage character from the long version description and
adjusted its format to comply with the other prefs
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30608 a95241bf-73f2-0310-859d-f6bbb57e9c96
the headers and importing the required classes in the implementation files
* automatic whitespace cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30586 a95241bf-73f2-0310-859d-f6bbb57e9c96
of simply importing the whole namespace - thanks for proofreading!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30568 a95241bf-73f2-0310-859d-f6bbb57e9c96
* actually, all those fixes were already contained in PulkoMandys patch,
but I just missed that :-/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30566 a95241bf-73f2-0310-859d-f6bbb57e9c96
* integrating most of the locale kit into the build (and image)
* removed LocaleBuild.h and _IMPEXP_LOCALE since that does not make
sense for elf (which usually exports all symbols anyway)
* added a couple of locale kit related pseudo targets for convenience
Hey, some of that stuff already seems to work :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30545 a95241bf-73f2-0310-859d-f6bbb57e9c96
into their new homes (at least for now, might need some adjustment).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30540 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
more work concerning navigation within BTextView:
* 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@30459 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
* in BEntry::SetTo and BFile::SetTo, we now support entry-refs with
absolute names, too, just like R5 does
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30183 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Since r30000, a net_socket is not zeroed anymore, which in turn
leaves its two addresses (local and peer) in an uninitialized,
but correct state - marking their state with ss_len == 0.
However, this state was not properly detected in some ipv4-address
functions, especially not the one that creates a hash value from
those two addresses.
This basically caused UDP to stop working, as here the peer address
(as opposed to TCP) is usually not explicitly initialized.
Adjusting the ipv4-address functions accordingly fixes the problem,
such that DHCP (and the rest of UDP) should now work again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30175 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
* optimized unmapping of a single page that was rather inefficient
for large areas
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29978 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
* added 'app' private header path such that ServerProtocolStructs.h
can be found
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29939 a95241bf-73f2-0310-859d-f6bbb57e9c96
* removed superfluous #include <config.h> which was protected by an #ifdef
that evaluated to false - so the file never got included, but jam tried
to locate it and usually failed, unless there happens to be a config.h
in the current working directory.
This fixes a spurious dependency from regex.c to the config.h in
src/libs/iconv.h if you invoked jam from there.
* fixed two warnings by always including stdlib.h
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28639 a95241bf-73f2-0310-859d-f6bbb57e9c96
* adjusted libtextencoding's Jamfile
* added libiconv.so to image
* added iconv headers to optional package Development (under 3rdparty)
* removed old private version of libiconv from textencoding
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28631 a95241bf-73f2-0310-859d-f6bbb57e9c96
the libiconv that was available for R5
* cleaned up iconv.h
* moved public libiconv headers (iconv.h and localcharset.h) into a
specific folder in headers/libs
* renamed config.h to libiconv_config.h in order to circumvent strange
problems with regex.c from glibc picking it up
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28630 a95241bf-73f2-0310-859d-f6bbb57e9c96
(config.h, iconv.h and localcharset.h were created by running 'configure'
on haiku)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28629 a95241bf-73f2-0310-859d-f6bbb57e9c96
Oliver Tappe