- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [update 3.0] #30448

by Pavel Krivanek

Damn, the last row of the last plugins fills all the window... -- Pavel 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Thanks, this seems to work: > > defaultSpec > > | layout | > layout := SpecLayout composed. > self pluginClasses do: [ :c | > layout add: {#model. #class. #pluginOf:. c. #defaultSpec} ]. > > ^ layout. > > > plugin code on the instance side looks like this: > > defaultSpec > > ^ SpecLayout composed > newRow:[: r | > r add: #finderButtonModel; > add: #browserButtonModel] > height: 25. > > > -- Pavel > > 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >> Since you are doing some really edge use of Spec, >> it's not covered by Spec easily. >> >> But if on you model you have a method returning your pluginClasses, you could do maybe: >> >> | layout | >> layout := SpecLayout composed. >> self pluginClasses do: [ :c | >> layout add: {#model. pluginOf:. c} ] >> >> I am not sure it works, but it worth a try :P >> >> Ben >> >> On Oct 4, 2013, at 9:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> This was the original code for the spec that embeds plugins. As you >>> can see, it had to use ugly addMorph:. I do not think that I need to >>> do something special. Has the current Spec a better way how to do >>> that? >>> >>> defaultSpec >>> >>> | spec | >>> spec := OrderedCollection with: #ContainerModel. >>> spec addAll: {#changeTableLayout. >>> #listDirection:. #topToBottom. >>> #hResizing:. #spaceFill. >>> #vResizing:. #spaceFill.}. >>> self pluginClasses do: [:c | >>> spec add: #addMorph:. >>> spec add: {(self pluginOf: c) defaultSpec}]. >>> ^ spec asArray. >>> >>> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> In other words... I have a model that has some plugins. I need to >>>> generate a spec that embeds specs generated for each plugin. Models >>>> for this embedded specs must be the plugins, not the original model. >>>> >>>> -- Pavel >>>> >>>> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>>> well, and the version with "SpecLayout composed" when I do not need >>>>> direct fractions? >>>>> >>>>> ^ SpecLayout composed >>>>> newRow:[: r | >>>>> r add: #finderButtonModel] >>>>> height: 25 >>>>> >>>>> How to send #finderButtonModel to different object than SpecInterpreter model? >>>>> >>>>> -- Pavel >>>>> >>>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>>>> ^{ #ContainerModel. >>>>>> >>>>>> #vShrinkWrap. >>>>>> >>>>>> #add:. {{self. #finderButtonModel}. >>>>>> >>>>>> #layout:. #(FrameLayout >>>>>> >>>>>> rightFraction: 0.125)}. >>>>>> >>>>>> #add:. {{self. #browserButtonModel}. >>>>>> >>>>>> #layout:. #(FrameLayout >>>>>> >>>>>> leftFraction: 0.125 >>>>>> rightFraction: 0.25)}} >>>>>> >>>>>> This should work, but looks strange though :P >>>>>> >>>>>> Ben >>>>>> >>>>>> On Oct 4, 2013, at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>>>> >>>>>> Ben, >>>>>> >>>>>> how now should look code like this: >>>>>> >>>>>> defaultSpec >>>>>> >>>>>> ^{ #ComposableSpec. >>>>>> #vResizing:. #shrinkWrap. >>>>>> #add:. {{self. #finderButtonModel}. >>>>>> #layout:. #(FrameLayout >>>>>> rightFraction: 0.125)}. >>>>>> #add:. {{self. #browserButtonModel}. >>>>>> #layout:. #(FrameLayout >>>>>> leftFraction: 0.125 >>>>>> rightFraction: 0.25)}} >>>>>> >>>>>> -- Pavel >>>>>> >>>>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>>>> >>>>>> For Spec users: >>>>>> >>>>>> The change is mostly backward compatible :) >>>>>> 2 things really changed: >>>>>> - direct access to a model's widget is not returning what it used to return. >>>>>> This is done on purpose since >>>>>> it's very often a bad idea to directly access the widget. >>>>>> - some behaviour on trees are now only available after the tree build. This >>>>>> is because some properties >>>>>> have been moved on the adapter directly, which is reachable only after the >>>>>> model build. >>>>>> You can use `whenBuiltDo:` to add post-build actions. >>>>>> >>>>>> Enjoy this new Spec :P >>>>>> >>>>>> Ben >>>>>> >>>>>> On Oct 4, 2013, at 2:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>>> >>>>>> 30448 >>>>>> ----- >>>>>> >>>>>> 11740 Remove Morphic dependency from Spec >>>>>> https://pharo.fogbugz.com/f/cases/11740 >>>>>> >>>>>> A Huge change from Ben... >>>>>> >>>>>> Diff information: >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1292.diff >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.33.diff >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.265… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.150.d… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.35.di… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-PolyWidgets-MarcusDenker… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-MarcusDenker.58.d… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.48… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.175.di… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-MarcusDenker.43.… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-MarcusDenker.35… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-MarcusDen… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Adapters-MarcusDenker.3.… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Tools-Spec-MarcusD… >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.58.diff >>>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… >>>>>> >>>>>> >>>>>> >>>>>> >>> >> >>

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30448

by Pavel Krivanek

Thanks, this seems to work: defaultSpec | layout | layout := SpecLayout composed. self pluginClasses do: [ :c | layout add: {#model. #class. #pluginOf:. c. #defaultSpec} ]. ^ layout. plugin code on the instance side looks like this: defaultSpec ^ SpecLayout composed newRow:[: r | r add: #finderButtonModel; add: #browserButtonModel] height: 25. -- Pavel 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: > Since you are doing some really edge use of Spec, > it's not covered by Spec easily. > > But if on you model you have a method returning your pluginClasses, you could do maybe: > > | layout | > layout := SpecLayout composed. > self pluginClasses do: [ :c | > layout add: {#model. pluginOf:. c} ] > > I am not sure it works, but it worth a try :P > > Ben > > On Oct 4, 2013, at 9:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> This was the original code for the spec that embeds plugins. As you >> can see, it had to use ugly addMorph:. I do not think that I need to >> do something special. Has the current Spec a better way how to do >> that? >> >> defaultSpec >> >> | spec | >> spec := OrderedCollection with: #ContainerModel. >> spec addAll: {#changeTableLayout. >> #listDirection:. #topToBottom. >> #hResizing:. #spaceFill. >> #vResizing:. #spaceFill.}. >> self pluginClasses do: [:c | >> spec add: #addMorph:. >> spec add: {(self pluginOf: c) defaultSpec}]. >> ^ spec asArray. >> >> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> In other words... I have a model that has some plugins. I need to >>> generate a spec that embeds specs generated for each plugin. Models >>> for this embedded specs must be the plugins, not the original model. >>> >>> -- Pavel >>> >>> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> well, and the version with "SpecLayout composed" when I do not need >>>> direct fractions? >>>> >>>> ^ SpecLayout composed >>>> newRow:[: r | >>>> r add: #finderButtonModel] >>>> height: 25 >>>> >>>> How to send #finderButtonModel to different object than SpecInterpreter model? >>>> >>>> -- Pavel >>>> >>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>>> ^{ #ContainerModel. >>>>> >>>>> #vShrinkWrap. >>>>> >>>>> #add:. {{self. #finderButtonModel}. >>>>> >>>>> #layout:. #(FrameLayout >>>>> >>>>> rightFraction: 0.125)}. >>>>> >>>>> #add:. {{self. #browserButtonModel}. >>>>> >>>>> #layout:. #(FrameLayout >>>>> >>>>> leftFraction: 0.125 >>>>> rightFraction: 0.25)}} >>>>> >>>>> This should work, but looks strange though :P >>>>> >>>>> Ben >>>>> >>>>> On Oct 4, 2013, at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>>> >>>>> Ben, >>>>> >>>>> how now should look code like this: >>>>> >>>>> defaultSpec >>>>> >>>>> ^{ #ComposableSpec. >>>>> #vResizing:. #shrinkWrap. >>>>> #add:. {{self. #finderButtonModel}. >>>>> #layout:. #(FrameLayout >>>>> rightFraction: 0.125)}. >>>>> #add:. {{self. #browserButtonModel}. >>>>> #layout:. #(FrameLayout >>>>> leftFraction: 0.125 >>>>> rightFraction: 0.25)}} >>>>> >>>>> -- Pavel >>>>> >>>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>>> >>>>> For Spec users: >>>>> >>>>> The change is mostly backward compatible :) >>>>> 2 things really changed: >>>>> - direct access to a model's widget is not returning what it used to return. >>>>> This is done on purpose since >>>>> it's very often a bad idea to directly access the widget. >>>>> - some behaviour on trees are now only available after the tree build. This >>>>> is because some properties >>>>> have been moved on the adapter directly, which is reachable only after the >>>>> model build. >>>>> You can use `whenBuiltDo:` to add post-build actions. >>>>> >>>>> Enjoy this new Spec :P >>>>> >>>>> Ben >>>>> >>>>> On Oct 4, 2013, at 2:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>> >>>>> 30448 >>>>> ----- >>>>> >>>>> 11740 Remove Morphic dependency from Spec >>>>> https://pharo.fogbugz.com/f/cases/11740 >>>>> >>>>> A Huge change from Ben... >>>>> >>>>> Diff information: >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1292.diff >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.33.diff >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.265… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.150.d… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.35.di… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-PolyWidgets-MarcusDenker… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-MarcusDenker.58.d… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.48… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.175.di… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-MarcusDenker.43.… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-MarcusDenker.35… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-MarcusDen… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Adapters-MarcusDenker.3.… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Tools-Spec-MarcusD… >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.58.diff >>>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… >>>>> >>>>> >>>>> >>>>> >> > >

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30446

by Tudor Girba

Impressive is the right word, indeed :) Doru On Fri, Oct 4, 2013 at 12:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Oct 2013, at 10:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > 30446 > > ----- > > > > 11719 integrate all the changes from the repository of the new debugger > > https://pharo.fogbugz.com/f/cases/11719 > > > > This commit contains the following main changes: > > - debugging actions are first class entities; they are defined in > separate classes. All actions from the toolbar are added dynamically based > on pragmas. > > - separated the spec interface into multiple widgets: stack, toolbar, > buttons > > - have dedicated filters to hide contexts from the stack > > > > Thanks to Clara Allende and Andrei Chis! > > Impressive stuff ! > > > Diff information: > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Settings-Tools-MarcusDenker.4… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.76… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerFilters-MarcusDenker.… > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30448

by Benjamin

Since you are doing some really edge use of Spec, it's not covered by Spec easily. But if on you model you have a method returning your pluginClasses, you could do maybe: | layout | layout := SpecLayout composed. self pluginClasses do: [ :c | layout add: {#model. pluginOf:. c} ] I am not sure it works, but it worth a try :P Ben On Oct 4, 2013, at 9:28 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > This was the original code for the spec that embeds plugins. As you > can see, it had to use ugly addMorph:. I do not think that I need to > do something special. Has the current Spec a better way how to do > that? > > defaultSpec > > | spec | > spec := OrderedCollection with: #ContainerModel. > spec addAll: {#changeTableLayout. > #listDirection:. #topToBottom. > #hResizing:. #spaceFill. > #vResizing:. #spaceFill.}. > self pluginClasses do: [:c | > spec add: #addMorph:. > spec add: {(self pluginOf: c) defaultSpec}]. > ^ spec asArray. > > 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> In other words... I have a model that has some plugins. I need to >> generate a spec that embeds specs generated for each plugin. Models >> for this embedded specs must be the plugins, not the original model. >> >> -- Pavel >> >> 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> well, and the version with "SpecLayout composed" when I do not need >>> direct fractions? >>> >>> ^ SpecLayout composed >>> newRow:[: r | >>> r add: #finderButtonModel] >>> height: 25 >>> >>> How to send #finderButtonModel to different object than SpecInterpreter model? >>> >>> -- Pavel >>> >>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>> ^{ #ContainerModel. >>>> >>>> #vShrinkWrap. >>>> >>>> #add:. {{self. #finderButtonModel}. >>>> >>>> #layout:. #(FrameLayout >>>> >>>> rightFraction: 0.125)}. >>>> >>>> #add:. {{self. #browserButtonModel}. >>>> >>>> #layout:. #(FrameLayout >>>> >>>> leftFraction: 0.125 >>>> rightFraction: 0.25)}} >>>> >>>> This should work, but looks strange though :P >>>> >>>> Ben >>>> >>>> On Oct 4, 2013, at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> >>>> Ben, >>>> >>>> how now should look code like this: >>>> >>>> defaultSpec >>>> >>>> ^{ #ComposableSpec. >>>> #vResizing:. #shrinkWrap. >>>> #add:. {{self. #finderButtonModel}. >>>> #layout:. #(FrameLayout >>>> rightFraction: 0.125)}. >>>> #add:. {{self. #browserButtonModel}. >>>> #layout:. #(FrameLayout >>>> leftFraction: 0.125 >>>> rightFraction: 0.25)}} >>>> >>>> -- Pavel >>>> >>>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>>> >>>> For Spec users: >>>> >>>> The change is mostly backward compatible :) >>>> 2 things really changed: >>>> - direct access to a model's widget is not returning what it used to return. >>>> This is done on purpose since >>>> it's very often a bad idea to directly access the widget. >>>> - some behaviour on trees are now only available after the tree build. This >>>> is because some properties >>>> have been moved on the adapter directly, which is reachable only after the >>>> model build. >>>> You can use `whenBuiltDo:` to add post-build actions. >>>> >>>> Enjoy this new Spec :P >>>> >>>> Ben >>>> >>>> On Oct 4, 2013, at 2:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> 30448 >>>> ----- >>>> >>>> 11740 Remove Morphic dependency from Spec >>>> https://pharo.fogbugz.com/f/cases/11740 >>>> >>>> A Huge change from Ben... >>>> >>>> Diff information: >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1292.diff >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.33.diff >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.265… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.150.d… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.35.di… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-PolyWidgets-MarcusDenker… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-MarcusDenker.58.d… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.48… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.175.di… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-MarcusDenker.43.… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-MarcusDenker.35… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-MarcusDen… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Adapters-MarcusDenker.3.… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Tools-Spec-MarcusD… >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.58.diff >>>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… >>>> >>>> >>>> >>>> >

Oct. 4, 2013

Re: [Pharo-dev] What is WeakActionSequence?

by ClÃ©ment Bera

This is a good question I was always wondering. I think it is related to event triggered in DependentFields of Object. It triggers several events. Weak because somehow there are weak event handled without weak references, probably due to the lack of ephemerons. (in some case the activation of the event or a veryDeepCopy delete the event if it is not referenced) 2013/10/4 Camillo Bruni <camillobruni(a)gmail.com> > What is that class? No comments, two single methods on Object that refer > to it? >

Oct. 4, 2013

Re: [Pharo-dev] additional Milestone label for applications

by Camillo Bruni

On 2013-10-04, at 19:44, btc(a)openinworld.com wrote: > Camillo Bruni wrote: >> If you want to track an external project on fogbugz, we should also create a proper fogbugz project, so it is clearly separated. > There is a separate Project='Launcher', but I guess its hard to filter out when many Projects are subparts of the main image. >> On a project-basis you can define custom milestones. >> >> > Good to know. I guess 'Launcher' just inherited the default. Who can update those? only admins currently, though the club is not that exclusive :) so if you want I can make you one...

Oct. 4, 2013

Re: [Pharo-dev] [ann] system attraction view

by Tudor Girba

Hi, On Fri, Oct 4, 2013 at 2:42 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > > > Le 04/10/2013 14:14, Tudor Girba a Ã©crit : > >> Hi, >> >> >> On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr**>> wrote: >> >> Hi Tudor, >> >> I found your visualisation very interesting, and wondered about one >> thing linked to your blog post and if I got it right. >> >> The visualisation you're showing is able to show, at the single >> class level, if a class is more or less regular (i.e. tidy == well >> designed?) but you show that it will loose very shortly it's tidy >> shape if the classes it joins to are added to the visualisation. And >> I wondered if this was a choice on the graph layout algorithm you've >> choosen, i.e. that maintaining the tidiness of the class could be >> done with a different layout algorithm? Maybe one which has a >> measure of tidiness of the class at the local level, and weight it >> against the position and attraction of its links to the other >> components in the application? >> >> >> My argumentation is that if we look at a class isolated it will have a >> certain shape, and because we are exposed to this view (the IDE is >> always showing me only that) all the time we will optimize it such that >> the shape is tidy. But if we look at the class in the context of its >> interactions the shape will be less recognizable. The chosen layout is a >> very simple one, and the goal is not to say whether the structure is >> good or bad. This is neither good nor bad. It simply argues how steering >> the architecture has to take these forces into account. >> > > Hum, my point would be that a locally well designed class is a factor to > strive for; also that the overall architecture has it's impact on it as > well, but not so as to so easily erase the local good property when looking > at the visualisation, otherwise the latter may not end up so usefull, > that's all. > > I do agree with your point, I just believe the layout could carry a bit > more insight in trying to both show the local property the code was trying > to achieve (and areas where it failed) and the "emergence" of the > architecture coupling on it. Your representation seemed to imply that local > good design is unimportant in the architectural view, and I'm sure this is > not what it is supposed to convey. There are many visualizations that try to capture good and bad, but I distinctly did not want the visualization to be about this. It is about how context changes the shape. As a consequence, architecture does not exist without the context, and as the context evolves in millions of little ways, so does architecture. Constantly. That is all. The main goal is to support technical people argue when discussing with managers, rather than necessarily having a say about the value. But, here is a challenge: would you like to play with it and propose a different approach? Btw, the current implementation has 19 lines :). > In the mean time, I'm slowly discovering we have amazing software >> architecture visualisation tools :) >> >> >> They really are amazing :). If you want to get more information about >> it, you can join the Moose mailing list: >> http://www.moosetechnology.**org/about/contact<http://www.moosetechnology.org/about/contact> >> > > I'll do once I have a strong/practical incentive :) I know its there, > StÃ©phane showed a lot of interesting things in it when he came here, but I > didn't managed to organize things around that subject. > > > Would really like to setup a project on that if I get the chance. >> >> >> What do you mean? What kind of a project? >> > > Collaborative R or R&D project :) Only way I can justify working on > something like that... > > A good fit would be visualisation of large software in my lab expertise > area : high performance and real time massively parallel software on > embedded systems. Perhaps you can get some inspiration of places to use Moose in on the humane-assessment.com site. In particular, on the blog I try to offer examples and stories for how assessment should change the face of development :). Cheers, Doru Thierry > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2013

Re: [Pharo-dev] What is WeakActionSequence?

by Sven Van Caekenberghe

On 04 Oct 2013, at 19:27, Camillo Bruni <camillobruni(a)gmail.com> wrote: > What is that class? No comments, two single methods on Object that refer to it? If you remove it, the world as we know it will end ! Seriously, I've seen this before, I also asked the same question, but no one seems to know. Sven

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30448

by Pavel Krivanek

This was the original code for the spec that embeds plugins. As you can see, it had to use ugly addMorph:. I do not think that I need to do something special. Has the current Spec a better way how to do that? defaultSpec | spec | spec := OrderedCollection with: #ContainerModel. spec addAll: {#changeTableLayout. #listDirection:. #topToBottom. #hResizing:. #spaceFill. #vResizing:. #spaceFill.}. self pluginClasses do: [:c | spec add: #addMorph:. spec add: {(self pluginOf: c) defaultSpec}]. ^ spec asArray. 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > In other words... I have a model that has some plugins. I need to > generate a spec that embeds specs generated for each plugin. Models > for this embedded specs must be the plugins, not the original model. > > -- Pavel > > 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> well, and the version with "SpecLayout composed" when I do not need >> direct fractions? >> >> ^ SpecLayout composed >> newRow:[: r | >> r add: #finderButtonModel] >> height: 25 >> >> How to send #finderButtonModel to different object than SpecInterpreter model? >> >> -- Pavel >> >> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>> ^{ #ContainerModel. >>> >>> #vShrinkWrap. >>> >>> #add:. {{self. #finderButtonModel}. >>> >>> #layout:. #(FrameLayout >>> >>> rightFraction: 0.125)}. >>> >>> #add:. {{self. #browserButtonModel}. >>> >>> #layout:. #(FrameLayout >>> >>> leftFraction: 0.125 >>> rightFraction: 0.25)}} >>> >>> This should work, but looks strange though :P >>> >>> Ben >>> >>> On Oct 4, 2013, at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> >>> Ben, >>> >>> how now should look code like this: >>> >>> defaultSpec >>> >>> ^{ #ComposableSpec. >>> #vResizing:. #shrinkWrap. >>> #add:. {{self. #finderButtonModel}. >>> #layout:. #(FrameLayout >>> rightFraction: 0.125)}. >>> #add:. {{self. #browserButtonModel}. >>> #layout:. #(FrameLayout >>> leftFraction: 0.125 >>> rightFraction: 0.25)}} >>> >>> -- Pavel >>> >>> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >>> >>> For Spec users: >>> >>> The change is mostly backward compatible :) >>> 2 things really changed: >>> - direct access to a model's widget is not returning what it used to return. >>> This is done on purpose since >>> it's very often a bad idea to directly access the widget. >>> - some behaviour on trees are now only available after the tree build. This >>> is because some properties >>> have been moved on the adapter directly, which is reachable only after the >>> model build. >>> You can use `whenBuiltDo:` to add post-build actions. >>> >>> Enjoy this new Spec :P >>> >>> Ben >>> >>> On Oct 4, 2013, at 2:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> 30448 >>> ----- >>> >>> 11740 Remove Morphic dependency from Spec >>> https://pharo.fogbugz.com/f/cases/11740 >>> >>> A Huge change from Ben... >>> >>> Diff information: >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1292.diff >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.33.diff >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.265… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.150.d… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.35.di… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-PolyWidgets-MarcusDenker… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-MarcusDenker.58.d… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.48… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.175.di… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-MarcusDenker.43.… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-MarcusDenker.35… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-MarcusDen… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Adapters-MarcusDenker.3.… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Tools-Spec-MarcusD… >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.58.diff >>> http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… >>> >>> >>> >>>

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30448

by Pavel Krivanek

In other words... I have a model that has some plugins. I need to generate a spec that embeds specs generated for each plugin. Models for this embedded specs must be the plugins, not the original model. -- Pavel 2013/10/4 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > well, and the version with "SpecLayout composed" when I do not need > direct fractions? > > ^ SpecLayout composed > newRow:[: r | > r add: #finderButtonModel] > height: 25 > > How to send #finderButtonModel to different object than SpecInterpreter model? > > -- Pavel > > 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >> ^{ #ContainerModel. >> >> #vShrinkWrap. >> >> #add:. {{self. #finderButtonModel}. >> >> #layout:. #(FrameLayout >> >> rightFraction: 0.125)}. >> >> #add:. {{self. #browserButtonModel}. >> >> #layout:. #(FrameLayout >> >> leftFraction: 0.125 >> rightFraction: 0.25)}} >> >> This should work, but looks strange though :P >> >> Ben >> >> On Oct 4, 2013, at 8:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> Ben, >> >> how now should look code like this: >> >> defaultSpec >> >> ^{ #ComposableSpec. >> #vResizing:. #shrinkWrap. >> #add:. {{self. #finderButtonModel}. >> #layout:. #(FrameLayout >> rightFraction: 0.125)}. >> #add:. {{self. #browserButtonModel}. >> #layout:. #(FrameLayout >> leftFraction: 0.125 >> rightFraction: 0.25)}} >> >> -- Pavel >> >> 2013/10/4 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com>: >> >> For Spec users: >> >> The change is mostly backward compatible :) >> 2 things really changed: >> - direct access to a model's widget is not returning what it used to return. >> This is done on purpose since >> it's very often a bad idea to directly access the widget. >> - some behaviour on trees are now only available after the tree build. This >> is because some properties >> have been moved on the adapter directly, which is reachable only after the >> model build. >> You can use `whenBuiltDo:` to add post-build actions. >> >> Enjoy this new Spec :P >> >> Ben >> >> On Oct 4, 2013, at 2:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> 30448 >> ----- >> >> 11740 Remove Morphic dependency from Spec >> https://pharo.fogbugz.com/f/cases/11740 >> >> A Huge change from Ben... >> >> Diff information: >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1292.diff >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.33.diff >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.265… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.150.d… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.35.di… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-MorphicAdapters-MarcusDe… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-PolyWidgets-MarcusDenker… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Layout-MarcusDenker.58.d… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.48… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.175.di… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Builder-MarcusDenker.43.… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Bindings-MarcusDenker.35… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusRefactoring-MarcusDen… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Adapters-MarcusDenker.3.… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Tools-Spec-MarcusD… >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.58.diff >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/HudsonBuildTools20-MarcusDenk… >> >> >> >>

Oct. 4, 2013