I suggest using Object defaultBackgroundColor and refactor current use of
defaultBackgroundColor to defaultWindowColor which is what it is used as
currently in the image.

Then add backgoundColor to WindowColorSpec so all windows can specify their
background color in a theme.

Best,
Karl

On Tue, Jan 12, 2016 at 5:58 PM, karl ramberg <karlramberg at gmail.com> wrote:

> 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/20160113/474fa708/attachment.htm