See http://www.freelists.org/post/haiku-development/Unifying-visuals-of-BTabView-usage
Besides the tab bar going the full width of the window, also some
layouting tweaks to several apps and prefs.
Still missing: the first (and last) tabs in the tab bar should be inset by
B_USE_WINDOW_SPACING so the controls in the tab view line up nicely.
I think I remember stippi wanting to look into it... :)
* This removes the CenteredViewContainer class, as it is no longer
being used.
* However, it also removes its functionality, ie. the Sudoku view now
fills the complete window (even without any borders), again.
The lock was only acquired when paths to watch were added or removed,
protecting the data structures against concurrent modification due
to addition/removal of entries by the API user.
Locking is also required for node monitor messages since these can
trigger the data structures to be modified (due to recursive watching
and new directories becoming available or due to resyncing of modified
ancestor chains).
Previously it was possible to corrupt the data structures when node
monitor messages were received while still starting to watch a directory
structure. This was especially likely in the case of watching devfs
directories, as accessing these can trigger device scanning which in
turn could possibly add new device entries. Either the path monitor
looper or the API user would then trip over the corrupted data
structures.
Probably fixes#11280. Although I was only able to reproduce crashes
on the API side, corruption of the hash tables and corresponding endless
loops are quite plausible.
Possibly also fixes#12412 if the input_server was in the process of
starting to watch entries. It's hard to tell due to the lack of a back
trace but would fit the crashes I was able to reproduce with a synthetic
test case.
Reduce duplication of code by
* Removing from elf_common.h definitions available in os/kernel/elf.h
* Deleting elf32.h and elf64.h
* Renaming elf_common.h to elf_private.h
* Updating source to build using public and private ELF header files
together
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Make a version of elf.h (assembled from the private header files
elf_common.h, elf32.h and elf64.h, and including Haiku's extensions for
C++) available to applications ported from UNIX.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* Services that end are now automatically restarted.
* However, this is very basic at the moment, there is no throttling,
and no support for shutting down the system.
* Ie. a listing of all targets/jobs, as well as specific (basic) info
on each.
* Also added a bit of optional debug output.
* Moved translating the path to launch time -- we should take the job's
environment into account here at some point.
Also print the locker sem (for manual name lookup) and the involved
threads. It was also missing the line terminator which messed up the
following output.
Also fix a typo in a comment.
Since a BLocker can be unlocked from other threads than the one holding
the lock, it can also be further unlocked even when already unlocked.
This caused the recursive count to become negative. The first lock then
needs to reinitialize the count to 1 for the lock balance to work again.
Just incrementing the negative recursive count lead to it never
counting back down from one to zero in the unlock case, which made the
BLocker impossible to unlock.
This makes the Haiku BLocker behave exactly like the BeOS one, including
the negative recursive count and reinitialization, as evidenced by its
debugging features showing the internal counts.
Alternatively to reinitializing the recursive count it could be
prevented from going below zero in the first place, but I don't see why
we should deviate from BeOS there while allowing its awkward unlock
behaviour.
This makes some more exotic use cases work like the BGLView <-> SDL
combination that previously would always just hang. While these abuses
should be reviewed/corrected, just hanging the BLocker doesn't seem
useful.
This was added in hrev47174 but isn't needed. (confirmed with jessicah)
the -e flag was causing the script to exit when it encountered an error
instead of allowing us to print an error message and exit ourselves.
I accidentially tried to compile Haiku on a case-insensitive FS and
tripped over this.
The configure script should print an error message if you try to configure
on a case-insensitive FS once again.
This adds to the "unittests" target a dependency on the
"AppTestRunApp3a" (etc.) files meant to be copied as part of the
BApplication test suite so they are generated when "jam unittests" is
run.
* TestsRules: Add "UnitTestDependency" rule.
* testapps/Jamfile: Make unit tests depend on copied files.
Fixes#12441.
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Having to upload the 650+ MiB source package with every new version is a drag.
People interested in the code can get it directly at
https://github.com/haiku/webkit/releases
* There is a small API change, and only the x86_gcc2 package was
updated. This means the x86 and x86_64 builds are broken until someone
updates the packages.
* Fix several small bugs, the most important one being that cookies are
written to disk again.
