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

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 20 Aug 2012 22:19:51 +0200

Stephan Aßmus wrote:
> 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.

IMO there doesn't have to be a direct connection between what constants exist 
and what the user can/has to configure in the preflet. For all I care the color 
preference options could be removed entirely (I'd rather have accessibility 
options instead (high contrast etc.)). Assuming that the majority disagrees, I 
would support Stephan's suggestion to only make a few "base colors" 
configurable. I wouldn't cull the number of color constants, though, but simply 
derive their colors from the base colors.

CU, Ingo

Other related posts: