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

Re: [Pharo-project] Spec news

by Benjamin

Can you show me your SpecLayout please ? Ben On Jan 8, 2013, at 3:57 PM, Pavel Krivanek wrote: > Hi Stef, > > get it here: > > Gofer new > smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; > package: 'Periscope'; > load. > > activate with: > > Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} . > > I tried to change it to the array form but it doesn't help. This is > the error stack: > > #('Array(Object)' 'doesNotUnderstand: #layoutFrame:') > #('SpecInterpreter' 'actionToPerformWithSelector:arguments:') > #('SpecInterpreter' 'interpretASpec:') > #('SpecInterpreter' 'interpretASpec:model:superSpec:') > #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') > #('[...] in SpecInterpreter' 'interpretASpec:') > #('Array(SequenceableCollection)' 'collect:') > #('SpecInterpreter' 'interpretASpec:') > #('SpecInterpreter' 'interpretASpec:model:superSpec:') > #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') > #('SpecInterpreter' 'retreiveSpecFrom:') > #('SpecInterpreter' 'interpretASpec:') > #('SpecInterpreter' 'interpretASpec:model:superSpec:') > #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') > #('[...] in SpecInterpreter' 'interpretASpec:') > #('Array(SequenceableCollection)' 'collect:') > #('SpecInterpreter' 'interpretASpec:') > #('SpecInterpreter' 'interpretASpec:model:superSpec:') > #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') > #('SpecInterpreter class' 'interpretASpec:model:superSpec:') > > -- Pavel > > On Tue, Jan 8, 2013 at 2:59 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi Ben, >>> >>> trying to run Periscope on the latest Pharo image, I see that >>> everything is broken again. Please, start to write some documentation >>> about Spec development, what have you changed, what do you plan to >>> change, what are the new prefered ways to write UI specification and >>> how to migrate old code. At least write some short mails here. >> >> Hi pavel >> >> where is your code? >> Because we did a massive refactoring with igor to free layoutFrame users from the tyranny of fractions:offset: >> >> so you can have a look at some spec in the latest 20 and you will see that now >> we use >> >> >> #layout: . #(0 0 1 1 0 22 0 0) >> >> when it was >> #layout: >> {#LayoutFrame . #fractions:offsets:. (0@0 corner: 1@0). (0@0 corner: 0@20). >> >> >> Now may be LayoutFrame should not be in morphic so that Spec is independent from Morphic but for now we prefered to avoid >> to have reference to LayoutFrame and more important use of #fractions:offsets: >> >> Esteban will start to work on a UIBuilder because we do not want to have to code such methods and he will do a pass on Spec. >> After we will stabilize it. >> >> >>> I know, it is a lot of work but we cannot write tools and bindings to >>> other user interface if the basic UI framework is undocumented and >>> changing silently. >>> >>> Cheers, >>> -- Pavel >>> >> >> >

Jan. 8, 2013

Re: [Pharo-project] Spec news

by Pavel Krivanek

Hi Stef, get it here: Gofer new smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; package: 'Periscope'; load. activate with: Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} . I tried to change it to the array form but it doesn't help. This is the error stack: #('Array(Object)' 'doesNotUnderstand: #layoutFrame:') #('SpecInterpreter' 'actionToPerformWithSelector:arguments:') #('SpecInterpreter' 'interpretASpec:') #('SpecInterpreter' 'interpretASpec:model:superSpec:') #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') #('[...] in SpecInterpreter' 'interpretASpec:') #('Array(SequenceableCollection)' 'collect:') #('SpecInterpreter' 'interpretASpec:') #('SpecInterpreter' 'interpretASpec:model:superSpec:') #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') #('SpecInterpreter' 'retreiveSpecFrom:') #('SpecInterpreter' 'interpretASpec:') #('SpecInterpreter' 'interpretASpec:model:superSpec:') #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') #('[...] in SpecInterpreter' 'interpretASpec:') #('Array(SequenceableCollection)' 'collect:') #('SpecInterpreter' 'interpretASpec:') #('SpecInterpreter' 'interpretASpec:model:superSpec:') #('SpecInterpreter class' 'private_interpretASpec:model:superSpec:') #('SpecInterpreter class' 'interpretASpec:model:superSpec:') -- Pavel On Tue, Jan 8, 2013 at 2:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi Ben, >> >> trying to run Periscope on the latest Pharo image, I see that >> everything is broken again. Please, start to write some documentation >> about Spec development, what have you changed, what do you plan to >> change, what are the new prefered ways to write UI specification and >> how to migrate old code. At least write some short mails here. > > Hi pavel > > where is your code? > Because we did a massive refactoring with igor to free layoutFrame users from the tyranny of fractions:offset: > > so you can have a look at some spec in the latest 20 and you will see that now > we use > > > #layout: . #(0 0 1 1 0 22 0 0) > > when it was > #layout: > {#LayoutFrame . #fractions:offsets:. (0@0 corner: 1@0). (0@0 corner: 0@20). > > > Now may be LayoutFrame should not be in morphic so that Spec is independent from Morphic but for now we prefered to avoid > to have reference to LayoutFrame and more important use of #fractions:offsets: > > Esteban will start to work on a UIBuilder because we do not want to have to code such methods and he will do a pass on Spec. > After we will stabilize it. > > >> I know, it is a lot of work but we cannot write tools and bindings to >> other user interface if the basic UI framework is undocumented and >> changing silently. >> >> Cheers, >> -- Pavel >> > >

Jan. 8, 2013

Re: [Pharo-project] About morph layout

by Igor Stasenko

On 8 January 2013 14:04, Ben Coman <btc(a)openinworld.com> wrote: > Just curious... > Is it possible to open a second native window in addition to the standard > one when the image starts? Then the Small Morphic could be tested with that > second window while the programming is safely done in the first. > > In addition, this feature could be useful for dual monitors. I personally > don't like splitting a single window across two monitors, especially when > they have different resolutions. In my case, my main computer is a laptop > that at home I connect to a 24" monitor. > Theoretically, yes. There is a plugin which supports that (but not on all platforms, only mac and win). But the problem is that Morphic has only single Display.. a global singleton.. and to change that, you'll have to walk way longer distance :) > cheers -ben > > > Fernando Olivero wrote: >> >> Hi, a couple of years ago, i tried to port Small Morphic from CUIS to >> Pharo1.2. >> >> After a couple of weeks i gave up, because there are to many relations >> between the UI framework and the underlying system, which made it not just >> a matter of UI porting, but a complete system diff. >> >> Morphic relies on some kernel graphics which slightly differ in both >> systems (Form, Canvas, etc..), and on the base object model >> infrastructure, >> and some IDE related objects such as SystemNavigation , UIManager, etc.. >> >> I prefer the approach taken by Stef and other community members, clean the >> current system one step at a time. Maybe, there will be some overlapping >> with Juan's great work on CUIS, but on the bright side you wont get burned >> trying to port, manage, and plug a new Morphic into Pharo. >> >> Fernando >> >> pd: It was so hard, i decided to start a new UI framework from the ground >> up. >> >> >> >> >> On Wed, Jan 2, 2013 at 7:52 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> >>> >>> Craig's NAIAD stands for "Name And Identity Are Distinct". Just >>> thinking aloud -- because Morphic is so entrenched.. Could NAIAD or >>> Colin's Environments allow Juan's Morphic (or, Morphic3) to co-exist >>> with original Morphic, so that it would allow working on the port >>> without depending on it for the tools? Once the port was complete, a >>> sane migration could more easily occur.. >>> >>> >>> On Wed, Jan 2, 2013 at 7:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> >>>> On 2 January 2013 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>> >>>>> >>>>> Hello again Igor >>>>> and Happy and Successful New "Pharo" Year 2013 >>>>> >>>>> >>>> >>>> Thanks Hannes :) >>>> Wish best to you in New Year too :) >>>> >>>> >>>> >>>>> >>>>> --Hannes >>>>> >>>>> my notes are inserted below. >>>>> >>>>> >>>>> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> On 24 December 2012 09:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> Hello Igor >>>>>>> >>>>>>> Thank you for this interesting mail. An issue over 11 years old, see >>>>>>> below. >>>>>>> >>>>>>> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> just wanna share some ideas about how we can cleanup morph a bit. >>>>>>>> >>>>>>> >>>>>>> A bit? >>>>>>> It will be a lot of effort. >>>>>>> >>>>>>> >>>>>> >>>>>> We can do it in small steps. >>>>>> >>>>>> >>>>>>> >>>>>>> Squeak 4.4-12234 (current) >>>>>>> >>>>>>> Morph selectors size 1183 >>>>>>> >>>>>>> >>>>>>> Pharo 2.0 (Beta) >>>>>>> >>>>>>> Morph selectors size 865 >>>>>>> >>>>>>> >>>>>>> Cuis 4.1 (18th Dec 2012) >>>>>>> >>>>>>> Morph selectors size 343 >>>>>>> >>>>>>> >>>>>>> This was an issue in 2001 >>>>>>> >>>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt >>>>>>> >>>>>>> see >>>>>>> >>>>>>> >>>>>> >>>>>> I am not first day here, of course i am aware of this :) >>>>>> >>>>> >>>>> Did you start working with Squeak already in 2001? >>>>> >>>>> >>>> >>>> no. But i know this is a long standing issue :) >>>> >>>> >>>>>>>> >>>>>>>> Layout.. bizarre. >>>>>>>> >>>>>>> >>>>>>> Yes, see humorous contribution from June 2001 >>>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt >>>>>>> >>>>>>> search for >>>>>>> >>>>>>> the Morph class has 924 methods >>>>>>> >>>>>>> in that mails >>>>>>> >>>>>>> There was an effort >>>>>>> Morphic Cleanup Project >>>>>>> >>>>>>> http://wiki.squeak.org/squeak/3005 >>>>>>> >>>>>>> lead by >>>>>>> >>>>>>> Diego Gomez Deck >>>>>>> >>>>>>> It produced some results. But they did not reach far enough. >>>>>>> >>>>>>> >>>>>> >>>>>> yes yes.. i know. >>>>>> >>>>>> >>>>>>> >>>>>>> However Juan Vuletic was successful in coming up with a simpler >>>>>>> >>> >>> Morphic in >>> >>>>>>> >>>>>>> Cuis. >>>>>>> >>>>>>> http://www.jvuletich.org/Cuis/Index.html >>>>>>> >>>>>>> >>>>>> >>>>>> search this mailing list for Small Morphic. >>>>>> It was an attempt to use Juan's work, which didn't fly. >>>>>> >>>>> >>>>> Of course I am aware of SmallMorphic. If a first attempt at >>>>> integrating SimpleMorphic into Pharo was not successful it does not >>>>> necessarily mean that a second one has to be a failure again. >>>>> >>>>> Time spent on an analysis why it didn't fly is surely not a waste. >>>>> >>>>> For example another approach could be instead of copying code from >>>>> Cuis and implanting it into Pharo "blob style" you could follow Juan >>>>> Vuletich's refactoring steps incrementally and copy smaller chunks of >>>>> code. Cuis had many releases until it reached version 4.1. >>>>> >>>>> In terms of factoring out classes from the class Morph you seem to >>>>> want to do that anyway. >>>>> >>>>> See for example >>>>> >>>>> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html >>>>> New in Cuis 2.7 (released September 3, 2010) >>>>> >>>>> * Morphic. New LayoutSpec mechanism. Simpler and nicer. >>>>> * Morphic Simplification: Layout, Extensions, etc >>>>> >>>>> >>>> >>>> Well, one thing is that Juan doing quite radical changes to code. >>>> He is not concerned about backwards compatibility (but unlike from >>>> >>> >>> Pharo, nobody >>> >>>> >>>> raising it as an issue over and over again ;) ). >>>> Yes, i checked new Cuis code. >>>> I see a lot of simplifications. But also i see reduced functionality. >>>> For instance, i did not found things like 'fill style', and themes. >>>> Also, i see some protocols is renamed, in preparation for something >>>> bigger (morphic 3 i guess ;) >>>> >>>> So, i agree we should not copy/paste the code. Because it won't fly. >>>> We should gradually analyze it and improve ours step by step. >>>> >>>> Layout code in Cuis is somewhat similar to what i proposing. >>>> But my proposal is essentially about approach, which you can apply to >>>> anything.. not just layouts in Morphics. >>>> >>>> >>>>>>>> >>>>>>>> There are so many methods dedicated to laying out morphs that it >>>>>>>> easy >>>>>>>> to get lost. >>>>>>>> >>>>>>> >>>>>>> Cuis has a new layout system. >>>>>>> >>>>>>> Worth to check out. >>>>>>> >>>>>>> >>>>>> >>>>>> Sure. >>>>>> >>>>> >>>>> Fine. >>>>> >>>>> >>>>>>>> >>>>>>>> For me the main mystery and source of confusion is that there >>>>>>>> >>> >>> actually >>> >>>>>>>> >>>>>>>> two different groups: >>>>>>>> >>>>>>>> - methods to control morph's own layout (in respect to its parent) >>>>>>>> - methods to control morph's children layout (something called >>>>>>>> layoutPolicy) >>>>>>>> >>>>>>>> the problem is that both APIs are found in single class, >>>>>>>> >>>>>>> >>>>>>> which one? >>>>>>> >>>>>>> >>>>>> >>>>>> Morph >>>>>> >>>>>> >>>>>>> >>>>>>> and most of >>>>>>> >>>>>>>> >>>>>>>> them contain 'layout' word in it, >>>>>>>> so it is really hard to determine which one to use and when.. >>>>>>>> >>>>>>>> Over a years, i seen that people learned how to use existing >>>>>>>> functionality, without delving deep into >>>>>>>> implementation detail. >>>>>>>> >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> But if you try to extend/change behavior (in your subclass), you >>>>>>>> will >>>>>>>> quite soon find out that it is really >>>>>>>> hard to tell with 100% certainty that the methods you override is >>>>>>>> the >>>>>>>> right place for your customization. >>>>>>>> >>>>>>> >>>>>>> Yes, this actually has made development very difficult. In such a way >>>>>>> that most people have abandoned it. Very few GUIs are actually built >>>>>>> with it. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Also, an important detail is extremely polluted protocol(s), making >>>>>>>> Morph a GOD class, >>>>>>>> >>>>> >>>>> Morph is at the root of a large subclasses tree. The question is: what >>>>> can be pushed down or factored out. An analysis in terms of number of >>>>> method candidates to move out would surely be a good thing to know. >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >>> >> >> >> > > > -- Best regards, Igor Stasenko.

Jan. 8, 2013

Re: [Pharo-project] Spec news

by Benjamin

On Jan 8, 2013, at 2:59 PM, StÃ©phane Ducasse wrote: > >> Hi Ben, >> >> trying to run Periscope on the latest Pharo image, I see that >> everything is broken again. Please, start to write some documentation >> about Spec development, what have you changed, what do you plan to >> change, what are the new prefered ways to write UI specification and >> how to migrate old code. At least write some short mails here. > > Hi pavel > > where is your code? > Because we did a massive refactoring with igor to free layoutFrame users from the tyranny of fractions:offset: > > so you can have a look at some spec in the latest 20 and you will see that now > we use > > > #layout: . #(0 0 1 1 0 22 0 0) why ?????? Why using a meaningless array when we could use object ? Ben > > when it was > #layout: > {#LayoutFrame . #fractions:offsets:. (0@0 corner: 1@0). (0@0 corner: 0@20). > > > Now may be LayoutFrame should not be in morphic so that Spec is independent from Morphic but for now we prefered to avoid > to have reference to LayoutFrame and more important use of #fractions:offsets: > > Esteban will start to work on a UIBuilder because we do not want to have to code such methods and he will do a pass on Spec. > After we will stabilize it. > > >> I know, it is a lot of work but we cannot write tools and bindings to >> other user interface if the basic UI framework is undocumented and >> changing silently. >> >> Cheers, >> -- Pavel >> > >

Jan. 8, 2013

Re: [Pharo-project] Spec news

by StÃ©phane Ducasse

> Hi Ben, > > trying to run Periscope on the latest Pharo image, I see that > everything is broken again. Please, start to write some documentation > about Spec development, what have you changed, what do you plan to > change, what are the new prefered ways to write UI specification and > how to migrate old code. At least write some short mails here. Hi pavel where is your code? Because we did a massive refactoring with igor to free layoutFrame users from the tyranny of fractions:offset: so you can have a look at some spec in the latest 20 and you will see that now we use #layout: . #(0 0 1 1 0 22 0 0) when it was #layout: {#LayoutFrame . #fractions:offsets:. (0@0 corner: 1@0). (0@0 corner: 0@20). Now may be LayoutFrame should not be in morphic so that Spec is independent from Morphic but for now we prefered to avoid to have reference to LayoutFrame and more important use of #fractions:offsets: Esteban will start to work on a UIBuilder because we do not want to have to code such methods and he will do a pass on Spec. After we will stabilize it. > I know, it is a lot of work but we cannot write tools and bindings to > other user interface if the basic UI framework is undocumented and > changing silently. > > Cheers, > -- Pavel >

Jan. 8, 2013

Re: [Pharo-project] About morph layout

by Ben Coman

Just curious... Is it possible to open a second native window in addition to the standard one when the image starts? Then the Small Morphic could be tested with that second window while the programming is safely done in the first. In addition, this feature could be useful for dual monitors. I personally don't like splitting a single window across two monitors, especially when they have different resolutions. In my case, my main computer is a laptop that at home I connect to a 24" monitor. cheers -ben Fernando Olivero wrote: > Hi, a couple of years ago, i tried to port Small Morphic from CUIS to > Pharo1.2. > > After a couple of weeks i gave up, because there are to many relations > between the UI framework and the underlying system, which made it not just > a matter of UI porting, but a complete system diff. > > Morphic relies on some kernel graphics which slightly differ in both > systems (Form, Canvas, etc..), and on the base object model infrastructure, > and some IDE related objects such as SystemNavigation , UIManager, etc.. > > I prefer the approach taken by Stef and other community members, clean the > current system one step at a time. Maybe, there will be some overlapping > with Juan's great work on CUIS, but on the bright side you wont get burned > trying to port, manage, and plug a new Morphic into Pharo. > > Fernando > > pd: It was so hard, i decided to start a new UI framework from the ground > up. > > > > > On Wed, Jan 2, 2013 at 7:52 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > >> Craig's NAIAD stands for "Name And Identity Are Distinct". Just >> thinking aloud -- because Morphic is so entrenched.. Could NAIAD or >> Colin's Environments allow Juan's Morphic (or, Morphic3) to co-exist >> with original Morphic, so that it would allow working on the port >> without depending on it for the tools? Once the port was complete, a >> sane migration could more easily occur.. >> >> >> On Wed, Jan 2, 2013 at 7:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 2 January 2013 12:55, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> >>>> Hello again Igor >>>> and Happy and Successful New "Pharo" Year 2013 >>>> >>>> >>> Thanks Hannes :) >>> Wish best to you in New Year too :) >>> >>> >>> >>>> --Hannes >>>> >>>> my notes are inserted below. >>>> >>>> >>>> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> On 24 December 2012 09:43, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>> >>>>>> Hello Igor >>>>>> >>>>>> Thank you for this interesting mail. An issue over 11 years old, see >>>>>> below. >>>>>> >>>>>> On 12/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> just wanna share some ideas about how we can cleanup morph a bit. >>>>>>> >>>>>> A bit? >>>>>> It will be a lot of effort. >>>>>> >>>>>> >>>>> We can do it in small steps. >>>>> >>>>> >>>>>> Squeak 4.4-12234 (current) >>>>>> >>>>>> Morph selectors size 1183 >>>>>> >>>>>> >>>>>> Pharo 2.0 (Beta) >>>>>> >>>>>> Morph selectors size 865 >>>>>> >>>>>> >>>>>> Cuis 4.1 (18th Dec 2012) >>>>>> >>>>>> Morph selectors size 343 >>>>>> >>>>>> >>>>>> This was an issue in 2001 >>>>>> >>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt >>>>>> >>>>>> see >>>>>> >>>>>> >>>>> I am not first day here, of course i am aware of this :) >>>>> >>>> Did you start working with Squeak already in 2001? >>>> >>>> >>> no. But i know this is a long standing issue :) >>> >>> >>>>>>> Layout.. bizarre. >>>>>>> >>>>>> Yes, see humorous contribution from June 2001 >>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt >>>>>> >>>>>> search for >>>>>> >>>>>> the Morph class has 924 methods >>>>>> >>>>>> in that mails >>>>>> >>>>>> There was an effort >>>>>> Morphic Cleanup Project >>>>>> >>>>>> http://wiki.squeak.org/squeak/3005 >>>>>> >>>>>> lead by >>>>>> >>>>>> Diego Gomez Deck >>>>>> >>>>>> It produced some results. But they did not reach far enough. >>>>>> >>>>>> >>>>> yes yes.. i know. >>>>> >>>>> >>>>>> However Juan Vuletic was successful in coming up with a simpler >>>>>> >> Morphic in >> >>>>>> Cuis. >>>>>> >>>>>> http://www.jvuletich.org/Cuis/Index.html >>>>>> >>>>>> >>>>> search this mailing list for Small Morphic. >>>>> It was an attempt to use Juan's work, which didn't fly. >>>>> >>>> Of course I am aware of SmallMorphic. If a first attempt at >>>> integrating SimpleMorphic into Pharo was not successful it does not >>>> necessarily mean that a second one has to be a failure again. >>>> >>>> Time spent on an analysis why it didn't fly is surely not a waste. >>>> >>>> For example another approach could be instead of copying code from >>>> Cuis and implanting it into Pharo "blob style" you could follow Juan >>>> Vuletich's refactoring steps incrementally and copy smaller chunks of >>>> code. Cuis had many releases until it reached version 4.1. >>>> >>>> In terms of factoring out classes from the class Morph you seem to >>>> want to do that anyway. >>>> >>>> See for example >>>> >>>> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html >>>> New in Cuis 2.7 (released September 3, 2010) >>>> >>>> * Morphic. New LayoutSpec mechanism. Simpler and nicer. >>>> * Morphic Simplification: Layout, Extensions, etc >>>> >>>> >>> Well, one thing is that Juan doing quite radical changes to code. >>> He is not concerned about backwards compatibility (but unlike from >>> >> Pharo, nobody >> >>> raising it as an issue over and over again ;) ). >>> Yes, i checked new Cuis code. >>> I see a lot of simplifications. But also i see reduced functionality. >>> For instance, i did not found things like 'fill style', and themes. >>> Also, i see some protocols is renamed, in preparation for something >>> bigger (morphic 3 i guess ;) >>> >>> So, i agree we should not copy/paste the code. Because it won't fly. >>> We should gradually analyze it and improve ours step by step. >>> >>> Layout code in Cuis is somewhat similar to what i proposing. >>> But my proposal is essentially about approach, which you can apply to >>> anything.. not just layouts in Morphics. >>> >>> >>>>>>> There are so many methods dedicated to laying out morphs that it easy >>>>>>> to get lost. >>>>>>> >>>>>> Cuis has a new layout system. >>>>>> >>>>>> Worth to check out. >>>>>> >>>>>> >>>>> Sure. >>>>> >>>> Fine. >>>> >>>> >>>>>>> For me the main mystery and source of confusion is that there >>>>>>> >> actually >> >>>>>>> two different groups: >>>>>>> >>>>>>> - methods to control morph's own layout (in respect to its parent) >>>>>>> - methods to control morph's children layout (something called >>>>>>> layoutPolicy) >>>>>>> >>>>>>> the problem is that both APIs are found in single class, >>>>>>> >>>>>> which one? >>>>>> >>>>>> >>>>> Morph >>>>> >>>>> >>>>>> and most of >>>>>> >>>>>>> them contain 'layout' word in it, >>>>>>> so it is really hard to determine which one to use and when.. >>>>>>> >>>>>>> Over a years, i seen that people learned how to use existing >>>>>>> functionality, without delving deep into >>>>>>> implementation detail. >>>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>>> But if you try to extend/change behavior (in your subclass), you will >>>>>>> quite soon find out that it is really >>>>>>> hard to tell with 100% certainty that the methods you override is the >>>>>>> right place for your customization. >>>>>>> >>>>>> Yes, this actually has made development very difficult. In such a way >>>>>> that most people have abandoned it. Very few GUIs are actually built >>>>>> with it. >>>>>> >>>>>> >>>>>> >>>>>>> Also, an important detail is extremely polluted protocol(s), making >>>>>>> Morph a GOD class, >>>>>>> >>>> Morph is at the root of a large subclasses tree. The question is: what >>>> can be pushed down or factored out. An analysis in terms of number of >>>> method candidates to move out would surely be a good thing to know. >>>> >>>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> > >

Jan. 8, 2013

Re: [Pharo-project] PluggableMultiColumnListMorph example?

by J. P. L. MartÃn

Sorry, magical hotkey pressed by mistake. On Tue, Jan 8, 2013 at 9:47 AM, J. P. L. MartÃn <arguser(a)gmail.com> wrote: > I point the list to an class instance "database" wich is > anOrderedCollection of Prestamo, you can see the code here: > https://github.com/arguser/Paradigmas-Final/blob/master/Paradigmas-Final.st > > If I leave wrap: item like this: ^ item asOrderedCollection collect [:e | > e asString] I get an OrderedCollection of OrderedCollection and items > display like: > a Prestamo fechaPrevistaDevolucion: value fechaPrestamo: value... etc. And I would like only the values to show.

Jan. 8, 2013

Re: [Pharo-project] PluggableMultiColumnListMorph example?

by J. P. L. MartÃn

I point the list to an class instance "database" wich is anOrderedCollection of Prestamo, you can see the code here: https://github.com/arguser/Paradigmas-Final/blob/master/Paradigmas-Final.st If I leave wrap: item like this: ^ item asOrderedCollection collect [:e | e asString On Tue, Jan 8, 2013 at 9:30 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > is your item a collection ?? > > Because it seems that the item you return is a "Prestamo" and that this > Prestamo doesn't understand the Collection methods > > Ben > > On Jan 8, 2013, at 1:26 PM, J. P. L. MartÃn wrote: > > I get an error when doing so: > > MessageNotUnderstood: Prestamo>>collect: > doesNotUnderstand: #collect: > MulticolumnLazyListMorph widthToDisplayItem: > > Leo > > > On Tue, Jan 8, 2013 at 9:09 AM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> if your item is already a collection, and you want a column per item, >> just return it >> >> wrap: item index: idx >> >> ^ item >> >> Ben >> >> On Jan 8, 2013, at 3:37 AM, J. P. L. MartÃn wrote: >> >> Ok, extent worked for size, so the wrap question remains active :P >> >> >> >> On Mon, Jan 7, 2013 at 11:35 PM, J. P. L. MartÃn <arguser(a)gmail.com>wrote: >> >>> If i have an OrderedCollection(a Prestamo id: '1' idMaterial: 'Book' >>> idSocio: 'User' fechaPrestamo: 7 January 2013 fechaPrevistaDevolucion: 10 >>> January 2013 fechaDevolucion: '') what would be a proper wrap for it if I >>> want a column for each part of the colection? Also, what was the method >>> that control size of the list? >>> >>> Thanks a lot! >>> >>> >>> On Thu, Jan 3, 2013 at 11:18 AM, Benjamin < >>> benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> >>>> Load the attached st file >>>> >>>> and execute the following snippet: >>>> >>>> (PluggableMultiColumnListMorph >>>> on: MyModelExample new >>>> list: #list >>>> selected: #selected >>>> changeSelected: #selected: >>>> menu: nil >>>> wrapSelector: #wrap:at:) openInWindow >>>> >>>> >>>> >>>> >>>> >>>> >>>> If you have questions, do not hesitate :) >>>> >>>> Ben >>>> >>>> On Jan 3, 2013, at 2:25 PM, J. P. L. MartÃn wrote: >>>> >>>> > Someone could give me a little example on >>>> PluggableMultiColumnListMorph? Does it work with OrderedCollections? >>>> > >>>> > Thanks in advance! >>>> >>>> >>>> >>> >> >> > >

Jan. 8, 2013

Re: [Pharo-project] PluggableMultiColumnListMorph example?

by Benjamin

is your item a collection ?? Because it seems that the item you return is a "Prestamo" and that this Prestamo doesn't understand the Collection methods Ben On Jan 8, 2013, at 1:26 PM, J. P. L. MartÃn wrote: > I get an error when doing so: > > MessageNotUnderstood: Prestamo>>collect: > doesNotUnderstand: #collect: > MulticolumnLazyListMorph widthToDisplayItem: > > Leo > > > On Tue, Jan 8, 2013 at 9:09 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > if your item is already a collection, and you want a column per item, just return it > > wrap: item index: idx > > ^ item > > Ben > > On Jan 8, 2013, at 3:37 AM, J. P. L. MartÃn wrote: > >> Ok, extent worked for size, so the wrap question remains active :P >> >> >> >> On Mon, Jan 7, 2013 at 11:35 PM, J. P. L. MartÃn <arguser(a)gmail.com> wrote: >> If i have an OrderedCollection(a Prestamo id: '1' idMaterial: 'Book' idSocio: 'User' fechaPrestamo: 7 January 2013 fechaPrevistaDevolucion: 10 January 2013 fechaDevolucion: '') what would be a proper wrap for it if I want a column for each part of the colection? Also, what was the method that control size of the list? >> >> Thanks a lot! >> >> >> On Thu, Jan 3, 2013 at 11:18 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Load the attached st file >> >> and execute the following snippet: >> >> (PluggableMultiColumnListMorph >> on: MyModelExample new >> list: #list >> selected: #selected >> changeSelected: #selected: >> menu: nil >> wrapSelector: #wrap:at:) openInWindow >> >> >> >> >> >> >> If you have questions, do not hesitate :) >> >> Ben >> >> On Jan 3, 2013, at 2:25 PM, J. P. L. MartÃn wrote: >> >> > Someone could give me a little example on PluggableMultiColumnListMorph? Does it work with OrderedCollections? >> > >> > Thanks in advance! >> >> >> >> > >

Jan. 8, 2013

Re: [Pharo-project] PluggableMultiColumnListMorph example?

by J. P. L. MartÃn

I get an error when doing so: MessageNotUnderstood: Prestamo>>collect: doesNotUnderstand: #collect: MulticolumnLazyListMorph widthToDisplayItem: Leo On Tue, Jan 8, 2013 at 9:09 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > if your item is already a collection, and you want a column per item, just > return it > > wrap: item index: idx > > ^ item > > Ben > > On Jan 8, 2013, at 3:37 AM, J. P. L. MartÃn wrote: > > Ok, extent worked for size, so the wrap question remains active :P > > > > On Mon, Jan 7, 2013 at 11:35 PM, J. P. L. MartÃn <arguser(a)gmail.com>wrote: > >> If i have an OrderedCollection(a Prestamo id: '1' idMaterial: 'Book' >> idSocio: 'User' fechaPrestamo: 7 January 2013 fechaPrevistaDevolucion: 10 >> January 2013 fechaDevolucion: '') what would be a proper wrap for it if I >> want a column for each part of the colection? Also, what was the method >> that control size of the list? >> >> Thanks a lot! >> >> >> On Thu, Jan 3, 2013 at 11:18 AM, Benjamin < >> benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> Load the attached st file >>> >>> and execute the following snippet: >>> >>> (PluggableMultiColumnListMorph >>> on: MyModelExample new >>> list: #list >>> selected: #selected >>> changeSelected: #selected: >>> menu: nil >>> wrapSelector: #wrap:at:) openInWindow >>> >>> >>> >>> >>> >>> >>> If you have questions, do not hesitate :) >>> >>> Ben >>> >>> On Jan 3, 2013, at 2:25 PM, J. P. L. MartÃn wrote: >>> >>> > Someone could give me a little example on >>> PluggableMultiColumnListMorph? Does it work with OrderedCollections? >>> > >>> > Thanks in advance! >>> >>> >>> >> > >

Jan. 8, 2013