- Pharo-dev - lists.pharo.org

Re: [Pharo-project] A contorted way of making things work :)

by Camillo Bruni

On 2012-12-22, at 09:56, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 22 Dec 2012, Fernando Olivero wrote: > >> Well, the assignment within the and: block says it allâ¦ > > Yeah, blame and flame everyone who doesn't write code the way you do... > But before you do that, tell me what's wrong with that assignment. why do I always have the impression you're at extinction when I read an email from you? I know I can be very annoying as well :D but you should consider a friendlier tone ;)

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Igor Stasenko

On 22 December 2012 14:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What I love is the impact of not having cool invariant. > Imagine a world where every morph would have a owner, suddenly the logic of morphic > would be cut by two :) > Well, for some morphs, nil is the only owner which they deserve to have :) > Stef -- Best regards, Igor Stasenko.

Dec. 22, 2012

Re: [Pharo-project] To Quadrangle or not Quadrangle?

by Igor Stasenko

On 22 December 2012 14:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > you mean bounds, inner bounds, inset bounds, outer boundsâ¦ > > :) > yeah.. morph's bounds is a jungle. we should think how to reduce them, because it makes model unbearable: Morph methodDict keys select: [:each | each endsWith: 'Bounds' ] #(#focusBounds #layoutBounds #fullBounds #adjustLayoutBounds #defaultBounds #worldBounds #flashBounds #submorphBounds #clippingBounds #privateFullBounds #outerBounds #preferredKeyboardBounds #innerBounds) -- Best regards, Igor Stasenko.

Dec. 22, 2012

Re: [Pharo-project] A tantalizing path of dealing with multiple concerns...

by StÃ©phane Ducasse

Igor may be having good design could help with little objects having responsibilities and plugging the right ones :) We should create "The club of gentleman against little kitties killing code" and save the kitties by refactoring the killing code :) Stef > areasRemainingToFill: aRectangle > "Pushed up from BorderedMorph, all cases tested for there are > supported by basic Morph." > "Morphs which achieve translucency by other means than fillStyle will have > to reimplement this" > "Fixed here to test the fillStyle rather than color for translucency. > Since can have a translucent fillStyle while the (calculated) color is not." > self fillStyle isTranslucent > ifTrue: [^ Array with: aRectangle]. > self wantsRoundedCorners > ifTrue: [(self borderWidth > 0 > and: [self borderColor isColor > and: [self borderColor isTranslucent]]) > ifTrue: [^ aRectangle > areasOutside: (self innerBounds intersect: self boundsWithinCorners)] > ifFalse: [^ aRectangle areasOutside: self boundsWithinCorners]] > ifFalse: [(self borderWidth > 0 > and: [self borderColor isColor > and: [self borderColor isTranslucent]]) > ifTrue: [^ aRectangle areasOutside: self innerBounds] > ifFalse: [^ aRectangle areasOutside: self bounds]] > > > ... the whole Morphic code fall victim of rounded corners (and borders > , of course). > > I wonder, is there any way to > a) have multiple concerns > b) at same time, have a clean code > ? > But i suspect that smalltalk is not powerful enough for that. :)

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by StÃ©phane Ducasse

What I love is the impact of not having cool invariant. Imagine a world where every morph would have a owner, suddenly the logic of morphic would be cut by two :) Stef On Dec 22, 2012, at 2:57 AM, Igor Stasenko wrote: > StringMorph>>boundsForBalloon > "Some morphs have bounds that are way too big. This is a contorted > way of making things work okay in PluggableListMorphs, whose list > elements historically have huge widths" > > | ownerOwner | > ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) and: > [ownerOwner isKindOf: PluggableListMorph]) > ifTrue: > [self boundsInWorld intersect: ownerOwner boundsInWorld] > ifFalse: > [super boundsForBalloon] > > -- > Best regards, > Igor Stasenko. >

Dec. 22, 2012

Re: [Pharo-project] To Quadrangle or not Quadrangle?

by StÃ©phane Ducasse

you mean bounds, inner bounds, inset bounds, outer boundsâ¦ :) On Dec 22, 2012, at 2:41 AM, Igor Stasenko wrote: > Class comment reads: > > I represent a particular kind of Rectangle that has a border and inside color. > > - 0 users in image, except strange test case in RPackage, and totally > unrelated to actual class. > > Now, lets count how many "bordered" stuff we have: > - Morph borderStyle > which using BorderStyle > - BorderedMorph, which has borderWidth borderColor (and if you > combine it with color inherited from Morph, > you get exactly what Quadrangle has).. > - Canvas protocol , supports #borderXYZ everywhere... > > > it is funny, how much attention this visual property drawn from developers :) > (not mentioning an amazing amount of efforts making rounded corners > (and of course drawing rounded borders there as well)) > > -- > Best regards, > Igor Stasenko. >

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Igor Stasenko

On 22 December 2012 13:56, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 22 Dec 2012, Fernando Olivero wrote: > >> Well, the assignment within the and: block says it allâ¦ > > > Yeah, blame and flame everyone who doesn't write code the way you do... > But before you do that, tell me what's wrong with that assignment. > No need to take it so seriously. I do not know what's wrong with assignment, but taking special action depending on specific class of outer morph smells bad. I'm not saying that i know the right solution to deal with such situation, but apparently it should not be like that. > > Levente > > >> >> Fernando >> >> >> On Sat, Dec 22, 2012 at 2:57 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> StringMorph>>boundsForBalloon >> "Some morphs have bounds that are way too big. This is a >> contorted >> way of making things work okay in PluggableListMorphs, whose list >> elements historically have huge widths" >> >> | ownerOwner | >> ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) >> and: >> [ownerOwner isKindOf: PluggableListMorph]) >> ifTrue: >> [self boundsInWorld intersect: ownerOwner >> boundsInWorld] >> ifFalse: >> [super boundsForBalloon] >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > -- Best regards, Igor Stasenko.

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Levente Uzonyi

On Sat, 22 Dec 2012, Fernando Olivero wrote: > Well, the assignmentÂ within the and: block says it allâ¦ Yeah, blame and flame everyone who doesn't write code the way you do... But before you do that, tell me what's wrong with that assignment. Levente > > Fernando > > > On Sat, Dec 22, 2012 at 2:57 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > StringMorph>>boundsForBalloon > Â Â Â Â "Some morphs have bounds that are way too big. Â This is a contorted > way of making things work okay in PluggableListMorphs, whose list > elements historically have huge widths" > > Â Â Â Â | ownerOwner | > Â Â Â Â ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) and: > Â Â Â Â Â Â Â Â Â Â Â Â [ownerOwner isKindOf: PluggableListMorph]) > Â Â Â Â Â Â Â Â ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [self boundsInWorld intersect: ownerOwner boundsInWorld] > Â Â Â Â Â Â Â Â ifFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [super boundsForBalloon] > > -- > Best regards, > Igor Stasenko. > > > >

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Fernando Olivero

Well, the assignment within the and: block says it allâ¦ Fernando On Sat, Dec 22, 2012 at 2:57 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > StringMorph>>boundsForBalloon > "Some morphs have bounds that are way too big. This is a contorted > way of making things work okay in PluggableListMorphs, whose list > elements historically have huge widths" > > | ownerOwner | > ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) and: > [ownerOwner isKindOf: PluggableListMorph]) > ifTrue: > [self boundsInWorld intersect: ownerOwner > boundsInWorld] > ifFalse: > [super boundsForBalloon] > > -- > Best regards, > Igor Stasenko. > >

Dec. 22, 2012

[Pharo-project] A tantalizing path of dealing with multiple concerns...

by Igor Stasenko

areasRemainingToFill: aRectangle "Pushed up from BorderedMorph, all cases tested for there are supported by basic Morph." "Morphs which achieve translucency by other means than fillStyle will have to reimplement this" "Fixed here to test the fillStyle rather than color for translucency. Since can have a translucent fillStyle while the (calculated) color is not." self fillStyle isTranslucent ifTrue: [^ Array with: aRectangle]. self wantsRoundedCorners ifTrue: [(self borderWidth > 0 and: [self borderColor isColor and: [self borderColor isTranslucent]]) ifTrue: [^ aRectangle areasOutside: (self innerBounds intersect: self boundsWithinCorners)] ifFalse: [^ aRectangle areasOutside: self boundsWithinCorners]] ifFalse: [(self borderWidth > 0 and: [self borderColor isColor and: [self borderColor isTranslucent]]) ifTrue: [^ aRectangle areasOutside: self innerBounds] ifFalse: [^ aRectangle areasOutside: self bounds]] ... the whole Morphic code fall victim of rounded corners (and borders , of course). I wonder, is there any way to a) have multiple concerns b) at same time, have a clean code ? But i suspect that smalltalk is not powerful enough for that. :) -- Best regards, Igor Stasenko.

Dec. 22, 2012