that actually work correctly (and treat the data as unsigned
characters).
* This fixes bug #724.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24458 a95241bf-73f2-0310-859d-f6bbb57e9c96
by NewOS are all broken. This is the actual reason for bug #724.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24457 a95241bf-73f2-0310-859d-f6bbb57e9c96
incorrect; only the length of the key matters, not if they are null
terminated. It would still return the correct value, though, it would
just access one byte beyond the buffer (which didn't really matter
in this specific case).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24456 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed the icons image, it was upside down.
* Support the new 24 bit boot screen images in the boot_loader and the kernel.
* Prepare the code for future indexed versions of the boot screen images.
But the generate_boot_screen tool currently does not generate those.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24449 a95241bf-73f2-0310-859d-f6bbb57e9c96
sure about the Copyright string. Should we really have that on the boot screen?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24447 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Release the resources needed for reading the PNGs and storing the image data.
* Change the semantics of the tool, previously it only supported palette mode
PNGs. Now I am doing the opposite, the tool tries to set up the PNG lib to
hand out RGB data, even stripping a potential alpha channel.
* Used standard Haiku license header.
* Improved output syntax.
* No longer depends on input image names, even with paths. The generated
output needs to have fixed names, or else the other source code will break.
* Made the use of the setjmp feature optional, depending on the PNG lib version
in use. This makes it possible to build the tool on BeOS without updating
the installed PNG lib.
* Added a few TODOs. Most important is to generate a single palette for all
three images, and storing the images in their palette representation along
with the full quality versions, so that they are ready during boot without
sucking up too many CPU cycles.
NOTE: The header which is now generated is not usable by the rest of the
source code yet, but that will come later. generate_boot_screen is not
integrated yet anyways.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24446 a95241bf-73f2-0310-859d-f6bbb57e9c96
locked.
* Removed some long and useless comments.
* Other minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24445 a95241bf-73f2-0310-859d-f6bbb57e9c96
prevent "configure" scripts from thinking we do actually support it.
Having real-time signals would be nice though (cf. #1935).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24444 a95241bf-73f2-0310-859d-f6bbb57e9c96
style couldn't be found, ie. when looking for "Roman", "Regular", and
"Book" are accepted, too, and "Italic"/"Oblique" are now synonyms as
well.
* This prevents StyledEdit from using the "Condensed" style when it does
not find a certain font.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24443 a95241bf-73f2-0310-859d-f6bbb57e9c96
able to resolve symlinks.
* file_open_entry_ref() now evaluates the openMode and passes the
correct "traverse" argument to entry_ref_to_vnode(). This fixes bug
#1932 (symlink refs wouldn't be resolved).
* dir_open_entry_ref() now always resolves symlinks, all other uses of
entry_ref_to_vnode() keep their previous behaviour, though.
* Fixed warnings; since Ingo's header changes, NULL now causes a warning
when it is used as int.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24442 a95241bf-73f2-0310-859d-f6bbb57e9c96
error string explaining the situation), causing bug #1934.
* When called without specifying an interface, it now chooses the first
suitable interface from the list as documented.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24441 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Build generate_boot_screen as a build platform tool. It requires
libpng to be installed.
* Added output file name as fourth argument.
* Replaced unnecessarily complicated
fwrite(<string>, strlen(<string>),...) and sprintf()+fwrite()
constructs by fputs() and fprintf() respectively.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24440 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Calculate icon offset from stage in splash.cpp, remove hard coded placement
values. Draw only icon, not the whole image from top/left to right of
icon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24439 a95241bf-73f2-0310-859d-f6bbb57e9c96
could be refactored to avoid code duplication (ie only cropping
implementations, with the non-cropping function being a special case of the
cropping version)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24436 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added the feature of an animated boot screen (icons lighting up at
different boot stages).
* Added first version of new boot splash images, generated by the new
hsbg tool. (Also finally contains the "new" Haiku logo.)
changes by myself:
* Added Artur to the contributors list in About System.
* Fixed some left overs in the patch, kept tracing turned off.
TODO:
* Remove the need for hard coding the icon positions. (Maybe generate
those from hsbg and put them into images.h? Have user provide icon
spacing/offsets at the command line for hsbg?)
* Rename the stages to something meaningful.
* Use hsbg as a build system tool and generate images.h during build
from PNGs provided in the artwork folder.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24434 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a tool to generate the "image.h" header from supplied PNGs,
which is going to be used by the new boot splash code.
TODO: Integrate this whole thing as a build system tool, complete with
source PNGs in the artwork folder. I am also in favor of renaming it
to something like "splash_gen" or similar if it has to be short.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24433 a95241bf-73f2-0310-859d-f6bbb57e9c96
picked might have changed while we were locking its cache. Might fix
#1931.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24430 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
