Well, currentSettings is a delegation to the current theme settings...
Is equivalent to UITheme current settings.
Settings are abstracted out to declutter the theme.
The point I was making is that there are settings on the current theme
(volatile) and default settings per theme.
I take your point, for ease of overriding, but the settings (as called) ware
abstracted out since UITheme is already
quite a large facade...
I don't agree with settings being a dictionary, too many things are already
inexplicit!
Some kind of meta-description is appropriate though, for use in the Settings
browser. Is that
not the case already?
Regards, Gary
----- Original Message -----
From: "Igor Stasenko" <[email protected]>
To: <[email protected]>
Sent: Friday, January 14, 2011 5:40 PM
Subject: Re: [Pharo-project] [update 1.2] #12297
Well, i imagine that different themes can have a different set of
editable settings available,
and from that perspective the ThemeSettings is limiting, since
it contains a list of 'standard' properties, no more no less.
So, i proposing to rewrite all uses of:
UITheme currentSettings foo
with:
UITheme current foo
and let theme decide how to answer the requested value.
For example, one could do:
MyTheme>>fooColor
^ Color red "non-editable, hardcoded value"
while another one could decide to use color from settings:
MyCoolTheme>>fooColor
^ settings at: #fooColor default: Color red
And also each theme could tell settings browser, which public
properties it having,
so, depending on currently installed theme, user could see and change
only those, which related to it.
Then settings could be a simple dict, where keys is symbols and values
is property values.
and then, when you changing the current theme , it should simply do:
newTheme settings: oldTheme settings
so, nothing will be lost, even if new theme does not using some
properties, and when user will switching back to
old theme, it will continue using settings which already registered by/for
it.
On 14 January 2011 18:05, Gary Chambers <[email protected]> wrote:
Just FYI...
On the class side of UITheme there is the defaultSettings... used when
changing themes to initialise the new theme.
Handy for having settings that survive theme changes.
For those of you wanting to retain certain colour changes, this is the
thing
to edit. Should survive updates etc.
Would be nice to have Settings support for both the current and defaults
though ;-)
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <[email protected]>
To: <[email protected]>
Sent: Friday, January 14, 2011 12:00 PM
Subject: Re: [Pharo-project] [update 1.2] #12297
On 14 January 2011 12:33, Douglas Brebner <[email protected]>
wrote:
On 13/01/2011 22:04, Tudor Girba wrote:
That is a good point. I actually used the Sim Daltonism application
(for
Mac) to check the color blindness issues, but it looks like I
overlooked
Monochromacy (however, this is pretty rare). I will try to look into
that.
Cheers,
Doru
It's not just the colour blind that are affected (though they have it
worst). Even people with perfect vision can find it difficult to
distinguish
adjacent areas of similar contrast.
e.g. If you look at the save changes window that appears when quitting
an
image you'll notice the buttons almost disappear into the background.
Still, it's good that someone is working on this :)
yeah.. if you not cleaning your house, do not expect guests to come :)
--
Best regards,
Igor Stasenko AKA sig.
--
Best regards,
Igor Stasenko AKA sig.
