an approach to ColorSchemes (was: The Inbox: Morphic-kfr.1064.mcz)

> 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.

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 <[hidden email]> 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.

I suggest do remove/replace the WindowColorRegistry because it is an
hard-to-extend and difficult-to-update cache.

Please browse the methods in "prefs - window colors" on the class-side of
Preferences to gain a better understanding.

See Preferences class >> #installWindowColorsVia: as another example. For
the last two lines:

SystemWindow refreshAllWindows.
TheWorldMainDockingBar updateInstances.

...indicates that we need a mechanism to update existing morphs with new
color specs. Reopening an application is not an option in such a live
programming environment.

Best,
Marcel



--
View this message in context: http://forum.world.st/an-approach-to-ColorSchemes-was-The-Inbox-Morphic-kfr-1064-mcz-tp4870902p4871086.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.

I just want to prevent that somebody tries to extend or reuse
WindowColorRegistry for such a thing. :-)

Best,
Marcel



--
View this message in context: http://forum.world.st/an-approach-to-ColorSchemes-was-The-Inbox-Morphic-kfr-1064-mcz-tp4870902p4871133.html

Sent from the Squeak - Dev mailing list archive at Nabble.com.

Ok

Best,

Karl

On Wed, Jan 13, 2016 at 3:52 PM, marcel.taeumel <[hidden email]> wrote:

I just want to prevent that somebody tries to extend or reuse
WindowColorRegistry for such a thing. :-)

Best,
Marcel



--
View this message in context: http://forum.world.st/an-approach-to-ColorSchemes-was-The-Inbox-Morphic-kfr-1064-mcz-tp4870902p4871133.html

Sent from the Squeak - Dev mailing list archive at Nabble.com.