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.
What appeared to be multiple issues was just one issue: BButton was drawing the
control background color for its border, whereas the previous system drew the
control low color, which was the parent's view color.
Neither is correct, no border should be drawn at all.
This made it appear that the default button was larger than it was and also
made it appear that some apps had a "white" border around the buttons.
In addition, BButton can now use the default BControl color behavior and
BButton exclusively adopt either parental or system colors without worrying
about the case in which another view has set the button's view color manually.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Previous colors matched the menu background color, but should have been
darkened.
The tint value was not being updated for the SetViewUIColor call construction,
therefore the tint parameter was still B_NO_TINT.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Repair regression where low color for text drawing was not set properly.
Do not use tinted color for default color state.
Prior to this, the hinting font would not respond to being pressed and the
column title background was the wrong color initially, but correct after
resizing (but then wrong again after a redraw on exposure).
In addition, the initial tint values used for the view color were unused,
so I removed them.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
* The direct methods in BMailProtocol now forward the request to the
looper; it's no longer the mail_daemon's responsibility to know
anything about that protocol.
* It's in desperate need of refactoring, but it doesn't hurt to add
it to the repository as is.
As suggested by Christopher Sean Morrison:
"Curiously, the two svg files lack styling / namespace declarations so
they won’t render in a browser. Adding an xml namespace to their <svg>
opening tag lets them render correctly: xmlns="http://www.w3.org/2000/svg"
Thanks!
