[haiku-development] ui_colors (was: [haiku-commits] Re: r38122 - in haiku/trunk: headers/os/interface src/bin)

  • From: François Revol <revol@xxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 15 Aug 2010 20:46:30 +0200

Le 15 août 2010 à 20:27, Axel Dörfler a écrit :

> François Revol <revol@xxxxxxx> wrote:
>> Le 15 août 2010 à 19:25, Axel Dörfler a écrit :
>>> revol@xxxxxxx wrote:
>>>> Log:
>>>> Add synonyms for tootip ui_color constants.
>>> Why? Please remove those again.
>> Well I do have code that use them :p
> 
> Then fix it. There is absolutely no reason to introduce Dano source
> compatibility cruft.

Pssst.

I really need B_RANDOM_COLOR,
B_MICHELANGELO_FAVORITE_COLOR and friends!!!

>> Btw, we lack more also...
>> At least one for the (inactive) window border.
> 
> That's decorator dependent, so I'm not sure we should have one, but
> that would probably be an okay addition.

Do we have a way to get those from the decorator itself globally ?
Hmm or maybe from a BWindow with the tab position ? I suppose I could use 
ThemeManager's own window.

>> Also, the input method colors should probably be here as well
>> instead of hardcoding them.
> 
> Good point!

B_INPUT_METHOD_TRANSACTION_COLOR
B_INPUT_METHOD_CLAUSE_COLOR
?

ZETA had B_DOCUMENT_LINK_COLOR and B_PANEL_LINK_COLOR, those might be useful 
too.

Btw, Dano had those string-based versions of Set*Color() to have them updated 
automatically.

I still don't see why they used strings here though, maybe we could have 
versions taking color_which instead ?
Cause there is really a lot to do to get things looking good, specially with 
dark bg.

We could probably even override the original ones...
Hmm why are those virtual anyway ?

BControlLook is interesting but it doesn't take all colors as parameters, which 
makes it impossible to use as a preview...

François.

Other related posts:

  • » [haiku-development] ui_colors (was: [haiku-commits] Re: r38122 - in haiku/trunk: headers/os/interface src/bin) - François Revol