May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about theme and friends

by Alexandre Bergel

Talking about theme, I just want to say that I like the Glamour theme very much. Alexandre On May 14, 2013, at 3:59 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I was rather thinking of having the theme be a composable factory: > - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory. > - the UITheme simply stores all these factories, and the morph looks the factory up via the theme. > - the UITheme will have no more subclasses. > - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme. > > This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside. > > Cheers, > Doru > > > > On May 14, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Looking at the code I have the impression that many UITheme methods should be moved to the their classes >> >> Example: >> >> >> UITheme>>newGroupboxIn: aThemedMorph label: aString >> "Answer a groupbox with the given label." >> >> ^GroupboxMorph new >> font: self labelFont; >> cornerStyle: aThemedMorph preferredCornerStyle; >> hResizing: #spaceFill; >> vResizing: #spaceFill; >> label: aString; >> yourself >> >> Why this is not a creation method on GroupBox? >> >> Then the trait TeasilyThemed looks suspicious to me. >> >> >> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Frank Shearar

Like I say, _in this case_ just implement a common method that everything speaks. And if you follow that all the time you get crazy nonsense spamming all your objects. Or you can say "if this thing's like a Stream, do this; if it's like a Collection, do that". And in that case, basing that decision on inheritance is a fail. As always, it's a matter of judgement & taste. frank On 14 May 2013 21:27, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > why do we want to introduce a bad slow type system on certain single place? > Why a UI element would have to check that a given instance can do something > while we never ever do it in any other places. > > if we have a button and its label should be able to answer the message enabled > then we display the button and send the message enabled. > If it crashes then this is the programmer' fault. He should provide an object that responds > to enabled but we do not test it. > > And we should have nice polymorphic objects and not string and nil and color > why not array with hexa decimal colors? > > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). > > Stef > >> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I'm in favor killing all the respondsTo: >>> >>> acceptTextMorphs >>> "Accept any text morphs except for those that have no edits." >>> >>> self allMorphs do: [:p | >>> ((p respondsTo: #accept) and: [ >>> (p respondsTo: #hasUnacceptedEdits) and: [ >>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> They're a step up from #isKindOf:. It looks like you need is something >> that says "does this object respond to a particular set of messages >> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >> :) ) >> >> But in this particular case the solution looks like making a >> #insertADecentNameHere that particular classes of things can implement >> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >> >> frank >> > >

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Denis Kudriashov

Hello 2013/5/15 stephane ducasse <stephane.ducasse(a)free.fr> > > Hi, > > > > I was rather thinking of having the theme be a composable factory: > > - for each morph, we would have a factory that would know how to work > with that morph. In essence for the GroupBoxMorph, we would have the method > below in a GroupBoxFactory. > > Why a factory and not just the morph? In my Presenty it was my conclusion: prototypes is a way to go. So instead of UITheme>>newGroupboxIn: aThemedMorph label: aString "Answer a groupbox with the given label." ^GroupboxMorph new font: self labelFont; cornerStyle: aThemedMorph preferredCornerStyle; hResizing: #spaceFill; vResizing: #spaceFill; label: aString; yourself You can get UITheme>>newGroupboxIn: aThemedMorph label: aString ^groupboxMorph veryDeepCopy label: aString; yourself And of course you can make prototype morphs as settings and edit it in SettingsBrowser. In Presenty I gone very far with this idea

May 14, 2013

Re: [Pharo-dev] vm fixes

by Benjamin

indeed :) I close it Ben On May 14, 2013, at 10:47 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > does this relates to https://pharo.fogbugz.com/default.asp?10366#76222 ? > > > 2013/5/14 Tudor Girba <tudor(a)tudorgirba.com> > This sounds intriguing. Can you be more specific? :) > > Doru > > > On May 14, 2013, at 10:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > > Thank you :) > > > > This fix goes with pair with > > https://pharo.fogbugz.com/default.asp?10619 > > > > Thanks to Esteban, one can now deploy a Spec widget with the os window as window :) > > > > Ben > > > > On May 14, 2013, at 10:19 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > > >> thanks esteban! > >> > >> On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >>> Hi, > >>> > >>> I just pushed fix for a weird bug in cocoa cog vm. > >>> It was crashing image when resizing using DisplayScreen>>#hostWindowSize: but even worst, some times was crashing also when dragging a window outside the world screen... > >>> > >>> The fix is there, but you will need to wait until tomorrow to have it in zeroconf (because of weird mac jenkins slave permissions). > >>> > >>> This increases a bit more the VM stability, still not perfect, but we are getting closer :) > >>> > >>> Esteban > >> > >> > > > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > >

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Benjamin

You do not have that because *people* use respondsTo: ^^ My point was that if coder what to be lazy, and do not care about code, then you can always find a dirty hack-around This one kind of simulate a receiver respondsTo: #strangeMessage ifTrue: [ receiver strangeMessage ] ifFalse: [ .. ] â¦ Ben On May 14, 2013, at 10:32 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On May 14, 2013, at 10:25 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Then you will have >> >> [ receiver strangeMessage ] >> on: Error >> do: [ receiver otherMessage >> on: Error >> do: [ self defaultFallback ] ] > > can you show me real examples? > Because in 15 years of Smalltaking non trivial program (but may be not complex enough) I never > needed that. > > The few times where I did somethng like that was to load broken and incomplete Squeak code lazily in VisualWorks. But it was a real deep and fun hack > > Stef > >

May 14, 2013

Re: [Pharo-dev] vm fixes

by Benjamin

In the following picture, instead of doing the classical MessageBrowser new openWithSpec, and get a Morphic window inside the os window of Pharo I do MessageBrowser openWorldWithSpec And here the message browser window *is* the system window. Basically, it sticks the morph on the world, do some magic around, and voilÃ . The cool part is that the rest of the code do not change at all, and still it opens a the good size, the title is properly updated etc Ben On May 14, 2013, at 10:28 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > This sounds intriguing. Can you be more specific? :) > > Doru > > > On May 14, 2013, at 10:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Thank you :) >> >> This fix goes with pair with >> https://pharo.fogbugz.com/default.asp?10619 >> >> Thanks to Esteban, one can now deploy a Spec widget with the os window as window :) >> >> Ben >> >> On May 14, 2013, at 10:19 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> thanks esteban! >>> >>> On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I just pushed fix for a weird bug in cocoa cog vm. >>>> It was crashing image when resizing using DisplayScreen>>#hostWindowSize: but even worst, some times was crashing also when dragging a window outside the world screen... >>>> >>>> The fix is there, but you will need to wait until tomorrow to have it in zeroconf (because of weird mac jenkins slave permissions). >>>> >>>> This increases a bit more the VM stability, still not perfect, but we are getting closer :) >>>> >>>> Esteban >>> >>> >> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

May 14, 2013

Re: [Pharo-dev] vm fixes

by phil＠highoctane.be

does this relates to https://pharo.fogbugz.com/default.asp?10366#76222 ? 2013/5/14 Tudor Girba <tudor(a)tudorgirba.com> > This sounds intriguing. Can you be more specific? :) > > Doru > > > On May 14, 2013, at 10:23 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > > Thank you :) > > > > This fix goes with pair with > > https://pharo.fogbugz.com/default.asp?10619 > > > > Thanks to Esteban, one can now deploy a Spec widget with the os window > as window :) > > > > Ben > > > > On May 14, 2013, at 10:19 PM, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: > > > >> thanks esteban! > >> > >> On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > >>> Hi, > >>> > >>> I just pushed fix for a weird bug in cocoa cog vm. > >>> It was crashing image when resizing using > DisplayScreen>>#hostWindowSize: but even worst, some times was crashing > also when dragging a window outside the world screen... > >>> > >>> The fix is there, but you will need to wait until tomorrow to have it > in zeroconf (because of weird mac jenkins slave permissions). > >>> > >>> This increases a bit more the VM stability, still not perfect, but we > are getting closer :) > >>> > >>> Esteban > >> > >> > > > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > >

May 14, 2013

About the window hierarchy

by StÃ©phane Ducasse

Hi gary I wonder why the window hierarchy is so large. I thought that a window is a simple widget that can embedded other more complex one. As such I thought that we could have a couple different windows and that after we can get a hierarchy of classes such as PopupChoiceDialog or LongMessage â¦ that could be plugged into a window as a standalone or added to other more complex UI. S.

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by stephane ducasse

On May 14, 2013, at 10:25 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Then you will have > > [ receiver strangeMessage ] > on: Error > do: [ receiver otherMessage > on: Error > do: [ self defaultFallback ] ] can you show me real examples? Because in 15 years of Smalltaking non trivial program (but may be not complex enough) I never needed that. The few times where I did somethng like that was to load broken and incomplete Squeak code lazily in VisualWorks. But it was a real deep and fun hack Stef

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Tudor Girba

+1 Doru On May 14, 2013, at 10:27 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > why do we want to introduce a bad slow type system on certain single place? > Why a UI element would have to check that a given instance can do something > while we never ever do it in any other places. > > if we have a button and its label should be able to answer the message enabled > then we display the button and send the message enabled. > If it crashes then this is the programmer' fault. He should provide an object that responds > to enabled but we do not test it. > > And we should have nice polymorphic objects and not string and nil and color > why not array with hexa decimal colors? > > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). > > Stef > >> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I'm in favor killing all the respondsTo: >>> >>> acceptTextMorphs >>> "Accept any text morphs except for those that have no edits." >>> >>> self allMorphs do: [:p | >>> ((p respondsTo: #accept) and: [ >>> (p respondsTo: #hasUnacceptedEdits) and: [ >>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> They're a step up from #isKindOf:. It looks like you need is something >> that says "does this object respond to a particular set of messages >> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >> :) ) >> >> But in this particular case the solution looks like making a >> #insertADecentNameHere that particular classes of things can implement >> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >> >> frank >> > > -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

May 14, 2013