[update 1.2] #12297
Locked
12
12
 
|
here is updated version of it.
more consistent colors (note the ">" button now not highlighted by default, also added thin border for lists and thin border for system windows, and removed 1pixel-wide shadow for system window. -- Best regards, Igor Stasenko AKA sig. |
GLMOrangeUITheme.st (7K) |
|
In reply to this post by Douglas Brebner
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 On 13 Jan 2011, at 16:22, Douglas Brebner wrote: > On 13/01/2011 11:29, Tudor Girba wrote: >> I tried to start from zero and add a new variable (e.g., color) only when I could not distinguish something. There are still things that are superfluous (e.g., the border around all tabs, or the bulky shape of an expander), but I did not have enough time and Morphic expertise to do better. >> >> Now, orange vs blue is actually not just a matter of taste because your orange is not the same as my blue. There are two reasons: (1) it is stronger, and (2) it appears in more places (e.g., at the bottom of the scrollbar). This means that it will compete for my attention with more force. This might be your intention, but it is not mine because it takes away from my main focus which is the content. >> > > I admit that I do like the blue for selections. > However, I find that the blue gradient on the buttons is difficult to see clearly. > > I suspect this is because the chosen blue has high contrast against the white background of the list but *extremely* poor contrast with the grey button/frame background. If you look at the browser in greyscale, the difference stands out starkly (see the attached image). > > I also find all of the buttons without white borders seem to blend into the background so much as to become difficult to distinguish. > > Otherwise, I do like it :) > <Pharo-button-grey.jpg> -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." |
|
|
In reply to this post by Igor Stasenko
I like the simple border around the windows. I adopted it in the Glamorous Theme :)
Cheers, Doru On 13 Jan 2011, at 19:36, Igor Stasenko wrote: > here is updated version of it. > more consistent colors > (note the ">" button now not highlighted by default, > also added thin border for lists > and thin border for system windows, > and removed 1pixel-wide shadow for system window. > > > -- > Best regards, > Igor Stasenko AKA sig. > <GLMOrangeUITheme.st><GLMOrangeUITheme.png> -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." |
|
|
On 13 January 2011 23:09, Tudor Girba <[hidden email]> wrote:
> I like the simple border around the windows. I adopted it in the Glamorous Theme :) > btw, i suggest you to fix all the places to use theme settings instead of direct colors, so your theme settings could be changed from Settings UI For example: glamorousBaseSelectionColorFor: aButton ^ settings selectionColor instead of: glamorousBaseSelectionColorFor: aButton ^ self class baseSelectionColor and by changing 'Selection color' in settings, i can change Orange->Blue :) Btw, there is a bug in Polymorph, it ignores the 'Find replace selection color' setting There is one widget which doesn't honors the text selection color - find and replace dialog. Btw, it would be cool to make theme consistent with all colors, used by settings (filter by *color*) > Cheers, > Doru > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Tudor Girba
doru
could push a new version in the inbox? Stef On Jan 13, 2011, at 11:09 PM, Tudor Girba wrote: > I like the simple border around the windows. I adopted it in the Glamorous Theme :) > > Cheers, > Doru > > > On 13 Jan 2011, at 19:36, Igor Stasenko wrote: > >> here is updated version of it. >> more consistent colors >> (note the ">" button now not highlighted by default, >> also added thin border for lists >> and thin border for system windows, >> and removed 1pixel-wide shadow for system window. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <GLMOrangeUITheme.st><GLMOrangeUITheme.png> > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > > > > > |
|
|
Done.
Doru On 14 Jan 2011, at 09:06, Stéphane Ducasse wrote: > doru > could push a new version in the inbox? > > Stef > > On Jan 13, 2011, at 11:09 PM, Tudor Girba wrote: > >> I like the simple border around the windows. I adopted it in the Glamorous Theme :) >> >> Cheers, >> Doru >> >> >> On 13 Jan 2011, at 19:36, Igor Stasenko wrote: >> >>> here is updated version of it. >>> more consistent colors >>> (note the ">" button now not highlighted by default, >>> also added thin border for lists >>> and thin border for system windows, >>> and removed 1pixel-wide shadow for system window. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> <GLMOrangeUITheme.st><GLMOrangeUITheme.png> >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that happen. They both matter." >> >> >> >> >> >> > > -- www.tudorgirba.com "Value is always contextual." |
|
|
In reply to this post by Tudor Girba
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 :) |
|
|
On 14 January 2011 12:33, Douglas Brebner <[hidden email]> 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. |
|
|
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" <[hidden email]> To: <[hidden email]> Sent: Friday, January 14, 2011 12:00 PM Subject: Re: [Pharo-project] [update 1.2] #12297 > On 14 January 2011 12:33, Douglas Brebner <[hidden email]> > 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. > |
|
|
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 <[hidden email]> 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" <[hidden email]> > To: <[hidden email]> > Sent: Friday, January 14, 2011 12:00 PM > Subject: Re: [Pharo-project] [update 1.2] #12297 > > >> On 14 January 2011 12:33, Douglas Brebner <[hidden email]> >> 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. |
|
|
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" <[hidden email]> To: <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> >> To: <[hidden email]> >> Sent: Friday, January 14, 2011 12:00 PM >> Subject: Re: [Pharo-project] [update 1.2] #12297 >> >> >>> On 14 January 2011 12:33, Douglas Brebner <[hidden email]> >>> 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. > |
|
|
In reply to this post by Igor Stasenko
Example:
UITheme currentSettings windowColor: Color orange. World themeChanged. UITheme current class defaultSettings windowColor: Color lightBlue. World themeChanged. " no change" UITheme currentSettings windowColor: Color yellow. World themeChanged. UITheme current class beCurrent "uses default of light blue" Switching between themes uses the theme defaults rather than any modifications to the current theme. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> To: <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> >> To: <[hidden email]> >> Sent: Friday, January 14, 2011 12:00 PM >> Subject: Re: [Pharo-project] [update 1.2] #12297 >> >> >>> On 14 January 2011 12:33, Douglas Brebner <[hidden email]> >>> 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. > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |