>> On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.den...@inria.fr> >> wrote: >>> 20404 >>> ----- >>> >>> Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic >>> http://code.google.com/p/pharo/issues/detail?id=6994 >> >> This fix has very interesting consequence when loading Morphic. >> Because when the Morphic package is loaded, it firstly loads >> Form>>#defaultCanvasClass that calls "Display defaultCanvasClass". But >> Display is a Form too so before the DisplayScreen implementation >> (^FormCanvas) is loaded too, it can lead and leads to infinite >> recursion. >> > I actually wonder if we need all the indirection (defaultCanvasClass and > friends). > > I looked at the senders, and it is not used everywhere... Canvas sometimes is > rerenced > directly, sometimes not. > > In addition, Canvas should not be in Morpic but there should be a Canvas > package that > Morphic *uses* but that is completely independend of Morphic. > > Marcus
Does it make sense to create two packages. One for abstract Canvas and second for Form-based Canvas classes? The current (abstract) Canvas implementation seems to be messed with direct Forms support too. Can for example someone from Athens tell something to this topic? However because of atomic loading the repackaging of Canvas classes may not solve this issue and we need to return FormCanvas in Form>>defaultCanvasClass directly. -- Pavel
