June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

by StÃ©phane Ducasse

Now what would be good is that as a community we identify key points and put money on the table. I'm sure that we can get some nice and smart south american programmers and esug can help. But this would make sense to do it as a community effort. May be we should do a call. Stef On Jun 30, 2010, at 10:36 PM, Adrian Lienhard wrote: > Taking about more future oriented stuff, I think it would be nice to have good support for document DBs (like CouchDB and MongoDB) and key/value stores (like Redis). At least for the former category of DBs, I know that a few people have been working on DB clients (see squeaksource.com) but I don't know how complete and stable they are. > > Adrian > > On Jun 30, 2010, at 20:53 , StÃ©phane Ducasse wrote: > >> Philippe this is good that you reacted. The point of esug is to support actions >> that will help people so probably XML-RCP is not a really good choice. >> Now what would be good is to have a map of current techno and their support >> for smalltalk. Then act to fill up the gaps. >> >> Stef >> >>> >>> It doesn't strike me as a forward looking investment. IMHO XML-RCP is >>> something that will only get used less in the future, not more. The >>> value you get from an XML-RCP implementation will become less and less >>> as fewer services support it. >>> >>> But then again ESUG is free to spend their money on what they seem fit. >>> If they disagree or decide the current use is big enough, I have no >>> problem at all with this. >>> >>> Cheers >>> Philippe >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2

by StÃ©phane Ducasse

thanks! On Jun 30, 2010, at 10:55 PM, Denis Kudriashov wrote: > I found that when color selector tools opened for both gradient colors > they not change same GradientStyle instance. > They just copy origin style with new color (first or last). Its not siutable for user. > > > I add another fix > > 2010/6/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cool! > > Stef > > On Jun 27, 2010, at 11:19 PM, Denis Kudriashov wrote: > > > I done slice for this. See http://code.google.com/p/pharo/issues/detail?id=2595 > > > > 2010/6/27 Denis Kudriashov <dionisiydk(a)gmail.com> > > I can't see full morph appearance. I just see what color I select. > > But It's nothing because I need see my little changes in full morph appearance. > > > > For example color of button should satisfy color of pane. And when I change button color I want immediately see full picture of my application view. > > > > I think It is very important for UI design. > > > > 2010/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > I do not understand because you can see the selected color in the selected color little pane. > > Is it not what you need? > > Stef] > > On Jun 27, 2010, at 11:53 AM, Denis Kudriashov wrote: > > > > > I try last Pharo 1.1 rc2 10.06.10. > > > > > > I found that tool for changing color by user is changed. ColorPickerMorph is removed. Now I can't dynamically change color by mouse and see my changes immediately. Now I must select color in new tool, press ok button. And after that tool close and I must open it again if I dont like my changes. > > > > > > It is bad behavior compare with pharo 1.0/squeak. But I really like new color picker morph. > > > > > > New tool is ColorSelectorDialogWindow. > > > How I can hookup It for tracking color selection? > > > Maybe I must add some event triggering in #basicSelectedColor: method. > > > But I see many #changed: sends in #basicSelectedColor: method. And maybe I already can implement some dependent class for needed stuff. > > > > > > What you think? > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] Setting new world in 1.1

by StÃ©phane Ducasse

You cannot anymore. Projects are not supported features. We got discussions in the mailing-list about that some times ago. Stef On Jun 30, 2010, at 10:27 PM, Denis Kudriashov wrote: > How I can install new World in Pharo 1.1? > > In pharo 1.0 I do : > > newWorld beWorldForProject: nil. > > But #beWorldForProject: absent in 1.1 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

Re: [Pharo-project] Strange behavior (bug) of wrapping text with TTFont (russian text) in TextMorph

by Denis Kudriashov

Hello, Nicolas. Multilingual additions do also consider a change of leadingChar as a > special case of endOfRun because current font must be changed too. > Also, presumably it did not hurt to split text here because a change > of leadingChar corresponds to a change of language. > LeadingChar is abount string encoding. Font is about string displaying. Why leadingChar changing should raise font changes? I can have string with russian and english chars and they all displayed by Arial font for example. I really not understand meaning of code that I comment. For english text its condition never executed. And for non english text I think its should be truth too. Why It not should be truth for text with english and non english chars? Would it be possible to change russian environment to use Unicode with > a good font support? > What you mean? I just want my application work with russian label, texts with regular TrueType fonts. Now I use DejaVu Regular font 30 Ð¸ÑÐ½Ñ 2010 Ð³. 23:35 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > Hi Denis, > My understanding of endOfRun is that the end of a run has been reached. > An end of run mark a change of emphasis (think of Text string:runs:) > or the end of the text to be rendered. > > stops endOfRun always return #endOfRun (the method to be executed when > an endOfRun condition occurs is programmable, but a single usage is > done across the image). > > You'll see that most CharacterScanner & subclasses will send a > #setStopConditions, that will send a #setFont. > That is the main purpose, when a change of emphasis (like bold or > italic) occurs, font must be changed. > > The code is like this for ages (already in st80 ASCII times). > > Multilingual additions do also consider a change of leadingChar as a > special case of endOfRun because current font must be changed too. > Also, presumably it did not hurt to split text here because a change > of leadingChar corresponds to a change of language. > I don't think we changed this behaviour. > We just used a message ^(stops endOfRun) instead of (stops at: > EndOfRun), because previous implementation (along with CrossedX) did > consume two character slots (256 257) which are valid Unicode (they > were previously unused in ASCII times and previous Multilingual > implementation because unicode leadingChar was 255). > > However, what changed is that less endOfRun are detected than before > because Unicode leadingChar is now zero... > > I unfortunately don't eat my own dog food because I'm a native latin > speaker, so maybe I just should stop touching the Multilingual code... > But my understanding is that code needed (and still need!) to be cleaned > up... > ... and also that leadingChar is not really usefull for rendering > Russian now that there are more and more fonts with good Unicode > support... > Would it be possible to change russian environment to use Unicode with > a good font support? > > Nicolas > > 2010/6/30 Denis Kudriashov <dionisiydk(a)gmail.com>: > > I found solution. > > > > I comment line of code in scanning loop in > > MultiCharacterScanner>>scanMultiCharactersFrom: startIndex to: stopIndex > in: > > sourceString rightX: rightX stopConditions: stops kern: kernDelta > > > > ... > > "encoding ~= startEncoding ifTrue: [lastIndex := lastIndex - 1. ^ > > stops endOfRun]." > > ... > > > > Without this commenting scanning process not register breakage at space > when > > scanning russian text. (because encoding is differ from startEncoding. > > Encoding for space is 0 but for startEncoding is leadingChar of not ascii > > russian text). > > > > I dont now meaning of this code line. But now I have correct wrapping > > behavior. > > > > I know that multilingual package have many newly versions. All containes > > that strange code line. > > > > I open Issue http://code.google.com/p/pharo/issues/detail?id=2608 > > > > 30 Ð¸ÑÐ½Ñ 2010 Ð³. 9:55:37 UTC+4 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ dionisiydk < > dionisiydk(a)gmail.com> > > Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > >> > >> No. #isSeparator message not used for wrapping. Wrapping logic > implemented > >> in MultiCompositionScanner and dont use #isSeparator > >> > >> 2010/6/30 Igor Stasenko <siguctua(a)gmail.com> > >>> > >>> 2010/6/30 Denis Kudriashov <dionisiydk(a)gmail.com>: > >>> > I use Pharo 1.1 rc2 10.06 > >>> > > >>> > I found strange behavior of wrapping text with TTFont (russian text) > in > >>> > TextMorph. > >>> > > >>> > I dont know how to reproduce it. But I see it in my application. > >>> > > >>> > I have prototype button with TextMorph as it label. And I do many of: > >>> > > >>> > aPanel add: prototype veryDeepCopy contentsWrapped: someRussianText. > >>> > > >>> > And I see that text on label dont wrapped by words. It is wrapped > only > >>> > by > >>> > label bounds. And words in text became break. > >>> > Example. I expect > >>> > > >>> i think it wraps text based on #isSeparator test. > >>> And any russian (as well as any other non-ascii characters), afaik is > >>> treated as separators. > >>> That's why it wraps on any letter. > >>> > >>> > "one two > >>> > three" > >>> > > >>> > But I see > >>> > > >>> > "one two th > >>> > ree > >>> > " > >>> > > >>> > Its work correct for english text. But for russian not. > >>> > > >>> > And I cant reproduce it by execution code separetelly from my > >>> > application > >>> > (aPanel add: prototype veryDeepCopy contentsWrapped: > someRussianText). > >>> > > >>> > I try many experiments with debuger and inspector. But I cant fix > that. > >>> > Wrapping text code is not simple. > >>> > Maybe somebody tell me what place I need learn/inspect for fixing > this > >>> > bug? > >>> > > >>> > And I found that If I insert char by keyboard at the end of word > "two" > >>> > (see > >>> > example) text wrapped correctly: > >>> > "one twoNEW > >>> > three > >>> > " > >>> > > >>> > And this behavior correct in Pharo 1.0. > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Pharo-project mailing list > >>> > Pharo-project(a)lists.gforge.inria.fr > >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > > >>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko AKA sig. > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

[Pharo-project] [update 1.2] #12025

by StÃ©phane Ducasse

12025 ----- - Issue 2599: better extract parameter - Issue 2604: a script as argument squeak mysqueak.image file.st squeak mysqueak.image scripts/file.st squeak mysqueak.image ../../svn/scripts/file.st Stef and Hilaire happily hacking to relax :)

June 30, 2010

Re: [Pharo-project] CLFramework and Pharo

by nullPointer

My knowledge is limited, but XML seems more portable than code Smalltalk. Exists external editor (UI Builders too) for generate code XAML. Then that code could be "file in" used in a image of Pharo-Smalltalk where a class could parse it and build the UI. The idea is use external tools like that... http://www.youtube.com/watch?v=kyrN_Ky3HWc&feature=PlayList&p=0DD1BED3F232B… Is a very sample tool, but exists anothers much more complete. Why re-create a new ui builder when exists another external always best? I need only the code for rebuild the UI, not all ui builder tool. I donÂ´t know nothing of Seaside, but I understand than the mechanism for build the UI will be the same. The same XAML code could build a equivalent UI, but in that case for HTML explorer. Well, only is a idea, surely stupid XD PS- My name is Gerard, without last vowel. -- View this message in context: http://forum.world.st/CLFramework-and-Pharo-tp2273256p2274245.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 30, 2010

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

by GermÃ¡n Arduino

Hi: Myself was playing a bit with Cassandra (also developing a rudimentary console). As Smalltalk is already included in Thrift, is not so hard to access and use a Cassandra store. Anyway I personally largely prefer the objects databases :) But indeed these sort of DBs (as Cassandra) are being more and more populars, I think that this is mainly for its HA features. Cheers. GermÃ¡n. 2010/6/30 Adrian Lienhard <adi(a)netstyle.ch>: > Taking about more future oriented stuff, I think it would be nice to have good support for document DBs (like CouchDB and MongoDB) and key/value stores (like Redis). At least for the former category of DBs, I know that a few people have been working on DB clients (see squeaksource.com) but I don't know how complete and stable they are. > > Adrian > > On Jun 30, 2010, at 20:53 , StÃ©phane Ducasse wrote: > >> Philippe this is good that you reacted. The point of esug is to support actions >> that will help people so probably XML-RCP is not a really good choice. >> Now what would be good is to have a map of current techno and their support >> for smalltalk. Then act to fill up the gaps. >> >> Stef >> >>> >>> It doesn't strike me as a forward looking investment. IMHO XML-RCP is >>> something that will only get used less in the future, not more. The >>> value you get from an XML-RCP implementation will become less and less >>> as fewer services support it. >>> >>> But then again ESUG is free to spend their money on what they seem fit. >>> If they disagree or decide the current use is big enough, I have no >>> problem at all with this. >>> >>> Cheers >>> Philippe >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

Re: [Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2

by Denis Kudriashov

I found that when color selector tools opened for both gradient colors they not change same GradientStyle instance. They just copy origin style with new color (first or last). Its not siutable for user. I add another fix 2010/6/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cool! > > Stef > > On Jun 27, 2010, at 11:19 PM, Denis Kudriashov wrote: > > > I done slice for this. See > http://code.google.com/p/pharo/issues/detail?id=2595 > > > > 2010/6/27 Denis Kudriashov <dionisiydk(a)gmail.com> > > I can't see full morph appearance. I just see what color I select. > > But It's nothing because I need see my little changes in full morph > appearance. > > > > For example color of button should satisfy color of pane. And when I > change button color I want immediately see full picture of my application > view. > > > > I think It is very important for UI design. > > > > 2010/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > I do not understand because you can see the selected color in the > selected color little pane. > > Is it not what you need? > > Stef] > > On Jun 27, 2010, at 11:53 AM, Denis Kudriashov wrote: > > > > > I try last Pharo 1.1 rc2 10.06.10. > > > > > > I found that tool for changing color by user is changed. > ColorPickerMorph is removed. Now I can't dynamically change color by mouse > and see my changes immediately. Now I must select color in new tool, press > ok button. And after that tool close and I must open it again if I dont like > my changes. > > > > > > It is bad behavior compare with pharo 1.0/squeak. But I really like new > color picker morph. > > > > > > New tool is ColorSelectorDialogWindow. > > > How I can hookup It for tracking color selection? > > > Maybe I must add some event triggering in #basicSelectedColor: method. > > > But I see many #changed: sends in #basicSelectedColor: method. And > maybe I already can implement some dependent class for needed stuff. > > > > > > What you think? > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 30, 2010

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

by Adrian Lienhard

Taking about more future oriented stuff, I think it would be nice to have good support for document DBs (like CouchDB and MongoDB) and key/value stores (like Redis). At least for the former category of DBs, I know that a few people have been working on DB clients (see squeaksource.com) but I don't know how complete and stable they are. Adrian On Jun 30, 2010, at 20:53 , StÃ©phane Ducasse wrote: > Philippe this is good that you reacted. The point of esug is to support actions > that will help people so probably XML-RCP is not a really good choice. > Now what would be good is to have a map of current techno and their support > for smalltalk. Then act to fill up the gaps. > > Stef > >> >> It doesn't strike me as a forward looking investment. IMHO XML-RCP is >> something that will only get used less in the future, not more. The >> value you get from an XML-RCP implementation will become less and less >> as fewer services support it. >> >> But then again ESUG is free to spend their money on what they seem fit. >> If they disagree or decide the current use is big enough, I have no >> problem at all with this. >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2010

[Pharo-project] Setting new world in 1.1

by Denis Kudriashov

How I can install new World in Pharo 1.1? In pharo 1.0 I do : newWorld beWorldForProject: nil. But #beWorldForProject: absent in 1.1

June 30, 2010