- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Spec news

by StÃ©phane Ducasse

I will check. May be this evening. We transformed systematically defaultSpec ^ { #ComposableSpec. #add:. { self topSpec. #layout:. {#LayoutFrame. #fractions:offsets:. (0@0 corner: 1@0). (0@0 corner: 0@20). }}. #add:. {{#model. #container.}. #layout:. {#LayoutFrame. #fractions:offsets:. (0@0 corner: 1@1). (0@22 corner: 0@0). }}} into defaultSpec ^ { #ComposableSpec. #add:. { self topSpec. #layout:. #(0 0 1 0 0 0 0 20) }. #add:. {{#model . #container } . #layout: . #(0 0 1 1 0 22 0 0) } } So I do not see why this is different from what we did. Stef > It does in plugin specs, for example > > defaultSpec > > ^{ #ComposableSpec. > #vResizing:. #shrinkWrap. > #add:. {{self. #textModel}. > #layout:. #(0 0 1 1 0 0 0 0)}. > } > > -- Pavel > > On Tue, Jan 8, 2013 at 3:59 PM, Benjamin > <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> 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] FileSystem inconsistency

by Ben Coman

Jimmie Houchin wrote: > Hello, > > I was writing a small utility using FileSystem. I had never used > FileSystem before. So I am browsing the code trying to learn where to > start and how to use it. > > It took me a little while to learn to do something like: > fs := FileSystem store: (DiskStore activeClass createDefault). > > It would be nice if there were an instance creation method like > FileSystem createDefault which would do the above. > > My utility was renaming some files. Once I had acquired a > FileSystemDirectoryEntry instance I needed to examine the name. > > I see #basename and #fullName. As I browse other classes I see > #childNamesAt: and #pathName, etc. > > I was just curious why #basename and not #baseName? > > Thanks. > > Jimmie > > Perhaps wide use of 'basename' as a single word has been previously established ? http://en.wikipedia.org/wiki/Basename

Jan. 8, 2013

Re: [Pharo-project] Spec news

by StÃ©phane Ducasse

>> 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 ? because we want to deprecate the use of fractions:offsets: So if you do not have fractions:offsets: then you should find a way (for spec) to create a layout. So we introduce a literal format and below the scene we are using a layoutFrame. > 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

[Pharo-project] FileSystem inconsistency

by Jimmie Houchin

Hello, I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it. It took me a little while to learn to do something like: fs := FileSystem store: (DiskStore activeClass createDefault). It would be nice if there were an instance creation method like FileSystem createDefault which would do the above. My utility was renaming some files. Once I had acquired a FileSystemDirectoryEntry instance I needed to examine the name. I see #basename and #fullName. As I browse other classes I see #childNamesAt: and #pathName, etc. I was just curious why #basename and not #baseName? Thanks. Jimmie

Jan. 8, 2013

Re: [Pharo-project] Spec news

by Benjamin

it seems that #layout is expecting a LayoutFrame as argument. But since I do not know what Stef and Igor changed (and what they didn't fix ^^) I can't tell more than that :s And I do not have too much time right now, sorry Ben On Jan 8, 2013, at 4:05 PM, Pavel Krivanek wrote: > It does in plugin specs, for example > > defaultSpec > > ^{ #ComposableSpec. > #vResizing:. #shrinkWrap. > #add:. {{self. #textModel}. > #layout:. #(0 0 1 1 0 0 0 0)}. > } > > -- Pavel > > On Tue, Jan 8, 2013 at 3:59 PM, Benjamin > <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> 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

It does in plugin specs, for example defaultSpec ^{ #ComposableSpec. #vResizing:. #shrinkWrap. #add:. {{self. #textModel}. #layout:. #(0 0 1 1 0 0 0 0)}. } -- Pavel On Tue, Jan 8, 2013 at 3:59 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > 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 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