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>
While pipe() only supports a read end and a write end, named FIFOs
are supposed to allow opening in read/write mode (which, indeed,
is something the Fish shell seems to require.)
The code that checks open_mode in the read/write routines was introduced
all the way back in 2003 (2469f26dfc).
At that time, the VFS did not do open_mode checks on FDs in the
I/O syscalls, so these doubled as permissions checks. Now, however,
the VFS does check that in common_user_io, so we can remove these
entirely and let things behave as they should.
Additionally, there is now also no reason to prevent select()ing
on both events for the same FD independent of open_mode, so
allow that too.
Change-Id: Ib3cba76d18e91b7c00d1695e8d29dd47cae06b79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5427
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
