This code is quite convoluted and very much in need of refactoring,
but this solution works well enough for the time being. It does not
look quite right at higher resolutions (borders come out darker than
they do at the default resolution), but at least the borders are now
the correct size instead of a constant one.
The resize nub drawing code also hasn't yet been updated, so while
it draws the gradient over the full resize area and responds to clicks,
the "checkerboard" pattern is drawn at a fixed small size still.
Nonetheless, this is a significant improvement.
There is nowhere else that unsets it (or makes sense to unset it),
we have to do it here, or otherwise it will never be unset.
This has actually been broken since the new scheduler was merged
many years ago; the old scheduler (which had more complex logic here)
unset this flag correctly.
This oversight mostly did not cause obvious problems: while the scheduler
would be invoked unnecessarily on every single interrupt, that would
be a minor performance downturn at most. But there is one other effect:
since we can only reenable interrupts after invoking the scheduler,
"post_interrupt_callback"s of threads were not invoked most of the time.
The main user of "post_interrupt_callback"s is the profiler, which uses
them to trigger buffer flushes back to userland. Since they were not
invoked, the buffer would quickly fill up and then no more results
would be recorded.
Thus, this fixes#16345.
Extracted as separate patch from CR 4790; implement BFont::BoundingBox
as it was in BeOS. Returns a BRect that encloses any character in a
font, scaled by the font size.
Since the FreeType bbox is only valid for vector outlines, for bitmap
fonts, return a BRect with the dimensions of the bitmap font that is
closest to the font size.
Tested with CharacterMap. Will update CharacterMap to use the bounding
box once this change is landed.
Note that bitmap font rendering doesn't appear to work at all.
Change-ID: I8fc42ca0ddc0c77e04e0216001cd17e086ec7495
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5431
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The local state scale is applied from the origin. That is, the origin
value does not change with the local scale.
This fixes the value returned by BView::Origin() when recovered from the
app server instead of from the client cache.
Change-Id: Id628d8f334fab06e6a6d084c079cdca1cfa914c6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5443
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Implemented the missing POSIX functions in <locale.h>:
newlocale, duplocale, uselocale, and freelocale, and also
provided missing type definitions for <locale.h>.
Implemented missing POSIX locale-based function variants.
Modified LocaleBackend so that it could support thread-local
locales.
Some glibc-like locale-related variables supporting
ctype and printf family of functions have also been updated
to reflect the thread-local variables present in the latest
glibc sources.
As there have been some modifications to global symbols
in libroot, libroot_stubs.c has been regenerated.
Bug: #17168
Change-Id: Ibf296c58c47d42d1d1dfb2ce64042442f2679431
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5351
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This commit introduces a simple thread-safe ring buffer implementation
based on top of BDataIO. The main use case for this class will be to
implement shared buffers between threads for the upcoming refactoring
of Services Kit.
Change-Id: I526bc044b28c91496ad996fabebe538e75647f2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2966
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
For mouse probing to work reliably, it's important that we don't
simultaneously send commands to the keyboard as well. This normally
happens because we don't publish the keyboard device until the probing
is complete.
However, if the mouse probing results in the keyboard sending some
replies, this can be detected as a "hot plugin" and leads to publishing
the keyboard device a lot earlier.
To prevent this, disable the "hot plugin" feature until we are done
initializing. This way the keyboard device is published only after we
are done with the probing.
Fixes#17806
Change-Id: Ia6a2b031550c845fa305df5b5f4d513d5c7931d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5388
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Before this patch, calling functions in the `printf` family and
passing %F in the format string, such as
printf("%6.2F\n", 580.0f);
would incorrectly output numbers in the exponential format:
5.8D+02
This patch fixes the output for this situation:
580.00
and fixes the behavior for programs that use %F, such as
several tests for the `fish` shell.
Change-Id: I124a5a7b93b5f551fa190501a5778726812d347c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5424
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This is for platforms where information from parsed ACPI namespace
is necessary to fully configure PCI subsystem.
Change-Id: I8bdcfab6b99cbe7fdbc902b9fc13b44133325961
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5273
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Previously, any accelerants failing would cause an
app_server crash.. so we would do everything in our
power to get "something"
* After hrev56252, the app_server properly handles
accelerant failures and vesa / framebuffer accelerants
should will be used.
* Thus, if no monitors were detected (due to none being
plugged-in, or some other fault), bail and return B_ERROR
so vesa fallback can give it a try.
Change-Id: Ib9695dd7cf1914e50547ca8661c55b80152a66a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5442
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
As far as I can tell, nothing checks these, so this should not
actually make any kind of difference.
The timeout_set change is also not a functional one, either,
as callout_init with mpsafe=0 uses &Giant also.
* Do not open() devices while looping but only open() the one
we were actually asked to open.
* Try the VESA or Framebuffer driver even if deviceNumber is something
other than 1.
* Start iterating at 0 instead of 1 following loop iteration changes.
Ideally this iteration should occur a completely different way, in order
to properly support multiple graphics cards, but that's a problem for
another day.
Fixes#4303.
AccelerantHWInterface and the Remote engines already did this.
These are not used at all outside of test_app_server, so we do not
need to even compile them in to the regular one.
Some syscall headers are generated during the build process, and jam is
not smart enough to add an automatic dependency.
Change-Id: I7c19da7aca9da4a52c4537a5f5c279fdbe24a48a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5435
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Set a flag if TFilePanel::RestoreState successfully reads the
FilePanelSettings file.
* Check for this flag in BFilePanel::Show.
* Part of #17374.
Change-Id: I4431c01f9282fe411fa7b30667215bba9249bd96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5433
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The referenced section of the specification gives no indication that
the bit should not be set if there was no data; indeed it indicates
it should always be set.
This brings our behavior here in line with other OSes seem to do.
Change-Id: I86b2eb2a6a5fa3af84fd0941e0a3ec601c7037bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5421
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
