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

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 20 Aug 2012 21:33:45 +0200

Ryan Leavengood <leavengood@xxxxxxxxx> schrieb:

>On Mon, Aug 20, 2012 at 2:49 PM, John Scipione <jscipione@xxxxxxxxx>
>wrote:
>>
>> I need a constant for both selected and unselected text. Should I
>make new
>> constants for list items?
>
>I kind of feel like we may already have an excessive number of
>constants, and while I can understand Axel's argument I don't know if
>we should add new constants. We could, but it is getting to the point
>where the Appearance preflet needs to be a bit more advanced, or we
>need to improve and integrate mmu_man's ThemeManager.
>
>For example in this case even if we had different constants for menu
>items and list items, the average use might be to have them match, and
>that is hard to do with the current preflet.
>
>Though it might be worse to have them both use the menu colors and
>then the user has no way to change the list item colors without also
>affecting menu colors. So maybe a new constant is more flexible.

Totally agreed that there are way to many constants and that the Appearance 
preflet is not ideal to use at all in this respect.

Most system color constants stem from Dano headers, they have not been present 
on R5.

When I first wrote BControlLook, I ignored the constants on purpose, since I 
don't believe they make sense and reflect how I would like to configure my 
system personally.

I believe there should be a single color (what B_PANEL_BACKGROUND_COLOR is now 
used for) that the user can pick. Then a "selection" color, a "focus" color and 
maybe a contrast setting that influences the shine and shadow tints. Ah yes, 
active and inactive tabs should be selectable.

With these few options, it should be possible to configure everything without 
risking bad looking results, even intermediate ones. The user is still free to 
chose non-matching and distasteful selection, focus and background colors, but 
why should it make sense to configure shine and shadow colors and different 
document text and panel text, list text and whatnot colors? In the direction 
that this is going, the user even *has* to configure all this stuff, even if he 
(sanely) prefers the same color for all stuff that should be the same in the 
first place.

So my plan was to drastically cut back the constants to R5 level and fix the 
tinting algorithms in BControlLook to work better when picking other or 
radically different "background" colors.

Best regards,
-Stephan

Hi,

Other related posts: