March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] 10252

by Gary Chambers

A lot more could be done with Rome, though only then availbale for platforms with Cario... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 3:22 PM Subject: Re: [Pharo-project] [ANN] 10252 a question: would it help to have rome canvas? because I would really like to curve it out of sophie for 1.1 stef On Mar 14, 2009, at 2:59 PM, Gary Chambers wrote: > Sadly BitBlt and/or Balloon don't support much so we're stuck with > GradientFills and rectangles for shapes (where the double-dispatched > "puting > the behaviour in the fill style" is concerned, unless the low-level > shape > drawing types are all dispatched)... > > As for the original question, BoundedGradientFillStyle simply allows > for an > extent so that, as part of a composite, it can be limited to only > part of > the drawing area. This makes it possible to make composites that have > different corner images (for example) along with gradients for the > "stretchy > bits" in between... > > In respect of the isXXX methods, these could be refactored properly > such > that the morph informs its fillStyle of bounds changes. For simple > colours > this would be effecitvely a no-op, gardients would adjust their > origin etc. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, March 14, 2009 9:13 AM > Subject: Re: [Pharo-project] [ANN] 10252 > > >> 2009/3/14 Igor Stasenko <siguctua(a)gmail.com>: >>> 2009/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I will let gary reply and rollback if necessary. or even better >>>> integrate next fixes :) >>>> I thought it was ready for integration. >>>> >>> I didn't said its not ready.. >>> I just wanted to point out, that it is half-done, in the way how i >>> see >>> it should be done. >>> It works, of course, but not so elegant as it should be :) >>> >>>> stef >>>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote: >>>> >>>>> 2009/3/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> Added BoundedGradientFillStyle. >>>>> >>>>> can to elaborate , what is it? :) >>>>> >>>>> We duscussed the fill styles with Gary a while ago, and the >>>>> result of >>>>> a discussion is to make fill styles to know what they need to do >>>>> to >>>>> fill the given shape i.e. fill style could be seen as a function: >>>>> f(shape, canvas) >>>>> >> >> going further with that, all drawings (not only fills) on canvas >> could >> be represented by such function >> f(shape, canvas) >> but it would require a deep refactorings in bitblt/morphic engine to >> do such unification. >> >> With such approach, it would be easy to introduce a new fill styles, >> such as bevel/emboss, blur , etc. >> While old fillstyles implementation is quite limited, because >> fillstyle used as a dumb state holder and drawing engine performs >> different tests (isXXXX) to do the right thing. >> >>>>> and, to use a fill style, in general form, you simply should use: >>>>> myfillStyle fill: someShape on: canvas. >>>>> >>>>> This concept were introduced into Polymorph, and as first proof >>>>> of it, >>>>> Gary implemented a composite fill styles. >>>>> But it's far from complete. In ideal, i'd like to get rid of many >>>>> 'isXXXFill', like #isGradientFill and others and remove any code >>>>> which >>>>> relying on fill style properties - instead it should always >>>>> delegate >>>>> the responsibility from filling a shape to a fill style object. >>>>> >>>>> This approach , also opens a new questions: >>>>> - how do we treat a morph. Should morph define own shape? Or >>>>> shape is >>>>> something that should be determined procedurally, and morph could >>>>> contain/use as many shapes as it wants to for representing >>>>> itself on >>>>> canvas? >>>>> I am far from thinking that morph's shape is rectangular (but >>>>> there >>>>> are many aspects in morphic, assuming it is rectangular - such as >>>>> #fullBounds or #bounds), as well as i don't think that making >>>>> morph >>>>> === shape is a good choice. >>>>> >>>>>> Standard Squeak uses original menu pin form. >>>>>> Tweaked appearance of drop lists for Watery 2 as an interim >>>>>> measure. >>>>>> Fixed positioning of drop list pop-up-list to deal with >>>>>> transforms >>>>>> (no >>>>>> rotation though ;-) ) (thanks Alain) >>>>>> >>>>>> Removed "revert" option in patch browser for MC 1.0 >>>>>> compatability. >>>>>> Handle missing remote definition when selecting next conflict. >>>>>> >>>>>> Stef >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> 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

March 14, 2009

Re: [Pharo-project] [ANN] 10252

by StÃ©phane Ducasse

a question: would it help to have rome canvas? because I would really like to curve it out of sophie for 1.1 stef On Mar 14, 2009, at 2:59 PM, Gary Chambers wrote: > Sadly BitBlt and/or Balloon don't support much so we're stuck with > GradientFills and rectangles for shapes (where the double-dispatched > "puting > the behaviour in the fill style" is concerned, unless the low-level > shape > drawing types are all dispatched)... > > As for the original question, BoundedGradientFillStyle simply allows > for an > extent so that, as part of a composite, it can be limited to only > part of > the drawing area. This makes it possible to make composites that have > different corner images (for example) along with gradients for the > "stretchy > bits" in between... > > In respect of the isXXX methods, these could be refactored properly > such > that the morph informs its fillStyle of bounds changes. For simple > colours > this would be effecitvely a no-op, gardients would adjust their > origin etc. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, March 14, 2009 9:13 AM > Subject: Re: [Pharo-project] [ANN] 10252 > > >> 2009/3/14 Igor Stasenko <siguctua(a)gmail.com>: >>> 2009/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I will let gary reply and rollback if necessary. or even better >>>> integrate next fixes :) >>>> I thought it was ready for integration. >>>> >>> I didn't said its not ready.. >>> I just wanted to point out, that it is half-done, in the way how i >>> see >>> it should be done. >>> It works, of course, but not so elegant as it should be :) >>> >>>> stef >>>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote: >>>> >>>>> 2009/3/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> Added BoundedGradientFillStyle. >>>>> >>>>> can to elaborate , what is it? :) >>>>> >>>>> We duscussed the fill styles with Gary a while ago, and the >>>>> result of >>>>> a discussion is to make fill styles to know what they need to do >>>>> to >>>>> fill the given shape i.e. fill style could be seen as a function: >>>>> f(shape, canvas) >>>>> >> >> going further with that, all drawings (not only fills) on canvas >> could >> be represented by such function >> f(shape, canvas) >> but it would require a deep refactorings in bitblt/morphic engine to >> do such unification. >> >> With such approach, it would be easy to introduce a new fill styles, >> such as bevel/emboss, blur , etc. >> While old fillstyles implementation is quite limited, because >> fillstyle used as a dumb state holder and drawing engine performs >> different tests (isXXXX) to do the right thing. >> >>>>> and, to use a fill style, in general form, you simply should use: >>>>> myfillStyle fill: someShape on: canvas. >>>>> >>>>> This concept were introduced into Polymorph, and as first proof >>>>> of it, >>>>> Gary implemented a composite fill styles. >>>>> But it's far from complete. In ideal, i'd like to get rid of many >>>>> 'isXXXFill', like #isGradientFill and others and remove any code >>>>> which >>>>> relying on fill style properties - instead it should always >>>>> delegate >>>>> the responsibility from filling a shape to a fill style object. >>>>> >>>>> This approach , also opens a new questions: >>>>> - how do we treat a morph. Should morph define own shape? Or >>>>> shape is >>>>> something that should be determined procedurally, and morph could >>>>> contain/use as many shapes as it wants to for representing >>>>> itself on >>>>> canvas? >>>>> I am far from thinking that morph's shape is rectangular (but >>>>> there >>>>> are many aspects in morphic, assuming it is rectangular - such as >>>>> #fullBounds or #bounds), as well as i don't think that making >>>>> morph >>>>> === shape is a good choice. >>>>> >>>>>> Standard Squeak uses original menu pin form. >>>>>> Tweaked appearance of drop lists for Watery 2 as an interim >>>>>> measure. >>>>>> Fixed positioning of drop list pop-up-list to deal with >>>>>> transforms >>>>>> (no >>>>>> rotation though ;-) ) (thanks Alain) >>>>>> >>>>>> Removed "revert" option in patch browser for MC 1.0 >>>>>> compatability. >>>>>> Handle missing remote definition when selecting next conflict. >>>>>> >>>>>> Stef >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> 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 >

March 14, 2009

Re: [Pharo-project] Setting package test

by Gary Chambers

----- Original Message ----- From: "Adrian Lienhard" <adi(a)netstyle.ch> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 12:48 PM Subject: Re: [Pharo-project] Setting package test > Hi Alain, > > Nice to see you making progress! > > I've taken a quick look at the GUI and the code. Here some feedback: > > - When I change a value, why do I get a red border (for me this > indicates that the change is invalid)? The red border is what eveyone apparently still wanted for an "edited" text field (until "accepted"). If you don't like that there is a preference (old-style) showTextEditingState. > - Set to default doesn't do anything > - Dropdown lists are displayed at the wrong position on the screen > (I'm using the default theme, Watery2) > - At first I didn't recognize the slider control (glyph contrast > setting) > > - Instead of using the old change notification mechanism, you could > use Announcements > - The method #domainValues: looks a bit fishy with the isKindOf: checks > - The method #maxNameWidthForFont: can be simplified by using > #detectMax: > > A search/filter would certainly be useful. > > Cheers, > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > On Mar 14, 2009, at 01:38 , Alain Plantec wrote: > >> Hi all, >> Preference is now renamed as Setting. >> Please, can you can load these two packages and play with the >> settings. >> 'SettingTree open' open the browser. >> Examples of setting are located in the Setting-SandBox category. >> You can use <pharo> or <setting> as pragma. >> the pragma list the browser is able to recognize is now a parameter. >> (see SettingCollector class side). >> as an example, It will be possible for an application to use its own >> pragma symbol. Thus, the browser will be able to show application >> specific >> settings. >> I will add 'saving', 'saving as', choose, open, and 'filtering' >> features (by package or by setting name as available in current >> preference browser). >> If you have more ideas or needs, please let me know. >> >> Cheers >> alain >> >> <Setting-alain_plantec.1.mcz><SettingSupport-alain_plantec. >> 1.mcz><Setting >> tree.gif>_______________________________________________ >> 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

March 14, 2009

Re: [Pharo-project] [ANN] 10252

by Gary Chambers

Sadly BitBlt and/or Balloon don't support much so we're stuck with GradientFills and rectangles for shapes (where the double-dispatched "puting the behaviour in the fill style" is concerned, unless the low-level shape drawing types are all dispatched)... As for the original question, BoundedGradientFillStyle simply allows for an extent so that, as part of a composite, it can be limited to only part of the drawing area. This makes it possible to make composites that have different corner images (for example) along with gradients for the "stretchy bits" in between... In respect of the isXXX methods, these could be refactored properly such that the morph informs its fillStyle of bounds changes. For simple colours this would be effecitvely a no-op, gardients would adjust their origin etc. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 9:13 AM Subject: Re: [Pharo-project] [ANN] 10252 > 2009/3/14 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> I will let gary reply and rollback if necessary. or even better >>> integrate next fixes :) >>> I thought it was ready for integration. >>> >> I didn't said its not ready.. >> I just wanted to point out, that it is half-done, in the way how i see >> it should be done. >> It works, of course, but not so elegant as it should be :) >> >>> stef >>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote: >>> >>>> 2009/3/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> Added BoundedGradientFillStyle. >>>> >>>> can to elaborate , what is it? :) >>>> >>>> We duscussed the fill styles with Gary a while ago, and the result of >>>> a discussion is to make fill styles to know what they need to do to >>>> fill the given shape i.e. fill style could be seen as a function: >>>> f(shape, canvas) >>>> > > going further with that, all drawings (not only fills) on canvas could > be represented by such function > f(shape, canvas) > but it would require a deep refactorings in bitblt/morphic engine to > do such unification. > > With such approach, it would be easy to introduce a new fill styles, > such as bevel/emboss, blur , etc. > While old fillstyles implementation is quite limited, because > fillstyle used as a dumb state holder and drawing engine performs > different tests (isXXXX) to do the right thing. > >>>> and, to use a fill style, in general form, you simply should use: >>>> myfillStyle fill: someShape on: canvas. >>>> >>>> This concept were introduced into Polymorph, and as first proof of it, >>>> Gary implemented a composite fill styles. >>>> But it's far from complete. In ideal, i'd like to get rid of many >>>> 'isXXXFill', like #isGradientFill and others and remove any code which >>>> relying on fill style properties - instead it should always delegate >>>> the responsibility from filling a shape to a fill style object. >>>> >>>> This approach , also opens a new questions: >>>> - how do we treat a morph. Should morph define own shape? Or shape is >>>> something that should be determined procedurally, and morph could >>>> contain/use as many shapes as it wants to for representing itself on >>>> canvas? >>>> I am far from thinking that morph's shape is rectangular (but there >>>> are many aspects in morphic, assuming it is rectangular - such as >>>> #fullBounds or #bounds), as well as i don't think that making morph >>>> === shape is a good choice. >>>> >>>>> Standard Squeak uses original menu pin form. >>>>> Tweaked appearance of drop lists for Watery 2 as an interim measure. >>>>> Fixed positioning of drop list pop-up-list to deal with transforms >>>>> (no >>>>> rotation though ;-) ) (thanks Alain) >>>>> >>>>> Removed "revert" option in patch browser for MC 1.0 compatability. >>>>> Handle missing remote definition when selecting next conflict. >>>>> >>>>> Stef >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > 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

March 14, 2009

Re: [Pharo-project] Setting package test

by Adrian Lienhard

Hi Alain, Nice to see you making progress! I've taken a quick look at the GUI and the code. Here some feedback: - When I change a value, why do I get a red border (for me this indicates that the change is invalid)? - Set to default doesn't do anything - Dropdown lists are displayed at the wrong position on the screen (I'm using the default theme, Watery2) - At first I didn't recognize the slider control (glyph contrast setting) - Instead of using the old change notification mechanism, you could use Announcements - The method #domainValues: looks a bit fishy with the isKindOf: checks - The method #maxNameWidthForFont: can be simplified by using #detectMax: A search/filter would certainly be useful. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/ On Mar 14, 2009, at 01:38 , Alain Plantec wrote: > Hi all, > Preference is now renamed as Setting. > Please, can you can load these two packages and play with the > settings. > 'SettingTree open' open the browser. > Examples of setting are located in the Setting-SandBox category. > You can use <pharo> or <setting> as pragma. > the pragma list the browser is able to recognize is now a parameter. > (see SettingCollector class side). > as an example, It will be possible for an application to use its own > pragma symbol. Thus, the browser will be able to show application > specific > settings. > I will add 'saving', 'saving as', choose, open, and 'filtering' > features (by package or by setting name as available in current > preference browser). > If you have more ideas or needs, please let me know. > > Cheers > alain > > <Setting-alain_plantec.1.mcz><SettingSupport-alain_plantec. > 1.mcz><Setting > tree.gif>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 14, 2009

Re: [Pharo-project] [ANN] 10252

by Igor Stasenko

2009/3/14 Igor Stasenko <siguctua(a)gmail.com>: > 2009/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I will let gary reply and rollback if necessary. or even better >> integrate next fixes :) >> I thought it was ready for integration. >> > I didn't said its not ready.. > I just wanted to point out, that it is half-done, in the way how i see > it should be done. > It works, of course, but not so elegant as it should be :) > >> stef >> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote: >> >>> 2009/3/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Added BoundedGradientFillStyle. >>> >>> can to elaborate , what is it? :) >>> >>> We duscussed the fill styles with Gary a while ago, and the result of >>> a discussion is to make fill styles to know what they need to do to >>> fill the given shape i.e. fill style could be seen as a function: >>> f(shape, canvas) >>> going further with that, all drawings (not only fills) on canvas could be represented by such function f(shape, canvas) but it would require a deep refactorings in bitblt/morphic engine to do such unification. With such approach, it would be easy to introduce a new fill styles, such as bevel/emboss, blur , etc. While old fillstyles implementation is quite limited, because fillstyle used as a dumb state holder and drawing engine performs different tests (isXXXX) to do the right thing. >>> and, to use a fill style, in general form, you simply should use: >>> myfillStyle fill: someShape on: canvas. >>> >>> This concept were introduced into Polymorph, and as first proof of it, >>> Gary implemented a composite fill styles. >>> But it's far from complete. In ideal, i'd like to get rid of many >>> 'isXXXFill', like #isGradientFill and others and remove any code which >>> relying on fill style properties - instead it should always delegate >>> the responsibility from filling a shape to a fill style object. >>> >>> This approach , also opens a new questions: >>> - how do we treat a morph. Should morph define own shape? Or shape is >>> something that should be determined procedurally, and morph could >>> contain/use as many shapes as it wants to for representing itself on >>> canvas? >>> I am far from thinking that morph's shape is rectangular (but there >>> are many aspects in morphic, assuming it is rectangular - such as >>> #fullBounds or #bounds), as well as i don't think that making morph >>> === shape is a good choice. >>> >>>> Standard Squeak uses original menu pin form. >>>> Tweaked appearance of drop lists for Watery 2 as an interim measure. >>>> Fixed positioning of drop list pop-up-list to deal with transforms >>>> (no >>>> rotation though ;-) ) (thanks Alain) >>>> >>>> Removed "revert" option in patch browser for MC 1.0 compatability. >>>> Handle missing remote definition when selecting next conflict. >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

March 14, 2009

Re: [Pharo-project] [ANN] 10252

by Igor Stasenko

2009/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I will let gary reply and rollback if necessary. or even better > integrate next fixes :) > I thought it was ready for integration. > I didn't said its not ready.. I just wanted to point out, that it is half-done, in the way how i see it should be done. It works, of course, but not so elegant as it should be :) > stef > On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote: > >> 2009/3/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Added BoundedGradientFillStyle. >> >> can to elaborate , what is it? :) >> >> We duscussed the fill styles with Gary a while ago, and the result of >> a discussion is to make fill styles to know what they need to do to >> fill the given shape i.e. fill style could be seen as a function: >> f(shape, canvas) >> >> and, to use a fill style, in general form, you simply should use: >> myfillStyle fill: someShape on: canvas. >> >> This concept were introduced into Polymorph, and as first proof of it, >> Gary implemented a composite fill styles. >> But it's far from complete. In ideal, i'd like to get rid of many >> 'isXXXFill', like #isGradientFill and others and remove any code which >> relying on fill style properties - instead it should always delegate >> the responsibility from filling a shape to a fill style object. >> >> This approach , also opens a new questions: >> - how do we treat a morph. Should morph define own shape? Or shape is >> something that should be determined procedurally, and morph could >> contain/use as many shapes as it wants to for representing itself on >> canvas? >> I am far from thinking that morph's shape is rectangular (but there >> are many aspects in morphic, assuming it is rectangular - such as >> #fullBounds or #bounds), as well as i don't think that making morph >> === shape is a good choice. >> >>> Standard Squeak uses original menu pin form. >>> Tweaked appearance of drop lists for Watery 2 as an interim measure. >>> Fixed positioning of drop list pop-up-list to deal with transforms >>> (no >>> rotation though ;-) ) (thanks Alain) >>> >>> Removed "revert" option in patch browser for MC 1.0 compatability. >>> Handle missing remote definition when selecting next conflict. >>> >>> Stef >>> >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig.

March 14, 2009

Re: [Pharo-project] Setting package test

by StÃ©phane Ducasse

sound good. I really like the idiom to have a class var on a package this is really a nice way to let the dev think that a preference is not a system global variable (aka old preference) but a local to the package references. This way we will be able to slowly arrive to have preference as a top layer :) Stef On Mar 14, 2009, at 1:38 AM, Alain Plantec wrote: > Hi all, > Preference is now renamed as Setting. > Please, can you can load these two packages and play with the > settings. > 'SettingTree open' open the browser. > Examples of setting are located in the Setting-SandBox category. > You can use <pharo> or <setting> as pragma. > the pragma list the browser is able to recognize is now a parameter. > (see SettingCollector class side). > as an example, It will be possible for an application to use its own > pragma symbol. Thus, the browser will be able to show application > specific > settings. > I will add 'saving', 'saving as', choose, open, and 'filtering' > features (by package or by setting name as available in current > preference browser). > If you have more ideas or needs, please let me know. > > Cheers > alain > > <Setting-alain_plantec.1.mcz><SettingSupport-alain_plantec. > 1.mcz><Setting > tree.gif>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 14, 2009

Re: [Pharo-project] [ANN] 10252

by StÃ©phane Ducasse

I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration. stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote: > 2009/3/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Added BoundedGradientFillStyle. > > can to elaborate , what is it? :) > > We duscussed the fill styles with Gary a while ago, and the result of > a discussion is to make fill styles to know what they need to do to > fill the given shape i.e. fill style could be seen as a function: > f(shape, canvas) > > and, to use a fill style, in general form, you simply should use: > myfillStyle fill: someShape on: canvas. > > This concept were introduced into Polymorph, and as first proof of it, > Gary implemented a composite fill styles. > But it's far from complete. In ideal, i'd like to get rid of many > 'isXXXFill', like #isGradientFill and others and remove any code which > relying on fill style properties - instead it should always delegate > the responsibility from filling a shape to a fill style object. > > This approach , also opens a new questions: > - how do we treat a morph. Should morph define own shape? Or shape is > something that should be determined procedurally, and morph could > contain/use as many shapes as it wants to for representing itself on > canvas? > I am far from thinking that morph's shape is rectangular (but there > are many aspects in morphic, assuming it is rectangular - such as > #fullBounds or #bounds), as well as i don't think that making morph > === shape is a good choice. > >> Standard Squeak uses original menu pin form. >> Tweaked appearance of drop lists for Watery 2 as an interim measure. >> Fixed positioning of drop list pop-up-list to deal with transforms >> (no >> rotation though ;-) ) (thanks Alain) >> >> Removed "revert" option in patch browser for MC 1.0 compatability. >> Handle missing remote definition when selecting next conflict. >> >> Stef >> >> _______________________________________________ >> 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 >

March 14, 2009

Re: [Pharo-project] Setting package test

by David Mitchell

I know the Mac, Windows, and even OS/2 style prefers ellipses to indicate that command button will not immediately perform an action but will instead open a dialog box. That is, prefer Fonts... to Dialog for Fonts On Fri, Mar 13, 2009 at 7:38 PM, Alain Plantec <alain.plantec(a)free.fr> wrote: > Hi all, > Preference is now renamed as Setting. > Please, can you can load these two packages and play with the settings. > 'SettingTree open' open Â the browser. > Examples of setting are located in the Setting-SandBox category. > You can use <pharo> or <setting> as pragma. > the pragma list the browser is able to recognize is now a parameter. > (see SettingCollector class side). > as an example, It will be possible for an application to use its own > pragma symbol. Thus, the browser will be able to show application specific > settings. > I will add 'saving', 'saving as', choose, open, Â and 'filtering' features > (by package or by setting name as available in current preference browser). > If you have more ideas or needs, please let me know. > > Cheers > alain > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 14, 2009