BeOS didn't support transparent views. As documented in the Be Book,
SetViewColor(B_TRANSPARENT_COLOR) only effect is to not fill the
invalidated areas with the view color before calling Draw() (it avoids
flickering, especially when combined with B_FULL_UPDATE_ON_RESIZE).
A previous change made B_TRANSPARENT_COLOR actually make the view
transparent (that is, additionally to the above, the underlying view is
drawn before the transparent children), but it creates compatibility
issues.
In order to keep the API compatible with BeOS, the new behavior is now
enabled explicitly using the B_TRANSPARENT_VIEW flag. This also opens
for future developments like allowing a view color with an alpha
channel (not supported yet).
Adjust programs that require transparent views.
Fixes#15744, #15745.
Helps with #15645.
Change-Id: I529574ea23db0a23579521b263bc8d572775e35a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2275
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Cleans up the code around tab-switching and
also improves some logic around inserting
packages into the list of 'prominent'
packages by using a binary search.
If Haiku is installed into an environment with no
networking then it won't be able to talk to HDS
and so won't know which packages are promoted.
In this case switch the user to the "all packages"
tab so they are not shown a blank panel by default.
Relates to #14675, #14927
Change-Id: I14dd3be4af09a98245ddd0a9704bd8d53ed64a53
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2478
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The user might have changed their authentication details
on the server and the client won't detect this until
they go to do something. Instead, if possible, check
this as the client starts. Also check that the user has
agreed to the current user usage conditions.
As a side-effect this generalizes the logic for process
coordination in the main window and also fixes some bugs
in the main window's progress display as the application
starts.
Relates to #15209
Change-Id: I4c9620648819ecd14fb095e4cb2c66fe7b2a0920
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This adds documentation for BCardView, BCardLayout and BLayoutBuilder::Cards.
There is also a bit of cleanup for the BSplitView documentation.
It also makes explicit when a developer passes an invalid argument to
BCardLayout::SetVisibleItem(), by making that a debugger() call.
Change-Id: I17ac52cc773bb76c4f81beaa76f72af62a9e10f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2460
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
System dependencies and kernel interface code has been added.
Change-Id: I770ad6b906ca41d4d84d374cea209e22149fd727
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2344
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It seems clear that the architectural designs of rpmalloc are
just not suited for us in the "corner-cases", and probably never
will be.
After R1/beta2, I'll investigate switching us to musl's mallocng,
which is explicitly designed as a system allocator and has much
lower overall memory usage than even glibc's default allocator.
This received 84% on the forums, so it seems pretty uncontroversial
to enable it by default.
No other option received 70% or more, so I'll leave Humdinger to
decide what the other changes to the defaults should be based
on whatever threshold is decided upon...
wpa_supplicant needs to be rebuilt
against it and then this needs to be tested.
Added some FIXMEs to keep track of places I'm not sure if we need to
change anything.
Fixes#14805
Change-Id: I6379dc32b772289960afbfb362365a542a986983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2225
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Scroll bars should look and work identically to before on
HaikuControlLook.
Add DrawScrollBarButton() and DrawScrollBarThumb() and
DrawScrollBarBorder() methods. These methods are used to draw scroll
bars in a generic way so that they can be drawn differently by alternative
control look's (e.g. BeControlLook). Also it gives us back drawing of
scroll bar knobs. However the knob setting is not exposed in the
interface in this commit.
These methods are in addition to the 2 existing DrawScrollBarBackground()
methods that draw the scroll bar background. One draws the area above and
below the thumb and the other is called by the first to actually draw the
area.
The rest of the drawing besides the backgrounds was being done in
BScrollBar before. To draw the scroll bar arrows and thumb we were recyling
other ControlLook methods, while this worked well enough on HaikuControlLook
it wasn't flexible enough for alternative control looks.
DrawScrollBarButton() is used to draw the four scroll buttons and is
typically (so far) used in combination with DrawArrowShape().
DrawScrollBarThumb() draws the scroll bar thumb.
DrawScrollBarBorder() draws a 1px border around the entire scroll bar,
potentially B_KEYBOARD_NAVIGATION_COLOR if focused (although this is
feature not currently used.)
Draw unscrollable scroll bars as if they were disabled including the
buttons with their arrow shapes, background, and thumb.
Add FBC backwords compatibility macros in ControlLook.cpp
Change-Id: I9237c5ce45d17d674785111d51de951e5686306b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/351
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
In hrev53944 selection is cleared if text view lose focus, but it
don't work properly in StyledEdit, causing clearing selection when
menu is opened. Clear selection on lose focus is needed for text controls,
so when you click on another text control, previosly focused text
control should clear selection. This behavior is working in BeOS, so
some investigation is required.
Fixes#15810.
Change-Id: Ie104fc1d7e76c2cd2b97d3a0462856fe70cccbbf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2355
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
they should be compatible for I2C I/O
Change-Id: Ifc2bed29813403ef845ca60c9cc22187e2cacc88
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2469
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
busses/i2c needs to be probed also for acpi devices
Change-Id: Ib75b6e8db27361e395560d069dcbf136571b7a8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2463
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
type is acpi_handle, to be used with the ACPI bus manager
Change-Id: Ibbdd81a21bdd57fc651f7a7238e3676033204857
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2456
Reviewed-by: Rene Gollent <rene@gollent.com>
ACPI_DEVICE_HID_ITEM is now optional, instead of an empty string.
Change-Id: I352ffaaad377659f650a0b8c0d56e40a68b739c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2420
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
to find a node in the hierarchy.
Change-Id: Iee858f21ce134569bf25fccbef9fe18ea8787e9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2419
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The last time I checked, dogs don't have the power of telekinesis. :)
Primarily changed the Tracker icon in all places to have the Tracker
mascot hold the window in its mouth (like in BeOS), rather than the
window just levitating in front of the dog.
Change-Id: Ic60d3b0cb47e5995a639b494bf63af9ca21ef7d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2408
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This test just checks a default-constructed BNetworkAddress and a
BNetworkAddress that has had its Unset method invoked are in the same
state.
It also compares against a BNetworkAddress that has been constructed
with the AF_INET family. In BeOS R5 this worked because you could
construct a BNetworkAddress with nullptr for the host parameter, but
in Haiku this this leads to Unset() being invoked. So
BNetworkAddress(AF_INET, NULL) is the same as a default-constructed
BNetworkAddress object.
This patch just changes the test to construct the BNetworkAddress used
for comparison with a valid host using the IPv4 loopback address
instead.
Change-Id: Id890110cfa1f3c40a630f9005e2a390e25f6baae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2388
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
That's a bad idea. The drag and drop tracking could get confused enough
to crash app_server (possibly because of calling InitiateDrag multiple
times?)
Fixes#14983.
_CollectCopyInfo uses fBytesToCopy and fItemsToCopy for the sole purpose
of returning the scan results. This variable in turn was used to add to
the amount of files to copy in the progress bar, causing it to grow
exponentially with every CollectTargets calls.
With the current use case, the variable would have to be reset to 0
everytime CollectTargets is invoked, making it rather useless as a class
state.
This commit turns those variables into _CollectCopyInfo return values,
and also fix the exponential growth of the progress bar target.
Fixes#15826
Change-Id: Ib734febfdd8aaaa12fdfac61be124adb61b28f6c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2445
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
