We already have the WindowColorRegistry, so we could extend that to have
background color

Best,
Karl

On Tue, Jan 12, 2016 at 5:40 PM, Chris Muller <asqueaker at gmail.com> wrote:

> > ScrollPanes should not have any knowlegde about SystemWindow. So storing
> the
> > preference in SystemWindow >> #backgroundColor is not an option.
>
> +1, but that is tangential to our discussion at the moment -- we just
> want to establish our "design" for enabling the ability to have
> different color sets.
>
> > It would make sense, however, to attach individual preference to those
> major
> > widgets. So that ScrollPane has its own #backgroundColor.
>
> Use-case #1 is:  I'm working during the day, I want a brighter,
> black-on-white scheme, when night comes, I want to "one-click" switch
> to a white-on-black scheme **without changing or having to
> double-manage** any of my other Preferences in the system -- they
> remain untouched.
>
> I'm concerned that individual preferences scattered across a bunch of
> global class vars would inhibit my use-case above.  Are you saying I
> would have to go into Preferernces panel and change the 30-50
> "individual preferences" to go to night mode?  To have "color themes"
> someone would have to write a methods to update all the globals,
> something like this:
>
>     ScrollPane backgroundColor: ...
>     ScrollPane foregroundColor: ...
>     SystemWindow titlebarBackgroundColor: ...
>     SystemWindow titlebarForegroundColor: ...
>     UserDialogBoxMorph backgroundColor: ...
>     UserDialogBoxMorph foregroundColor: ...
>
> And what package would such methods be written in?  They have to
> reference the entire system, so there would be dependency issues.
> Every time we discover a new thing needing color we'll have to update
> this method...
>
> That's why I think we store colors into ColorSchemes which can be
> swapped out whole and grow organically instead of a bunch of
> class-vars.  I don't care about exact the implementation details, just
> that we make something flexible and easy to use and maintain, not
> brittle.  Please.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160112/bc7f932f/attachment.htm