gGetHaikuDevMailingList->HelloAll();
Okay, so I've been busy on making a few changes to how the color system
works in Haiku, and I think I'm at a good place to split off and focus
on full font awareness and 3rd party apps. But, before that can happen
in earnest, this code needs to be signed off and applied to master.
Which will probably involve me mostly trying to please Axel, let's be
real here ;-)
In any event, here's a quick rundown of what has been accomplished:
1. BView gains the following methods:
HasDefaultColors() const
HasSystemColors() const
AdoptParentColors()
AdoptSystemColors()
AdoptViewColors(BView* view);
SetViewUIColor(color_which, float tint = B_NO_TINT)
SetHighUIColor(color_which, float tint = B_NO_TINT)
SetLowUIColor(color_which, float tint = B_NO_TINT)
color_which ViewUIColor(float* tint = NULL)
color_which HighUIColor(float* tint = NULL)
color_which LowUIColor(float* tint = NULL)
DelayedInvalidate(bigtime_t delay)
DelayedInvalidate(bigtime_t delay, BRect invalRect)
I will not go into describing how all of these work here, however most
people will just want to use AdoptSystemColors() and call it a day ;-)
2. All Haiku apps and preflets in the source tree have full live color
updating and some level of font awareness.
3. All system system interface elements should intelligently adopt the
colors of their parents, so legacy apps should have no issues (there are
a few exceptions that can't be helped, such as buttons and BBoxes added
directly to a window).
4. Spamming set_ui_color will see the events merged and updates will
only occur at a set 60hz rate, IIRC. A future update will make this a
system configurable option.
5. Spamming DelayedInvalidate() calls will merge redundant calls,
contrary to BeOS R5.1 behavior.
6. Tracker InfoView, AboutSystem, and others are now font-sensitive, so
you no longer need to use a magnifying glass to read the details on a
high def+ monitor - just set the font size and be happy.
7. Every window and view receives a B_COLORS_UPDATED message when any
color is updated, this message includes a BColorMap data structure that
can be accessed with static methods or you can instantiate a BColorMap
from the message directly. I will be documenting BColorMap once I am
sure its API is solidified (pending Axel et.al. feedback). In order to
cut down on the number of calls, these messages are merged together and
sent only about 60 times a second at a maximum, so the message may
include many colors which have been updated (possibly every color on the
system).
A word on performance:
I have taken great strides to ensure the optimal performance for this
system and to ensure things remain fluid, however I do not have much
slow hardware available to me so testers on the slowest hardware
available would be welcome. I can provide an install image if anyone is
interested and doesn't feel like building the source themselves.
A word on BeOS R5.1 dan0 API compatibility:
While dan0 had a method called SetViewUIColor it used const char*
constants, whereas this version uses the existing enumerated color_which
constants. Removing the _UI_ part of the dan0 constants should result
in a compiling program with the expected behavior.
DelayedInvalidate(), however, should be source compatible, with the
added benefit that calls are merged on the server side and the given
rects are potentially merged, resulting in less unnecessary redraws. As
with dan0, short delays make very little sense, this is meant to DELAY a
redraw, after-all.
-------------------
The source changes sound scary, as there are nearly 400 changed files.
MOST of these are simply modifying SetViewColor to SetViewUIColor(), as
before.
Single-file formatted patchset:
http://files.looncraz.net/SetViewUIColor-V3.patch
About 1MB
Diff from master:
http://files.looncraz.net/SetViewUIColor-V3-diff.patch
About 500KB
-------------------
Looking forward to the coming ridicule,
--The loon
