* Painter::StrokeLine() has an optimization for lines which are
single pixel dots, i.e. identical start and end point and pen
size 1: it sets the pixel directly in the buffer, completely
bypassing the AGG base renderer.
This is a problem when inside a layer since this also bypasses
the low-level offset in the base renderer (which moves drawing
coordinates into the layer bitmap), causing an out-of-bounds
access.
* Fixes#12587
Enforce use of proper colors in DrawLabel() when on the desktop.
This repairs an issue where the text looks wrong in ActivityMonitor when it is a
desktop replicant and likely other unreported issues.
Fixes#12576.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Was using the panel color without checking if we were the desktop view.
This corrects the reported issue where icon label outlines would look
incorrect.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Additionally to more robust pasting to sprunge (now checks if the
service is operational) the required curl version is now the one
that's actually in the HaikuPorts repo, 7.45.0.
Clipdinger 0.5 depended on a newer version, which rendered it uninstallable
with only the default HaikuPorts repo.
There's a messaging issue that results in pasting to sprunge twice, which
I'm still investigating. Releasing now, as it's not a debilitating bug.
PoseView's ColumnRedraw fills exposed areas in manually in an offscreen view
using the PoseView's LowColor. As QueryPoseView uses a custom view color it
is necessary for the low color to match, otherwise resizing a column will
draw the untinted document background color.
Fixes#12569.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
View color now shows through, so we keep the view color in sync with the
parent to act as the button background color. The low color is used to
determine the button color. The high color is used to determine the
button label color.
The default low and high colors are the control background and text colors,
respectfully. To maintain the identical appearance as before, the default
control background color is tinted to match the default panel background
color. As the color has a gradient applied anyway, no one will notice a
difference while playing with custom control colors.
Fixes#12568.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Recent changes require us to adopt the tint value for PowerStatus's
low color as well as the ViewUIColor.
This repairs the issue where the replicant's background color was lighter
than the Deskbar's tray color.
Fixes#12566.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* update_package_requires uses the latest version available, so haiku package
would then require a version 5.x of libgcc.
* Be sure to check that gcc_syslibs is installed and not gcc5_syslibs.
Adopted parent colors for the text view - should not have done so.
Disabled colors were incorrect, so I also corrected those in this patch.
Fixes#12574.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Previously the DataView relied on the default colors, which layout now
overrides more uniformly. The document colors are more appropriate.
After the addition of the layout changes, the DataView would adopt
system panel colors.
Fixes#12572.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
As per API documentation, a BView caches the configured view
colours when not yet attached to the app_server via its
window. So check if we're attached to a window, and if we are,
then and only then do we attempt to lock/unlock our looper.
This fixes uses of AdoptViewColors and AdoptParentColors when
the view isn't yet attached to a window.
Previously the layout would crush the default colors of BStringView preventing
BStringView from calling AdoptParentColors() on its own, so we must call it
manually.
In addition, the default tooltip view should fully adopt tooltip colors so
that any colors will default to the desired foreground color (which is the
same as the tooltip text color).
Fixes#12573.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* The actual problem is that the launch_daemon does not notice the
manual launch of system services (because of the missing registrar
that provides that service).
* So not checking if the print server is running actually solves the
issue; otherwise the launch_daemon starts its own server, that will
then get shut down, as there already is a print server (the one
launched by the Printers preferences).
* Closes ticket #12531.
The MIME type that's created by WonderBrush contains an out-of-date
sniffer rule. Archived BMessages used to start with '1BOF', now it's
'HMF1'. That's why newer WonderBrush images aren't identified as such.
The new sniffer rule should detect both old and new files.
