- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about text selection colors in 1.2

by Alain Plantec

Le 13/01/2011 14:27, csrabak(a)bol.com.br a Ã©crit : > Mariano, Alain, > > This is a *big* theme! yes! too difficult for me and unfortunately, not enough time to learn. anyway, thanks for the links. > It would require a person with appropriate training and expertise to help us to find the "right" set of colors to address this. > > http://www.internettg.org/newsletter/mar99/accessibility_color_challenged.h… > (see especially the refs of this excellent article) > > This site has a "color simulator" which allows designers to "see" how color would appear to color blind people http://www.webexhibits.org/causesofcolor/2.html > > This may help us to create means to test our color schemes: http://colororacle.cartography.ch/ > > HTH > > -- > Cesar Rabak > >

Jan. 13, 2011

Re: [Pharo-project] [update 1.2] #12297

by Alain Plantec

Le 13/01/2011 13:54, Igor Stasenko a Ã©crit : > Here the 'fix' to orange theme.. > i renamed the class and theme name > > also i made an 'underline' highlighting a bit tinier. > > In screenshot you see a text selection is grayed out.. This is > highlighting color of editor with inactive focus.. > I think it should be different (imo it should use a pale modification > of theme's selection color, rather than plain gray). you can change it with unfocusedSelectionColor and unfocusedSelectionColor: in ThemeSetting. maybe change the default value in ThemeSetting>>unfocusedSelectionColor. Cheers Alain > Still, have no clue, what package name to use it.. > Morphic-Themes > ? >

Jan. 13, 2011

Re: [Pharo-project] about text selection colors in 1.2

by Guillermo Polito

Shouldn't we choose some pastel colors for UI? :P A very strong orange or blue or whatever, always look... uncomfortable. On Thu, Jan 13, 2011 at 10:23 AM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Le 13/01/2011 13:11, StÃ©phane Ducasse a Ã©crit : > > On my mac I always use orange for selection else I do not see it and I'm >> not color blind. >> > ah! colors ... :) > Orange is already used for find & replace color. > maybe light orange for secondary selection and orange (I mean darker > orange) for find & replace color. > > > Stef >> >> On Jan 13, 2011, at 11:27 AM, Alain Plantec wrote: >> >> Le 13/01/2011 11:16, Mariano Martinez Peck a Ã©crit : >>> >>>> >>>> On Thu, Jan 13, 2011 at 10:39 AM, Alain Plantec<alain.plantec(a)free.fr >>>> <mailto:alain.plantec@free.fr>> wrote: >>>> >>>> Hi all, >>>> A friend of mine told me that it was very difficult for him to see >>>> the difference between the >>>> green and the blue colors. (Color blindness...) >>>> So, I would suggest to change the secondary selection color >>>> (green) to another color. >>>> >>>> >>>> yes, the green is very very difficult to see. >>>> >>> yes, this had to be changed >>> >>>> What do you think ? which color ? >>>> >>>> >>>> light yellow? grey ? I don't know :( >>>> >>> for testing, you can change it from the setting browser >>> >>>> Cheers >>>> Alain >>>> >>>> >>>> >>>> >>> >> > >

Jan. 13, 2011

Re: [Pharo-project] about text selection colors in 1.2

by csrabak＠bol.com.br

Em 13/01/2011 08:16, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > On Thu, Jan 13, 2011 at 10:39 AM, Alain Plantec > <alain.plantec(a)free.fr> wrote: > Hi all, > A friend of mine told me that it was very difficult for him to see > the difference between the green and the blue colors. (Color > blindness...) So, I would suggest to change the secondary > selection color (green) to another color. > > yes, the green is very very difficult to see. What do you think ? > which color ? > > light yellow?Â Â grey ?Â Â I don't know :( Cheers Mariano, Alain, This is a *big* theme! It would require a person with appropriate training and expertise to help us to find the "right" set of colors to address this. http://www.internettg.org/newsletter/mar99/accessibility_color_challenged.h… (see especially the refs of this excellent article) This site has a "color simulator" which allows designers to "see" how color would appear to color blind people http://www.webexhibits.org/causesofcolor/2.html This may help us to create means to test our color schemes: http://colororacle.cartography.ch/ HTH -- Cesar Rabak

Jan. 13, 2011

Re: [Pharo-project] about text selection colors in 1.2

by Alain Plantec

Le 13/01/2011 13:11, StÃ©phane Ducasse a Ã©crit : > On my mac I always use orange for selection else I do not see it and I'm not color blind. ah! colors ... :) Orange is already used for find & replace color. maybe light orange for secondary selection and orange (I mean darker orange) for find & replace color. > Stef > > On Jan 13, 2011, at 11:27 AM, Alain Plantec wrote: > >> Le 13/01/2011 11:16, Mariano Martinez Peck a Ã©crit : >>> >>> On Thu, Jan 13, 2011 at 10:39 AM, Alain Plantec<alain.plantec(a)free.fr<mailto:alain.plantec@free.fr>> wrote: >>> >>> Hi all, >>> A friend of mine told me that it was very difficult for him to see >>> the difference between the >>> green and the blue colors. (Color blindness...) >>> So, I would suggest to change the secondary selection color >>> (green) to another color. >>> >>> >>> yes, the green is very very difficult to see. >> yes, this had to be changed >>> What do you think ? which color ? >>> >>> >>> light yellow? grey ? I don't know :( >> for testing, you can change it from the setting browser >>> Cheers >>> Alain >>> >>> >>> >> >

Jan. 13, 2011

Re: [Pharo-project] DuplicatedVariableError: styler is already defined in PluggableTextMorph

by Guillermo Polito

On Thu, Jan 13, 2011 at 5:26 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > There is a fix already submitted to PharoTaskForces. > > Where what bug entry? > Today some of ConfigurationOfOmniBrowser packages rely on PharoTaskForces. Mmm, I did and integrated those "fixes" in order to build 1.2 full. I submitted them into PharoTaskForces because I've no access to lukas repo, and I don't know what does he what to do with those changes... > > > > If you download the last version from the metacello config, it should > load well :). > > > > Cheers! > > > > On Wed, Jan 12, 2011 at 4:05 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > When trying to do: > > > > Gofer new renggli: 'omnibrowser'; > > package: 'OmniBrowser'; > > package: 'OB-Standard'; > > package: 'OB-Morphic'; > > package: 'OB-Shout'; > > package: 'OB-Refactory'; > > package: 'OB-Regex'; > > package: 'OB-SUnitIntegration'; > > load > > > > (Part of the build scripts of LR's builder scripting package) > > > > I get the following error: > > > > DuplicatedVariableError: styler is already defined in PluggableTextMorph > > > > while loading the definitiion of OBPluggableTextMorphWithShout in > PharoCore 1.2 #12294. > > > > I have seen some things flying around on the mailinglist related > indirectly to this issue. > > > > Is there a solution ? > > > > Thx, > > > > Sven > > > > > > > > >

Jan. 13, 2011

Re: [Pharo-project] [update 1.2] #12297

by Geert Claes

Igor Stasenko wrote: > > we're talking about changing single color, not introducing new colors. > > And i really don't like the button highlighting in original glamorous > theme.. > pale blue to gray gradient makes me vomit, that's why i changed the way > how to indicate 'selected' button appearance, and i think this is more > coherent with Glamorous vision :) > I have 3 main remarks regarding the Glamourous(2) screenshots: - buttons need to look more like buttons: maybe a slightly rounded edge? - the "Instance/?/Class" group are not really a normal buttons: probably something along the lines of the "List/Day/Month" - avoid using too many colours (a darker grey would probably be better than blue or orange) If it was easier to customize themes, I would give it a go http://forum.world.st/file/n3215801/GLMUIThemeIdeas.png http://forum.world.st/file/n3215801/GLMUIThemeIdeas.png GLMUIThemeIdeas.png -- View this message in context: http://forum.world.st/update-1-2-12297-tp3215517p3215801.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 13, 2011

Re: [Pharo-project] [update 1.2] #12297

by Igor Stasenko

Here the 'fix' to orange theme.. i renamed the class and theme name also i made an 'underline' highlighting a bit tinier. In screenshot you see a text selection is grayed out.. This is highlighting color of editor with inactive focus.. I think it should be different (imo it should use a pale modification of theme's selection color, rather than plain gray). Still, have no clue, what package name to use it.. Morphic-Themes ? -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2011

[Pharo-project] Fwd: Zinc HTTP Components: Zinc-HTTP-SvenVanCaekenberghe.116.mcz

by Sven Van Caekenberghe

Thanks, Tony, for reporting this! Sven Begin forwarded message: > From: squeak-dev-noreply(a)lists.squeakfoundation.org > Date: 13 Jan 2011 14:39:04 GMT+01:00 > To: sven(a)beta9.be, arturus(a)gmail.com > Subject: [SPAM] Zinc HTTP Components: Zinc-HTTP-SvenVanCaekenberghe.116.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: > http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenbergh… > > ==================== Summary ==================== > > Name: Zinc-HTTP-SvenVanCaekenberghe.116 > Author: SvenVanCaekenberghe > Time: 13 January 2011, 1:39:01 pm > UUID: a102bbdc-8185-41b0-afa2-4d0af8f2557a > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.115 > > changed the redirect behavior for POST/PUT requests: the common practice is to turn these into GET request, see ZnUserAgent>>#method:for:headers:data:imit: and ZnUserAgent>>#prepareRedirect: On 12 Jan 2011, at 20:34, Tony Fleig wrote: > My interpretation of what is intended by 303 is that server is saying > that the resource requested by the POST has been found (or generated) > and may be obtained by GETting the URI in the Location header field. > > This is in fact what happens all the time in Seaside. The POST request > performs the callbacks, essentially changing the server state, and > returns 302. The client then does a GET to retrieve a page that > reflects the changed server state. Seaside should probably return 303 > to be in compliance with the spec, but pre HTTP 1.1 browsers may not > recognize 303, so I guess that's why it is like it is. > > I think the 303 required behavior is clear. ZnHttpClient should do a > GET after receiving a 303 response. 302 is less clear because of the > incorrect behavior of most browsers. For 302 I suppose a setting would > make sense to allow either the common browser behavior or the strict > interpretation of the specification behavior. > > Regards, > TF > > RFC 2616 Excerpt: > > 10.3.3 302 Found > > The requested resource resides temporarily under a different URI. > Since the redirection might be altered on occasion, the client SHOULD > continue to use the Request-URI for future requests. This response > is only cacheable if indicated by a Cache-Control or Expires header > field. > > The temporary URI SHOULD be given by the Location field in the > response. Unless the request method was HEAD, the entity of the > response SHOULD contain a short hypertext note with a hyperlink to > the new URI(s). > > If the 302 status code is received in response to a request other > than GET or HEAD, the user agent MUST NOT automatically redirect the > request unless it can be confirmed by the user, since this might > change the conditions under which the request was issued. > > Note: RFC 1945 and RFC 2068 specify that the client is not allowed > to change the method on the redirected request. However, most > existing user agent implementations treat 302 as if it were a 303 > response, performing a GET on the Location field-value regardless > of the original request method. The status codes 303 and 307 have > been added for servers that wish to make unambiguously clear which > kind of reaction is expected of the client. > > 10.3.4 303 See Other > > The response to the request can be found under a different URI and > SHOULD be retrieved using a GET method on that resource. This method > exists primarily to allow the output of a POST-activated script to > redirect the user agent to a selected resource. The new URI is not a > substitute reference for the originally requested resource. The 303 > response MUST NOT be cached, but the response to the second > (redirected) request might be cacheable. > > The different URI SHOULD be given by the Location field in the > response. Unless the request method was HEAD, the entity of the > response SHOULD contain a short hypertext note with a hyperlink to > the new URI(s). > > Note: Many pre-HTTP/1.1 user agents do not understand the 303 > status. When interoperability with such clients is a concern, the > 302 status code may be used instead, since most user agents react > to a 302 response as described here for 303. > > On Wed, Jan 12, 2011 at 10:44 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 12 Jan 2011, at 19:03, Tony Fleig wrote: >> >>> Oops. >>> >>> My reply escaped before I was finished. >>> >>>>> 1. It is my understanding that many browsers respond to a 302/303 >>>>> response from a POST with a following GET to the address specified in >>>>> the 302/303 Location header rather than repeating the POST with its >>>>> payload as is done in ZnHttpClient. (See >>>>> http://en.wikipedia.org/wiki/HTTP_303) >>>> >>>> I'll have to study/think about that for a while, it depends on what the specs says. It doesn't make much sense for an automated client to do a GET I think. What would you suggest ? >>> >>> RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) says >>> >>> 10.3.4 303 See Other >>> >>> The response to the request can be found under a different URI and >>> SHOULD be retrieved using a GET method on that resource. >>> >>> so I think we should do a GET ;) . >>> >>> Regards, >>> TF >> >> OK, it is in the spec then but only for 303 ? >> >> But suppose you programmatically try to POST something somewhere and the server tells you to do that on another URL, if you then GET that URL, you haven't fullfilled the original goal of posting something somewhere. As a human, you will probably see another form and start over. >> >> Anyway I think it is an edge case (unless you have a real usecase), we could maybe make it an option/setting ? >> >> Sven >> >

Jan. 13, 2011

Re: [Pharo-project] [update 1.2] #12297

by Tudor Girba

Because we could not distinguish it enough when there are many controls on the board. Exactly because color is used so sparingly makes a light blue efficient. Any design will depend on someone's perception, but this does not mean that there cannot be reasons behind it :). Cheers, Doru On 13 Jan 2011, at 13:31, Torsten Bergmann wrote: > Tudor Girba >> I tried to start from zero and add a new variable (e.g., color) only when I >could not distinguish something > > If that is true then why do you use the additional blue for activated > buttons instead of using a gray one: > > lightSelectionColor > ^ Color gray > > in your original theme - you can distinguish buttons already > using the gray-style gradient (see attached example). > > However ... all of this is very specific to a particular persons > view of the world. As you said you've choosen blue since it is > the color of Moose... > > Bye > T. > > > > > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > <screen.png> -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Jan. 13, 2011