About morph layout
Locked
 
|
Hi,
just wanna share some ideas about how we can cleanup morph a bit. Layout.. bizarre. There are so many methods dedicated to laying out morphs that it easy to get lost. 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, 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. 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. Also, an important detail is extremely polluted protocol(s), making Morph a GOD class, with so many functions that it is unbearable. So, what i want to propose is same as i proposed to introduce for "SmalltalkImage" is to use "scoping" accessors , or "delegate" accessor to get access to part of functionality with clear context. Remember: Smalltalk vm version Smalltalk tools browser so, lets see how code might look like if we apply same approach to morph protocols: Example. Original: column := AlignmentMorph newColumn vResizing: #shrinkWrap; hResizing: #shrinkWrap; layoutInset: 1; borderColor: Color black; borderWidth: 0; wrapCentering: #center; cellPositioning: #center; color: Color white; yourself. Change: column := AlignmentMorph newColumn. column color: Color white. column layout shrinkWrap. "v and h both" column border width: 0; color: Color black. column childLayout inset: 1; wrapCentering: #center; cellPositioning: #center. Cons: - a code is a bit more elaborate. That because, of course, we cannot merge everything into single cascade. Pros: - from code it is clear, which properties belong to which parts of functionality. You cannot confuse, for instance, whether 'wrapCentering' property controls morph's own layout or a layout of its children - most important, we can considerably shrink Morph's protocol by removing all direct accessors and instead put them into delegated behaviors. More than that, a delegates don't need to be a dummy state holders (like most of properties are now), but actually an object(s) which conform to certain protocol.. For instance, if we have a 'border' as a delegate, and morph wants to draw it, it could just tell: MyMorph>>drawOn: aCanvas self border drawOn: aCanvas btw, then it is actually makes sense having a BorderedMorph subclass, which a) introduces 'border' delegate b) cares to draw its border in contrast to Morph who shouldn't. As well as in case of layouts, you can tell: morph layout changed. or morph childLayout layOutChildren. etc. -- Best regards, Igor Stasenko. |
|
|
Hello Igor
Thank you for this interesting mail. An issue over 11 years old, see below. On 12/24/12, Igor Stasenko <[hidden email]> wrote: > Hi, > > just wanna share some ideas about how we can cleanup morph a bit. A bit? It will be a lot of effort. 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 > 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. However Juan Vuletic was successful in coming up with a simpler Morphic in Cuis. http://www.jvuletich.org/Cuis/Index.html > 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. > 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? 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, > with so many functions that it is unbearable. > So, what i want to propose is same as i proposed to introduce for > "SmalltalkImage" > is to use "scoping" accessors , or "delegate" accessor to get access > to part of functionality > with clear context. Surely a good intermediary step. > Remember: > Smalltalk vm version > Smalltalk tools browser > > so, lets see how code might look like if we apply same approach to > morph protocols: > > Example. > Original: > > column := AlignmentMorph newColumn vResizing: #shrinkWrap; > hResizing: #shrinkWrap; > layoutInset: 1; > borderColor: Color black; > borderWidth: 0; > wrapCentering: #center; > cellPositioning: #center; > color: Color white; > yourself. > > Change: > > column := AlignmentMorph newColumn. > > column color: Color white. > column layout shrinkWrap. "v and h both" > > column border > width: 0; > color: Color black. > > column childLayout > inset: 1; > wrapCentering: #center; > cellPositioning: #center. > > Cons: > - a code is a bit more elaborate. That because, of course, we cannot > merge everything into single cascade. > > Pros: > - from code it is clear, which properties belong to which parts of > functionality. You cannot confuse, for instance, whether > 'wrapCentering' > property controls morph's own layout or a layout of its children > - most important, we can considerably shrink Morph's protocol by > removing all direct accessors and instead put them into delegated > behaviors. > > More than that, a delegates don't need to be a dummy state holders > (like most of properties are now), but actually an object(s) which > conform to certain protocol.. > > For instance, if we have a 'border' as a delegate, and morph wants to > draw it, it could just tell: > > MyMorph>>drawOn: aCanvas > self border drawOn: aCanvas > > btw, then it is actually makes sense having a BorderedMorph subclass, which > a) introduces 'border' delegate > b) cares to draw its border > in contrast to Morph who shouldn't. > > As well as in case of layouts, you can tell: > > morph layout changed. > > or > > morph childLayout layOutChildren. > > etc. > > I can't comment more at the approach at the moment. Could you elaborate it a bit more? As the leading example of Juan Vuletich shows it is possible to reduce the complexity of Morphic. It would be good to check out what he has written about his work. Best regards Hannes Hirzel > -- > Best regards, > Igor Stasenko. > > |
|
|
Hannes
this is exactly for these reasons that we started Pharo. We want to have a clean and powerful system. Now in addition we want to make sure that people can make business with it. And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable in 1980 that are now possible. Now I think that Pharo delivers. We will continue. Stef |
Re: About morph layout
|
|
On 24 Dec 2012, at 11:20, Stéphane Ducasse <[hidden email]> wrote:
> Hannes > > this is exactly for these reasons that we started Pharo. We want to have a clean and powerful system. > Now in addition we want to make sure that people can make business with it. > And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable > in 1980 that are now possible. +10 > Now I think that Pharo delivers. We will continue. +100 Very well said, quotable material ! > Stef Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
|
|
> And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable > in 1980 that are now possible. What does this mean ? You mean that the solution to the GUI should be web based (Js / Html5) ? |
|
|
On Dec 24, 2012, at 12:16 PM, dimitris chloupis wrote: > > > > And our goal is not just to be Smalltalk because there are probably design decisions that were not suitable > > in 1980 that are now possible. > > What does this mean ? You mean that the solution to the GUI should be web based (Js / Html5) ? it means nothing special. Just do it. You know a keyboard and a man. Or a group of programmers that want to get something done. So I will not continue to talk because I want to keep my time to hack. Sorry but pair programming is too fun and I have some legos to build before igor show up Stef |
|
|
In reply to this post by kilon
maybe - but with the Seaside web framework this was put to action. See
Seaside weeb page. And there is a initial release of a follow up web framework to Seaside called 'Altitude'. See Squeak mailing list. And have a look at how the GUI in Cuis 4.1 is constructed. Pharo has the 'Glamour' browser construction framework. It is very well documented and put to use in the 'Moose' image. HTH to give some things to try out. --Hannes Pharo was and still is positioned as a Smalltalk IDE and a server side tool. On 12/24/12, dimitris chloupis <[hidden email]> wrote: > > > >> And our goal is not just to be Smalltalk because there are probably design >> decisions that were not suitable >> in 1980 that are now possible. > > What does this mean ? You mean that the solution to the GUI should be web > based (Js / Html5) ? > |
|
|
In reply to this post by Hannes Hirzel
On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote:
> Hello Igor > > Thank you for this interesting mail. An issue over 11 years old, see below. > > On 12/24/12, Igor Stasenko <[hidden email]> wrote: >> Hi, >> >> just wanna share some ideas about how we can cleanup morph a bit. > > A bit? > It will be a lot of effort. > > 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 > >> 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. > > 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. >> 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. >> 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? > > 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, >> with so many functions that it is unbearable. > > > >> So, what i want to propose is same as i proposed to introduce for >> "SmalltalkImage" >> is to use "scoping" accessors , or "delegate" accessor to get access >> to part of functionality >> with clear context. > > Surely a good intermediary step. > >> Remember: >> Smalltalk vm version >> Smalltalk tools browser >> >> so, lets see how code might look like if we apply same approach to >> morph protocols: >> >> Example. >> Original: >> >> column := AlignmentMorph newColumn vResizing: #shrinkWrap; >> hResizing: #shrinkWrap; >> layoutInset: 1; >> borderColor: Color black; >> borderWidth: 0; >> wrapCentering: #center; >> cellPositioning: #center; >> color: Color white; >> yourself. >> >> Change: >> >> column := AlignmentMorph newColumn. >> >> column color: Color white. >> column layout shrinkWrap. "v and h both" >> >> column border >> width: 0; >> color: Color black. >> >> column childLayout >> inset: 1; >> wrapCentering: #center; >> cellPositioning: #center. >> >> Cons: >> - a code is a bit more elaborate. That because, of course, we cannot >> merge everything into single cascade. >> >> Pros: >> - from code it is clear, which properties belong to which parts of >> functionality. You cannot confuse, for instance, whether >> 'wrapCentering' >> property controls morph's own layout or a layout of its children >> - most important, we can considerably shrink Morph's protocol by >> removing all direct accessors and instead put them into delegated >> behaviors. >> >> More than that, a delegates don't need to be a dummy state holders >> (like most of properties are now), but actually an object(s) which >> conform to certain protocol.. >> >> For instance, if we have a 'border' as a delegate, and morph wants to >> draw it, it could just tell: >> >> MyMorph>>drawOn: aCanvas >> self border drawOn: aCanvas >> >> btw, then it is actually makes sense having a BorderedMorph subclass, which >> a) introduces 'border' delegate >> b) cares to draw its border >> in contrast to Morph who shouldn't. >> >> As well as in case of layouts, you can tell: >> >> morph layout changed. >> >> or >> >> morph childLayout layOutChildren. >> >> etc. >> >> > > I can't comment more at the approach at the moment. Could you > elaborate it a bit more? > > As the leading example of Juan Vuletich shows it is possible to > reduce the complexity of Morphic. It would be good to check out what > he has written about his work. > I am sure that things i proposing not found in Cuis. > > Best regards > Hannes Hirzel > -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Igor Stasenko
I like this decomposition of a large interface into separate objects.
Stef > > column := AlignmentMorph newColumn. > > column color: Color white. > column layout shrinkWrap. "v and h both" > > column border > width: 0; > color: Color black. > > column childLayout > inset: 1; > wrapCentering: #center; > cellPositioning: #center. > > Cons: > - a code is a bit more elaborate. That because, of course, we cannot > merge everything into single cascade. > > Pros: > - from code it is clear, which properties belong to which parts of > functionality. You cannot confuse, for instance, whether > 'wrapCentering' > property controls morph's own layout or a layout of its children > - most important, we can considerably shrink Morph's protocol by > removing all direct accessors and instead put them into delegated > behaviors. > > More than that, a delegates don't need to be a dummy state holders > (like most of properties are now), but actually an object(s) which > conform to certain protocol.. > > For instance, if we have a 'border' as a delegate, and morph wants to > draw it, it could just tell: > > MyMorph>>drawOn: aCanvas > self border drawOn: aCanvas > > btw, then it is actually makes sense having a BorderedMorph subclass, which > a) introduces 'border' delegate > b) cares to draw its border > in contrast to Morph who shouldn't. > > As well as in case of layouts, you can tell: > > morph layout changed. > > or > > morph childLayout layOutChildren. > > etc. > > > -- > Best regards, > Igor Stasenko. > |
Re: About morph layout
|
|
On 25.12.2012 18:34, Stéphane Ducasse wrote:
> I like this decomposition of a large interface into separate objects. > > Stef Smells like progress to me too! Cheers, Henry |
|
|
In reply to this post by Igor Stasenko
Hello again Igor
and Happy and Successful New "Pharo" Year 2013 --Hannes my notes are inserted below. On 12/24/12, Igor Stasenko <[hidden email]> wrote: > On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote: >> Hello Igor >> >> Thank you for this interesting mail. An issue over 11 years old, see >> below. >> >> On 12/24/12, Igor Stasenko <[hidden email]> 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? >>> 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 >>> 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. >>> with so many functions that it is unbearable. >> >> >> >>> So, what i want to propose is same as i proposed to introduce for >>> "SmalltalkImage" >>> is to use "scoping" accessors , or "delegate" accessor to get access >>> to part of functionality >>> with clear context. >> >> Surely a good intermediary step. >> >>> Remember: >>> Smalltalk vm version >>> Smalltalk tools browser >>> >>> so, lets see how code might look like if we apply same approach to >>> morph protocols: >>> >>> Example. >>> Original: >>> >>> column := AlignmentMorph newColumn vResizing: #shrinkWrap; >>> hResizing: #shrinkWrap; >>> layoutInset: 1; >>> borderColor: Color black; >>> borderWidth: 0; >>> wrapCentering: #center; >>> cellPositioning: #center; >>> color: Color white; >>> yourself. >>> >>> Change: >>> >>> column := AlignmentMorph newColumn. >>> >>> column color: Color white. >>> column layout shrinkWrap. "v and h both" >>> >>> column border >>> width: 0; >>> color: Color black. >>> >>> column childLayout >>> inset: 1; >>> wrapCentering: #center; >>> cellPositioning: #center. >>> >>> Cons: >>> - a code is a bit more elaborate. That because, of course, we cannot >>> merge everything into single cascade. >>> >>> Pros: >>> - from code it is clear, which properties belong to which parts of >>> functionality. You cannot confuse, for instance, whether >>> 'wrapCentering' >>> property controls morph's own layout or a layout of its children >>> - most important, we can considerably shrink Morph's protocol by >>> removing all direct accessors and instead put them into delegated >>> behaviors. >>> >>> More than that, a delegates don't need to be a dummy state holders >>> (like most of properties are now), but actually an object(s) which >>> conform to certain protocol.. >>> >>> For instance, if we have a 'border' as a delegate, and morph wants to >>> draw it, it could just tell: >>> >>> MyMorph>>drawOn: aCanvas >>> self border drawOn: aCanvas >>> >>> btw, then it is actually makes sense having a BorderedMorph subclass, >>> which >>> a) introduces 'border' delegate >>> b) cares to draw its border >>> in contrast to Morph who shouldn't. >>> >>> As well as in case of layouts, you can tell: >>> >>> morph layout changed. >>> >>> or >>> >>> morph childLayout layOutChildren. >>> >>> etc. >>> >>> >> >> I can't comment more at the approach at the moment. Could you >> elaborate it a bit more? >> > mm.. can you tell, what is not clear to you? > >> As the leading example of Juan Vuletich shows it is possible to >> reduce the complexity of Morphic. It would be good to check out what >> he has written about his work. >> > I am sure that things i proposing not found in Cuis. > >> >> Best regards >> Hannes Hirzel >> > > > -- > Best regards, > Igor Stasenko. > > |
|
|
On 2 January 2013 12:55, H. Hirzel <[hidden email]> 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 <[hidden email]> wrote: >> On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote: >>> Hello Igor >>> >>> Thank you for this interesting mail. An issue over 11 years old, see >>> below. >>> >>> On 12/24/12, Igor Stasenko <[hidden email]> 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? > >>>> 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. |
|
|
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 <[hidden email]> wrote: > On 2 January 2013 12:55, H. Hirzel <[hidden email]> 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 <[hidden email]> wrote: >>> On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote: >>>> Hello Igor >>>> >>>> Thank you for this interesting mail. An issue over 11 years old, see >>>> below. >>>> >>>> On 12/24/12, Igor Stasenko <[hidden email]> 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. > |
|
|
In reply to this post by Igor Stasenko
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 <[hidden email]> wrote: Craig's NAIAD stands for "Name And Identity Are Distinct". Just |
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: >> >>> On 2 January 2013 12:55, H. Hirzel <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>>> On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote: >>>>> >>>>>> Hello Igor >>>>>> >>>>>> Thank you for this interesting mail. An issue over 11 years old, see >>>>>> below. >>>>>> >>>>>> On 12/24/12, Igor Stasenko <[hidden email]> 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. >>> >>> >> > > |
|
|
On 8 January 2013 14:04, Ben Coman <[hidden email]> 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. > 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 <[hidden email]> 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 <[hidden email]> wrote: >>> >>>> >>>> On 2 January 2013 12:55, H. Hirzel <[hidden email]> 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 <[hidden email]> wrote: >>>>> >>>>>> >>>>>> On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote: >>>>>> >>>>>>> >>>>>>> Hello Igor >>>>>>> >>>>>>> Thank you for this interesting mail. An issue over 11 years old, see >>>>>>> below. >>>>>>> >>>>>>> On 12/24/12, Igor Stasenko <[hidden email]> 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. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |