work to do, but it's about time to give this code more exposure.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33176 a95241bf-73f2-0310-859d-f6bbb57e9c96
Net_server starts services by invoking fork() followed by exec(). If the latter
fails (for instance because the service isn't installed), the forked child is
invoking exit(). This in turn unloads libbe, triggering static cleanup code in
BMessage, which deletes a couple of message ports that were inherited from the
parent during the fork. After that, net_server was desparately missing those
ports and no longer worked reliably.
* in InitTerminateLibBe, we now register an atfork-(child-)handler, which
takes care to re-initialize the static reply ports used by BMessage code
* added BMessage::Private::StaticReInitForkedChild wrapper and
BMessage::_StaticReInitForkedChild() implementation which overwrites the
inherited port IDs with a set of own ports
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33050 a95241bf-73f2-0310-859d-f6bbb57e9c96
as a result failed DHPC-requests will no longer result in bogus static
configurations (but an auto-config IP-address will be picked instead)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33049 a95241bf-73f2-0310-859d-f6bbb57e9c96
its open_dir() implementation instead (as suggested by Ingo).
-alphabranch (it's only a cleanup)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33025 a95241bf-73f2-0310-859d-f6bbb57e9c96
* update Firefox optional package for r1a1
+alphabranch (will do that next)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33019 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed precedence problem in jam rule that caused an if to evaluate to true, no matter
if a cd or an image was being built
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33007 a95241bf-73f2-0310-859d-f6bbb57e9c96
a directory, we returned EINVAL instead, which caused Perl's internal
glob() implementation to fail prematurely
+alphabranch (will do that myself in a minute)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32999 a95241bf-73f2-0310-859d-f6bbb57e9c96
longer require libiconv
* removed libiconv from dependencies of DevelopmentMin, as this is
no longer true
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32479 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
* when items are removed, the anchor may need adjustment (fixes the problem
in Beam reported by Stippi)
* the check for needed adjustment of fLastSelected in _Select(from, to, extend)
was broken, as it needs to be independent of fFirstSelected - this fixes
broken navigation after doing a select-all
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32099 a95241bf-73f2-0310-859d-f6bbb57e9c96
* avoid setting fAnchorIndex multiple times in certain situations
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32090 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed handling of B_HOME and B_END in extend mode for multiselection, such that
now all the items inbetween the anchor and the final target are selected, too
* made sure that the anchor always gets adjusted in _Select(), as otherwise
navigation via cursor keys could get "locked".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31980 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed recent regression with respect to navigating via cursor keys
* unified (and thus partly corrected) computation of whether or not we're in
extend mode in KeyDown(), fixing the handling of unmodified B_HOME and B_END
in multiselection mode
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31975 a95241bf-73f2-0310-859d-f6bbb57e9c96
* resolved a couple of redundant function declaration in our public headers
* adjusted zipomatic accordingly - everything else built fine
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31938 a95241bf-73f2-0310-859d-f6bbb57e9c96
those, too. Among other things, this should facilitate making use of wstring
with gcc4.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31927 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added declaration of strtof() to stdlib.h, as we now provide it alongside
with strtod()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31926 a95241bf-73f2-0310-859d-f6bbb57e9c96
too, and I do not dare to add a glibc-based source to our kernel.
This means that our kernel will have to live with strod() yielding
inaccurate results, but since the only use I have found was for fs-queries,
I think we can cope for now.
* added a comment to the top of strtod.c that explains the current state.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31925 a95241bf-73f2-0310-859d-f6bbb57e9c96
version that lives in our repo, too, and actually works as intended
* removed the broken strtod() implementation from the repo
This fixes all floating-point test regressions reported in #3308.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31919 a95241bf-73f2-0310-859d-f6bbb57e9c96
all allocations, instead we now directly request the use of malloc/free in
stl_config.h. This avoids warnings about 'arrays of size 0' when building
any stl-code with -pedantic (like e.g. ICU does).
Alternatively, we could active pthread-type threading support, but since in
some small tests, I have not been able to see any advantage, I've just added
a respective comment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31609 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
Oliver Tappe