This is now fixed by update 1361viewerConflicts-sw, which also fixes five or six related glitches which all derived from similar collisions of slot-definitions for Viewers, as specified in class- side #addiltionsToViewerCategoryxxx methods.
The formerly conflicting slot definitions that are cleaned up by this update are:
cursor -- conflicts among TextMorph, NCLabelMorph, PasteUpMorph, FlashPlayerMorph, GraphMorph
graphic -- conflicts among SketchMorph, VideoMorph, PasteUpMorph
Thanks again for the bug report, Dan. It's good to get these glitches sorted out.
Cheers,
-- Scott
On Jun 11, 2007, at 12:03 PM, Scott Wallace wrote:
I tracked this down and discovered that the problem arrived with update 1233VideoForSq-fixes2-dgd.
The cause is that update 1233 provides an #additionsToViewerCategories method containing among other things an override for the #graphic slot for VideoMorph, which (appropriately) declares the #graphic slot to be read-only.
However -- and I believe we encountered this once before in a different context in recent months -- the MethodInterfaces in the etoy vocabulary are not bound to a particular class but rather only to a selector; thus, the new declaration for the #graphic slot in Diego' fileout clobbered the #graphic entry previously present, in which #graphic was a read/write slot, and replaced it with the entry provided for VideoMorph which declares #graphic to be read- only...
So, in short, we have a problem whenever the #additionsToViewerCategories declarations in two different classes declare the same slot-name with conflicting details.
Let's discuss what to do about this during our conference call this afternoon...
Cheers,
-- Scott
On Jun 11, 2007, at 8:54 AM, Heywood, Daniel Feaster wrote:
Hi Scott,
I just recently noticed that one is not able to make an assignment to a Sketch's graphic in the OLPC image; the base graphic is assignable but the graphic is not. In the Plugin image a Sketch does have the capability to make an assignment to its graphic--not sure if this is a bug or another matter of a preference setting?
--Dan Heywood
However update 1361 had a couple of flaws, which are fixed by update 1364viewerRepairs-sw, so please be certain to load further updates!
Cheers,
-- Scott
On Jun 12, 2007, at 2:43 AM, Scott Wallace wrote:
This is now fixed by update 1361viewerConflicts-sw, which also fixes five or six related glitches which all derived from similar collisions of slot-definitions for Viewers, as specified in class- side #addiltionsToViewerCategoryxxx methods.
The formerly conflicting slot definitions that are cleaned up by this update are:
cursor -- conflicts among TextMorph, NCLabelMorph, PasteUpMorph, FlashPlayerMorph, GraphMorph
graphic -- conflicts among SketchMorph, VideoMorph, PasteUpMorph
Thanks again for the bug report, Dan. It's good to get these glitches sorted out.
Cheers,
-- Scott
On Jun 11, 2007, at 12:03 PM, Scott Wallace wrote:
I tracked this down and discovered that the problem arrived with update 1233VideoForSq-fixes2-dgd.
The cause is that update 1233 provides an #additionsToViewerCategories method containing among other things an override for the #graphic slot for VideoMorph, which (appropriately) declares the #graphic slot to be read-only.
However -- and I believe we encountered this once before in a different context in recent months -- the MethodInterfaces in the etoy vocabulary are not bound to a particular class but rather only to a selector; thus, the new declaration for the #graphic slot in Diego' fileout clobbered the #graphic entry previously present, in which #graphic was a read/write slot, and replaced it with the entry provided for VideoMorph which declares #graphic to be read- only...
So, in short, we have a problem whenever the #additionsToViewerCategories declarations in two different classes declare the same slot-name with conflicting details.
Let's discuss what to do about this during our conference call this afternoon...
Cheers,
-- Scott
On Jun 11, 2007, at 8:54 AM, Heywood, Daniel Feaster wrote:
Hi Scott,
I just recently noticed that one is not able to make an assignment to a Sketch's graphic in the OLPC image; the base graphic is assignable but the graphic is not. In the Plugin image a Sketch does have the capability to make an assignment to its graphic--not sure if this is a bug or another matter of a preference setting?
--Dan Heywood
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
etoys-dev@lists.squeakfoundation.org