Okay,
So, I implemented the messages in way I think works best.
B_FONTS_UPDATED and B_COLORS_UPDATED are sent to each window and each
view attached to a window.
The messages (for now, at least) do not contain any helpful information
as I am not entirely certain whether or not the changes I would need to
make are worth it - or if there is a better way to go about this.
Due to the way the Appearance preflet blindly resets all default colors
and fonts when invoking "Default," I found it necessary to have the
DesktopSettings check to see if the new value was different than the old
value. This worked perfectly, and now only notifications are made when
a color is actually changed. I did not worry about this for fonts, as
there are only three monitored font categories...
Menu font changes are not currently sending a notification as the code
is wrapped up in menu_info, so I will need to check to ensure the font
changed, in any way, from the current setting before the message is
sent, otherwise we will have menus rebuilding themselves needlessly -
even though they aren't visible.
Here's the patch:
http://files.looncraz.net/0001-Font-and-Color-Update-Messages.patch
It's quick, simple, and to the point. And it works very well (changing
the panel color changes my overly complex test window's many many many
views' colors seemingly instantly, while still dragging the control
around - just like I wanted :-)).
Once this gets a nod, I'll implement SetViewUIColor - and maybe
SetHighUIColor, and SetLowUIColor, if desired.
Another, related, feature (and another 5.1 ripoff) is
DelayedInvalidate(). If anyone sees a use for this, beyond me, let me
know, as it just delays sending Invalidate() to the server for a certain
amount of time, which is useful for limiting how often you update a view
without a great deal of timing code (mind you, multiple
DelayedInvalidate() calls, in R5.1, will result in multiple Invalidate()
calls, but I'd prefer for them to merge).
--The loon
