* It is necessary to store the local origin and scale of a view state, at
least for the clipping region and especially because the scale affects the
clipping region. Ie origin and scale of one state affect the clipping region,
at the time the clipping is evaluated, ie
SetOrigin(...);
ConstrainClippingRegion(...);
is equivalent to
ConstrainClippingRegion(...);
SetOrigin(...);
The current client provided clipping region at the time of PushState()
always constrains the region of the new state. The previous region
and the current local clipping may have their own individual origin and
scale.
To support all this, I needed to store origin and scale of each state on
the stack, but I do cache the combined origin and scale. Caching only
the combined region is not possible though. So the new implementation
is slower than the previous, but more correct.
* Refactored "copy constructor" from DrawState, which is not really a copy
constructor anyways, made it private. It is only used by PushState().
* Removed some dead code from DrawState.
All this improves Firefox redraw issues a tiny bit, but does not fix them.
Either I am not covering Firefox needs with my test app, or the bug is
somewhere else. At least Haiku behaves like BeOS with regard to client
clipping regions and the state stack now...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24428 a95241bf-73f2-0310-859d-f6bbb57e9c96
readlink() function. It is no longer required to null-terminate the
string, shall not fail, if the buffer is too small, and shall return
the length of the string actually written into the buffer.
* Adjusted rootfs, devfs, and bfs accordingly. Also adjusted their
read_stat() hooks to return the correct symlink length in st_size.
* Our readlink() does now comply to the standard (and BeOS).
Additionally if the buffer is big enough it is nice to non-conforming
apps and null-terminates it.
* BSymLink::ReadLink() explicitly null-terminates the string now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24425 a95241bf-73f2-0310-859d-f6bbb57e9c96
default route in the whole stack. The default routes are ordered by
link speed, so faster interfaces are preferred.
* find_route() by net_route now also checks for the equality of the
RTF_DEFAULT flag
* find_route() by address now ignores routes that point to interfaces
that have no link; if you have more than one configured interface in
your system, the one with a link is now always chosen.
* get_route_internal() now recognizes AF_LINK addresses, and allows
one to specify a route by interface this way.
* Implemented update_route_info().
* Minor cleanup, moved copy_address(), and fill_route_entry() into the
private part of the file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24423 a95241bf-73f2-0310-859d-f6bbb57e9c96
maybe this should be the assembler version we use for x86, but is probably
fine for the purpose of the test environment (only BString uses this)
* Fix semantics of DrawingEngine::CopyToFront() which I recently introduced,
for the fake accelerant of the test environment, we do need to call
Invalidate(), not CopyBackToFront() directly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24422 a95241bf-73f2-0310-859d-f6bbb57e9c96
only happen if BPartition::SetContentType() set it (which set it
only if the original type differed).
* This fixes a part of bug #1928, but of course, it still won't work
(now the partition reports to be busy).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24419 a95241bf-73f2-0310-859d-f6bbb57e9c96
would cause various incorrect behavior, best observed in the form of Deskbar crashing if you tried to drag and drop
a large replicant (i.e. Workspaces) onto it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24418 a95241bf-73f2-0310-859d-f6bbb57e9c96
169.254.0.x, as this is the IANA reserved address for default
configuration.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24415 a95241bf-73f2-0310-859d-f6bbb57e9c96
builds on Linux with gcc 2 and 4, but the images do even run. :-) Not
tested on BeOS.
* Removed stddef.h and stdarg.h. They are provided by the compiler.
* Adjusted size_t.h, wchar_t.h, and wchar.h accordingly.
* Made stdio.h avoid gcc 2.95.3's fixincludes hack stdio_va_list
* Added gcc 2.95.3 headers to the repository. They are used instead of
the headers of the gcc 2.95.3's we use to compile Haiku with. Should
avoid build problems with the BeOS native compiler.
For sake of personal recreation you can rebuild the cross gcc 2.95.3,
but the only thing that changed is its header directory
(lib/gcc-lib/.../include), which isn't used anymore. Replacing it with
headers/build/gcc-2.95.3 should have the same effect as rebuilding, BTW.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24413 a95241bf-73f2-0310-859d-f6bbb57e9c96
hack math_huge_val_ifndef does, anyway. We do it ourselves and remove
the therefore superfluous gcc math.h header.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24412 a95241bf-73f2-0310-859d-f6bbb57e9c96
depth, and will bail out if it hasn't reached the leaf level then.
* This should at least avoid the crash of bug #1911; there is not much
more I can do about that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24411 a95241bf-73f2-0310-859d-f6bbb57e9c96
what RunArrays::Length() meant; it should have been the length of a
log entry, but was only the block count.
* Now I've improved naming and fixed initializing the LogEntry with a
wrong size, causing subsequent log entries to lose track in the log
(the log_start pointer got wrong, so BFS would not be able to replay
such a log).
* This at least fixes one part of the problem of bug #1911.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24410 a95241bf-73f2-0310-859d-f6bbb57e9c96
Tracker now persisting its desktop replicants across sessions.
This may not completely handle zombies properly though, I had
nothing to test that case with.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24409 a95241bf-73f2-0310-859d-f6bbb57e9c96
change resulted in "version mismatch between boot loader and kernel". So
apparently the size of some type changed unintentionally.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24408 a95241bf-73f2-0310-859d-f6bbb57e9c96
under Haiku overrides ours anyway.
* Adjusted size_t.h, wchar_t.h, wchar.h accordingly. This should fix the
annoying "ssize_t redefined" warnings when compiling under Haiku.
* When building Haiku the gcc headers come first in the include
search path now, as it should be. The respective TODO suggested that
this might break the build depending on compiler version and host
platform. I've tested with Linux gcc 2 and gcc 4, which work fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24406 a95241bf-73f2-0310-859d-f6bbb57e9c96
use the index of the first page of the allocation as an id. This removes the
need for separate id generation. This also fixes the possible problem of
multiple large allocations getting the same allocation_id (due to the limited
range of possible ids), which in the worst case (i.e. for adjacent allocations)
could cause pages to be freed that were still in use.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24405 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed various warnings with GCC4 due to the double sHaikuRevision line.
* Turned system_info.c to a C++ file.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24404 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the blocks in the log entry will be checked, and only if this passed,
all log entries are written back together; if the whole run array contained
bad data, it's no longer written to disk at all if it's detectable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24402 a95241bf-73f2-0310-859d-f6bbb57e9c96
entries, even though many more could fit in the blog. This fixes mounting
a dirty (original-)BFS volume with a block size larger than 1024 bytes,
and probably vice versa.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24401 a95241bf-73f2-0310-859d-f6bbb57e9c96
number. Was a problem only for partitions > 2^32 * block size (4TB
for 1KB blocks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24393 a95241bf-73f2-0310-859d-f6bbb57e9c96
replicant as well.
* Added a context menu that allows you to change how Workspaces looks
and behaves (previously accessible only using command line options).
* The settings changes are now remembered; we're now using a new
settings file (flattened BMessage), but can still read old settings
files if it exists.
* Renamed WorkspacesPreferences to WorkspacesSettings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24389 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The view must be a follow all view since the workspaces are handled
differently.
* No longer needs to use kWorkspacesWindowFlag; this makes it no longer
work on BeOS.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24387 a95241bf-73f2-0310-859d-f6bbb57e9c96
from the call to vfs_get_vnode() now. Only this way it is safe to call
store_release_ref() later (as the page writer does). We had a potential
race condition -- if called after vm_cache_remove_consumer() had
released the last reference, the old vnode might already have been
deleted.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24386 a95241bf-73f2-0310-859d-f6bbb57e9c96
Move implementation from LocalDevice for retrieving the BluetoothServer Messenger
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24385 a95241bf-73f2-0310-859d-f6bbb57e9c96
FreeBSD driver is doing.
* hda_codec_new_audio_group() did not free the audio group's widgets on
failure.
* No longer create the input stream for now.
* Reworked multiaudio-support to work regardless if there is only a playback
or record stream.
* With these changes, I hear nothing on my laptop anymore (before there was
noise), but on another system, I can finally hear something that sounds very
much like the sinus wave the multi_audio_test application produces; the
sound quality is pretty bad though (lots of periodical noise and glitches).
* Made B_MULTI_GET_DESCRIPTION safe to be called from userland.
* Minor other cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24383 a95241bf-73f2-0310-859d-f6bbb57e9c96
one gets overwritten; if the log contains invalid data, it will no longer
render the whole disk unreadable. This should have helped to prevent bug #1911
(but of course the problem that there is invalid data in the log in the first
place remains).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24381 a95241bf-73f2-0310-859d-f6bbb57e9c96
