[haiku-commits] Re: haiku: hrev44567 - in src: preferences/appearance kits/interface preferences/locale

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 21 Aug 2012 16:48:41 +0200

Am 21.08.2012 17:41, schrieb Axel Dörfler:
Am 20.08.2012 22:21, schrieb John Scipione:
I have been struggling with this for some time. There are clearly too
many color constants right now, the user should not have to select
between 30+ options just to change a single color setting.

Those are two different things -- I'm all with Ingo on this, btw: the
color constants should stays mostly (could possibly cleared up as Stippi
pointed out), but should even be made more complete instead.

Ok, you guys convinced me. If we go that route, it may indeed be wise to extend the list some more. But then BControlLook needs to be fixed. Basically, I tweaked the tinting values until they looked perfect to my eye, with the 216 default background grey.

IIRC, tint_color() was "reverse engineered" until it gave almost the exact results as the BeOS R5 version, but I don't know if it works as good as it can. If it were to work perfectly, then using a different background color should give "similar" appearance of shine and shadow shades, but it does not, especially for much darker background colors.

On top of that, some border painting methods in BControlLook support rendering over an existing background. In those cases, the tinting is replaced with using transparent black and white for the shadow and white, again with tweaking the exact alpha channel values until it looked good to me. I suppose that doesn't even work for non-gray background colors (using black and white I mean).

Also I don't know how much sense the current API of BControlLook makes with regards to passing the reference background color to most methods. On one hand, it is very convenient when using a color other than B_PANEL_BACKGROUND_COLOR (see for example DeskCalc or Keymap buttons). But when passing such an alternative color, it would make no sense to use pre-defined and cached colors in BControlLook for shine and shadow. Passing all colors used for the various frames makes no sense either, since the purpose of BControlLook is to abstract the look, so the caller should have no knowledge what system colors are used in what type of frame, and how.

In light of this, maybe getting rid of the shadow and shine constants does make sense after all and calculating the tints in BControlLook is the best compromise. Despite the wasted performance by not caching these values. It's probably neglectable anyway.

Best regards,
-Stephan

Other related posts: