[Pharo-project] Canvas repackaging (WAS: Re: [update 2.0] #20404)
On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker@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
On Sun, Nov 18, 2012 at 8:34 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker@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
http://code.google.com/p/pharo/issues/detail?id=6998 -- Pavel
participants (1)
-
Pavel Krivanek