The Inbox: Graphics-cmm.329.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Graphics-cmm.329.mcz

commits-2
A new version of Graphics was added to project The Inbox:
http://source.squeak.org/inbox/Graphics-cmm.329.mcz

==================== Summary ====================

Name: Graphics-cmm.329
Author: cmm
Time: 31 March 2016, 2:43:44.434481 pm
UUID: a7a78301-477c-40ea-b010-c4e71c02a038
Ancestors: Graphics-tfel.328

Fix the green clone halo morph for SketchMorphs to not share its underlying Form.

=============== Diff against Graphics-tfel.328 ===============

Item was removed:
- ----- Method: Form>>veryDeepCopyWith: (in category 'copying') -----
- veryDeepCopyWith: deepCopier
- "Return self.  I am immutable in the Morphic world.  Do not record me."
- ^ self!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Tobias Pape

On 31.03.2016, at 19:43, [hidden email] wrote:

> A new version of Graphics was added to project The Inbox:
> http://source.squeak.org/inbox/Graphics-cmm.329.mcz
>
> ==================== Summary ====================
>
> Name: Graphics-cmm.329
> Author: cmm
> Time: 31 March 2016, 2:43:44.434481 pm
> UUID: a7a78301-477c-40ea-b010-c4e71c02a038
> Ancestors: Graphics-tfel.328
>
> Fix the green clone halo morph for SketchMorphs to not share its underlying Form.
>
> =============== Diff against Graphics-tfel.328 ===============
>
> Item was removed:
> - ----- Method: Form>>veryDeepCopyWith: (in category 'copying') -----
> - veryDeepCopyWith: deepCopier
> - "Return self.  I am immutable in the Morphic world.  Do not record me."
> - ^ self!
>

I'm a bit curious how this quite broad change is only affecting the quite narrow
use case of green clone halo of SketchMorphs. Care to explain?

Best
        -Tobias
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Bert Freudenberg
In reply to this post by commits-2

> On 31.03.2016, at 19:43, [hidden email] wrote:
>
> A new version of Graphics was added to project The Inbox:
> http://source.squeak.org/inbox/Graphics-cmm.329.mcz
>
> ==================== Summary ====================
>
> Name: Graphics-cmm.329
> Author: cmm
> Time: 31 March 2016, 2:43:44.434481 pm
> UUID: a7a78301-477c-40ea-b010-c4e71c02a038
> Ancestors: Graphics-tfel.328
>
> Fix the green clone halo morph for SketchMorphs to not share its underlying Form.
Err. The clone handle is *supposed to* not duplicate the form. This is used a lot in Etoys. You can have many players sharing the same bitmap costume. We do *not* want to waste memory duplicating the form.

While editing the sketch, we work on a copy of the form (to support canceling). If accepting the painting, *then* we set it to the new form.

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Chris Muller-3
Okay, that's why this is in the Inbox.  I started to formulate my
question in long words in email, but decided this was the quickest and
easiest way to ask it.  :)

Okay, so this is definitely not the place to fix my problem.  So I
will instead try putting something into SketchMorph's veryDeepFixup:
which will ensure its underlying form gets copied when I green-halo a
SketchMorph.  SketchMorph is an exception because he's a dumb data
object, not a "player" who wants to share a costume.

  -- I was working on an icon, writing scripts to change colors
pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
green halo, only to find I corrupted my original, as well.  Some work
lost.

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

marcel.taeumel
We should use real morphs as halo handles, not only forms. Then we can define/adjust that deep-copy operation there.

Nevertheless, Chris is right that the override of #veryDeepCopyWith: in Form outside any Morphic extension category is quite smelly. Deep copying is not Morphic-specific.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Karl Ramberg
You can hold shift while dragging the green handle to change it's copying behavior. One makes a sibling, so they share the same form. One makes a copy of the morph and form.

Best,
Karl

On Fri, Apr 1, 2016 at 9:43 AM, marcel.taeumel <[hidden email]> wrote:
We should use real morphs as halo handles, not only forms. Then we can
define/adjust that deep-copy operation there.

Nevertheless, Chris is right that the override of #veryDeepCopyWith: in Form
outside any Morphic extension category is quite smelly. Deep copying is not
Morphic-specific.

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Inbox-Graphics-cmm-329-mcz-tp4887677p4887736.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Bert Freudenberg
On 01.04.2016, at 14:33, karl ramberg <[hidden email]> wrote:

You can hold shift while dragging the green handle to change it's copying behavior. One makes a sibling, so they share the same form. One makes a copy of the morph and form.

Not true. Both make a copy of the morph, both do *not* copy the form.

The only difference is that the morph’s player’s class is the same for siblings, but unique for copies. Hence, scripts (methods) are shared between siblings, but independent for copies.

- Bert -

On Fri, Apr 1, 2016 at 9:43 AM, marcel.taeumel <[hidden email]> wrote:
We should use real morphs as halo handles, not only forms. Then we can
define/adjust that deep-copy operation there.

Nevertheless, Chris is right that the override of #veryDeepCopyWith: in Form
outside any Morphic extension category is quite smelly. Deep copying is not
Morphic-specific.

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Inbox-Graphics-cmm-329-mcz-tp4887677p4887736.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.









smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Bert Freudenberg
In reply to this post by Chris Muller-3
On 01.04.2016, at 01:41, Chris Muller <[hidden email]> wrote:

>
> Okay, that's why this is in the Inbox.  I started to formulate my
> question in long words in email, but decided this was the quickest and
> easiest way to ask it.  :)
>
> Okay, so this is definitely not the place to fix my problem.  So I
> will instead try putting something into SketchMorph's veryDeepFixup:
> which will ensure its underlying form gets copied when I green-halo a
> SketchMorph.  SketchMorph is an exception because he's a dumb data
> object, not a "player" who wants to share a costume.
SketchMorph is the single most-used user object in Etoys :)

> -- I was working on an icon, writing scripts to change colors
> pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
> green halo, only to find I corrupted my original, as well.  Some work
> lost.

I’m sorry you lost time. Nevertheless, the originalForm in SketchMorph is designed to be shared.

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Chris Muller-3
Really?  That's really surprising; SketchMorph is just a dumb data
object, a painting, making a copy of it via the UI is a valid
use-case.  For every other kind of Morph, the green halo makes a deep
copy, SketchMorph is inconsistent, shouldn't Etoys simply override
that halo to call its own #semiDeepCopy to suit its own purposes?

Is Etoys running in trunk?  It is not targeted for trunk though, is it?

I want to be able to make easy copies of SketchMorph's.  Surely we can
come up with some solution; what about Karl's suggestion?   I think
Shift should be the sharing, because the "modifer" keys are used to
"modify" the standard behavior, which is a true veryDeepCopy..


On Fri, Apr 1, 2016 at 8:45 AM, Bert Freudenberg <[hidden email]> wrote:

> On 01.04.2016, at 01:41, Chris Muller <[hidden email]> wrote:
>>
>> Okay, that's why this is in the Inbox.  I started to formulate my
>> question in long words in email, but decided this was the quickest and
>> easiest way to ask it.  :)
>>
>> Okay, so this is definitely not the place to fix my problem.  So I
>> will instead try putting something into SketchMorph's veryDeepFixup:
>> which will ensure its underlying form gets copied when I green-halo a
>> SketchMorph.  SketchMorph is an exception because he's a dumb data
>> object, not a "player" who wants to share a costume.
>
> SketchMorph is the single most-used user object in Etoys :)
>
>> -- I was working on an icon, writing scripts to change colors
>> pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
>> green halo, only to find I corrupted my original, as well.  Some work
>> lost.
>
> I’m sorry you lost time. Nevertheless, the originalForm in SketchMorph is designed to be shared.
>
> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

David T. Lewis
Yes of course Etoys should work in trunk!

It would be really good if some members of the squeak-dev community could
take an interest in this, and maybe make a project out of doing whatever
updates may be needed to clean up trunk in this regard. The Etoys image
itself provides a clear reference of how things should work, and I'm sure
that Bert and others would be happy to offer some guidance and oversight
to anyone who might want to contribute.

Personally I think it would be very cool if you could open a new trunk
image, start a new project, and be able to select Morphic, MVC, or Etoys
as types of project. Then entering a new Etoys project could take you
directly into an environment just like that of the reference Etoys image.

Dave

> Really?  That's really surprising; SketchMorph is just a dumb data
> object, a painting, making a copy of it via the UI is a valid
> use-case.  For every other kind of Morph, the green halo makes a deep
> copy, SketchMorph is inconsistent, shouldn't Etoys simply override
> that halo to call its own #semiDeepCopy to suit its own purposes?
>
> Is Etoys running in trunk?  It is not targeted for trunk though, is it?
>
> I want to be able to make easy copies of SketchMorph's.  Surely we can
> come up with some solution; what about Karl's suggestion?   I think
> Shift should be the sharing, because the "modifer" keys are used to
> "modify" the standard behavior, which is a true veryDeepCopy..
>
>
> On Fri, Apr 1, 2016 at 8:45 AM, Bert Freudenberg <[hidden email]>
> wrote:
>> On 01.04.2016, at 01:41, Chris Muller <[hidden email]> wrote:
>>>
>>> Okay, that's why this is in the Inbox.  I started to formulate my
>>> question in long words in email, but decided this was the quickest and
>>> easiest way to ask it.  :)
>>>
>>> Okay, so this is definitely not the place to fix my problem.  So I
>>> will instead try putting something into SketchMorph's veryDeepFixup:
>>> which will ensure its underlying form gets copied when I green-halo a
>>> SketchMorph.  SketchMorph is an exception because he's a dumb data
>>> object, not a "player" who wants to share a costume.
>>
>> SketchMorph is the single most-used user object in Etoys :)
>>
>>> -- I was working on an icon, writing scripts to change colors
>>> pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
>>> green halo, only to find I corrupted my original, as well.  Some work
>>> lost.
>>
>> I’m sorry you lost time. Nevertheless, the originalForm in SketchMorph
>> is designed to be shared.
>>
>> - Bert -
>>
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Tobias Pape

On 01.04.2016, at 17:18, David T. Lewis <[hidden email]> wrote:

> Yes of course Etoys should work in trunk!
>
> It would be really good if some members of the squeak-dev community could
> take an interest in this, and maybe make a project out of doing whatever
> updates may be needed to clean up trunk in this regard. The Etoys image
> itself provides a clear reference of how things should work, and I'm sure
> that Bert and others would be happy to offer some guidance and oversight
> to anyone who might want to contribute.
>
> Personally I think it would be very cool if you could open a new trunk
> image, start a new project, and be able to select Morphic, MVC, or Etoys
> as types of project. Then entering a new Etoys project could take you
> directly into an environment just like that of the reference Etoys image.
>

Noted.

> Dave
>
>> Really?  That's really surprising; SketchMorph is just a dumb data
>> object, a painting, making a copy of it via the UI is a valid
>> use-case.  For every other kind of Morph, the green halo makes a deep
>> copy, SketchMorph is inconsistent, shouldn't Etoys simply override
>> that halo to call its own #semiDeepCopy to suit its own purposes?
>>
>> Is Etoys running in trunk?  It is not targeted for trunk though, is it?
>>
>> I want to be able to make easy copies of SketchMorph's.  Surely we can
>> come up with some solution; what about Karl's suggestion?   I think
>> Shift should be the sharing, because the "modifer" keys are used to
>> "modify" the standard behavior, which is a true veryDeepCopy..
>>
>>
>> On Fri, Apr 1, 2016 at 8:45 AM, Bert Freudenberg <[hidden email]>
>> wrote:
>>> On 01.04.2016, at 01:41, Chris Muller <[hidden email]> wrote:
>>>>
>>>> Okay, that's why this is in the Inbox.  I started to formulate my
>>>> question in long words in email, but decided this was the quickest and
>>>> easiest way to ask it.  :)
>>>>
>>>> Okay, so this is definitely not the place to fix my problem.  So I
>>>> will instead try putting something into SketchMorph's veryDeepFixup:
>>>> which will ensure its underlying form gets copied when I green-halo a
>>>> SketchMorph.  SketchMorph is an exception because he's a dumb data
>>>> object, not a "player" who wants to share a costume.
>>>
>>> SketchMorph is the single most-used user object in Etoys :)
>>>
>>>> -- I was working on an icon, writing scripts to change colors
>>>> pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
>>>> green halo, only to find I corrupted my original, as well.  Some work
>>>> lost.
>>>
>>> I’m sorry you lost time. Nevertheless, the originalForm in SketchMorph
>>> is designed to be shared.
>>>
>>> - Bert -



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Bert Freudenberg
In reply to this post by Chris Muller-3
On 01.04.2016, at 16:53, Chris Muller <[hidden email]> wrote:
>
> Really?  That's really surprising; SketchMorph is just a dumb data
> object, a painting, making a copy of it via the UI is a valid
> use-case.  For every other kind of Morph, the green halo makes a deep
> copy.

Every other morph is cheap to copy, compared to deep-copying bitmaps.

> SketchMorph is inconsistent, shouldn't Etoys simply override
> that halo to call its own #semiDeepCopy to suit its own purposes?
>
> Is Etoys running in trunk?

Yes it is. There are even a few people using it (e.g. https://realm.io/news/altconf-daniel-steinberg-swift-playgrounds-education/ ).

> It is not targeted for trunk though, is it?

It’s still desirable to retire the Etoys fork of Squeak. Having a unified codebase (and faster VM) would be very nice. We may finally have found students to work on that, but even if it does not happen soon it’s still the plan.

> I want to be able to make easy copies of SketchMorph's.  Surely we can
> come up with some solution; what about Karl's suggestion?   I think
> Shift should be the sharing, because the "modifer" keys are used to
> "modify" the standard behavior, which is a true veryDeepCopy..

Why not adhere to the copy-on-write scheme for forms in Morphic? That’s how it was designed.

E.g. when you make a green-handle copy of a SystemWindow, why would you want to deep-copy all the icons?

Instead, before you modify a form (which is an extremely rare operation compared to all uses of forms), make a copy of it. That is how all the Sketch editing functions work (e.g. in the halo’s “painting…” submenu).

Btw you may consider using an ImageMorph if you don’t actually need all the specialized SketchMorph functionality. It does share the form when deep-copying too, though.

- Bert -

>
>
> On Fri, Apr 1, 2016 at 8:45 AM, Bert Freudenberg <[hidden email]> wrote:
>> On 01.04.2016, at 01:41, Chris Muller <[hidden email]> wrote:
>>>
>>> Okay, that's why this is in the Inbox.  I started to formulate my
>>> question in long words in email, but decided this was the quickest and
>>> easiest way to ask it.  :)
>>>
>>> Okay, so this is definitely not the place to fix my problem.  So I
>>> will instead try putting something into SketchMorph's veryDeepFixup:
>>> which will ensure its underlying form gets copied when I green-halo a
>>> SketchMorph.  SketchMorph is an exception because he's a dumb data
>>> object, not a "player" who wants to share a costume.
>>
>> SketchMorph is the single most-used user object in Etoys :)
>>
>>> -- I was working on an icon, writing scripts to change colors
>>> pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
>>> green halo, only to find I corrupted my original, as well.  Some work
>>> lost.
>>
>> I’m sorry you lost time. Nevertheless, the originalForm in SketchMorph is designed to be shared.
>>
>> - Bert -
>>
>>
>>
>>






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Karl Ramberg
In reply to this post by Bert Freudenberg
Ok, I miss understood the difference

Best,
Karl

On Fri, Apr 1, 2016 at 3:29 PM, Bert Freudenberg <[hidden email]> wrote:
On 01.04.2016, at 14:33, karl ramberg <[hidden email]> wrote:

You can hold shift while dragging the green handle to change it's copying behavior. One makes a sibling, so they share the same form. One makes a copy of the morph and form.

Not true. Both make a copy of the morph, both do *not* copy the form.

The only difference is that the morph’s player’s class is the same for siblings, but unique for copies. Hence, scripts (methods) are shared between siblings, but independent for copies.

- Bert -

On Fri, Apr 1, 2016 at 9:43 AM, marcel.taeumel <[hidden email]> wrote:
We should use real morphs as halo handles, not only forms. Then we can
define/adjust that deep-copy operation there.

Nevertheless, Chris is right that the override of #veryDeepCopyWith: in Form
outside any Morphic extension category is quite smelly. Deep copying is not
Morphic-specific.

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Inbox-Graphics-cmm-329-mcz-tp4887677p4887736.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.












Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Stéphane Rollandin
In reply to this post by Bert Freudenberg
> It’s still desirable to retire the Etoys fork of Squeak. Having a unified codebase (and faster VM) would be very nice. We may finally have found students to work on that, but even if it does not happen soon it’s still the plan.

+1

Stef


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Eliot Miranda-2
In reply to this post by Bert Freudenberg
Hi All,

> On Apr 1, 2016, at 9:45 AM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 01.04.2016, at 16:53, Chris Muller <[hidden email]> wrote:
>>
>> Really?  That's really surprising; SketchMorph is just a dumb data
>> object, a painting, making a copy of it via the UI is a valid
>> use-case.  For every other kind of Morph, the green halo makes a deep
>> copy.
>
> Every other morph is cheap to copy, compared to deep-copying bitmaps.

That makes sense.

>> SketchMorph is inconsistent, shouldn't Etoys simply override
>> that halo to call its own #semiDeepCopy to suit its own purposes?
>>
>> Is Etoys running in trunk?
>
> Yes it is. There are even a few people using it (e.g. https://realm.io/news/altconf-daniel-steinberg-swift-playgrounds-education/ ).
>
>> It is not targeted for trunk though, is it?
>
> It’s still desirable to retire the Etoys fork of Squeak. Having a unified codebase (and faster VM) would be very nice. We may finally have found students to work on that, but even if it does not happen soon it’s still the plan.

+1

>> I want to be able to make easy copies of SketchMorph's.  Surely we can
>> come up with some solution; what about Karl's suggestion?   I think
>> Shift should be the sharing, because the "modifer" keys are used to
>> "modify" the standard behavior, which is a true veryDeepCopy..
>
> Why not adhere to the copy-on-write scheme for forms in Morphic? That’s how it was designed.
>
> E.g. when you make a green-handle copy of a SystemWindow, why would you want to deep-copy all the icons?
>
> Instead, before you modify a form (which is an extremely rare operation compared to all uses of forms), make a copy of it. That is how all the Sketch editing functions work (e.g. in the halo’s “painting…” submenu).

+1.  But it needs to be documented in all the relevant Morph veryDeepCopy methods, not just SketchMorph but Morph too (& possibly in the class comments?).

I suspect that too often we write simple schemes like this that over time get obscured by layers of new code (I see uniclass support in morph VDC methods) and even if the original intent was clear in the first version, in these later versions it is difficult to see.  Conventions like this /must/ be well-documented to thrive.

> Btw you may consider using an ImageMorph if you don’t actually need all the specialized SketchMorph functionality. It does share the form when deep-copying too, though.
>
> - Bert -
>
>>
>>
>>> On Fri, Apr 1, 2016 at 8:45 AM, Bert Freudenberg <[hidden email]> wrote:
>>>> On 01.04.2016, at 01:41, Chris Muller <[hidden email]> wrote:
>>>>
>>>> Okay, that's why this is in the Inbox.  I started to formulate my
>>>> question in long words in email, but decided this was the quickest and
>>>> easiest way to ask it.  :)
>>>>
>>>> Okay, so this is definitely not the place to fix my problem.  So I
>>>> will instead try putting something into SketchMorph's veryDeepFixup:
>>>> which will ensure its underlying form gets copied when I green-halo a
>>>> SketchMorph.  SketchMorph is an exception because he's a dumb data
>>>> object, not a "player" who wants to share a costume.
>>>
>>> SketchMorph is the single most-used user object in Etoys :)
>>>
>>>> -- I was working on an icon, writing scripts to change colors
>>>> pixel-by-pixel, goofed up my "backup" SketchMorph I had torn off the
>>>> green halo, only to find I corrupted my original, as well.  Some work
>>>> lost.
>>>
>>> I’m sorry you lost time. Nevertheless, the originalForm in SketchMorph is designed to be shared.
>>>
>>> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Chris Muller-3
> Why not adhere to the copy-on-write scheme for forms in Morphic? That’s how it was designed.
>
> E.g. when you make a green-handle copy of a SystemWindow, why would you want to deep-copy all the icons?

I don't.  I want to deepCopy the form bits when I invoke the
green-halo it on a SketchMorph, not a SystemWindow.  That's what
Morph-cmm.1096 does, without affecting it when copying SystemWindows
or anything else besides a SketchMorph.

But you said the problem with that is that Etoys students are putting
their behaviors directly on SketchMorphs instead of something more
abstract like a PlayerMorph.  With a PlayerMorph they could set his
#fillStyle to some Form which would still share on veryDeepCopy, and
yet with my #veryDeepFixup: in SketchMorph, the green-halo would ALSO
work properly when invoked directly on a SketchMorph -- the best of
both worlds.

But we have to break this common use-case so that this design choice
to use SketchMorphs everywhere, will be more memory-efficient..
Sigh..

>> Instead, before you modify a form (which is an extremely rare operation compared to all uses of forms), make a copy of it.

As I said, that's exactly what I did -- or thought I was doing.  I
just did it via the green halo because I expected it to behave as it
does on all other Morphs -- to make a meaningfully separate copy.

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Bert Freudenberg

> On 02.04.2016, at 20:39, Chris Muller <[hidden email]> wrote:
>
>> Why not adhere to the copy-on-write scheme for forms in Morphic? That’s how it was designed.
>>
>> E.g. when you make a green-handle copy of a SystemWindow, why would you want to deep-copy all the icons?
>
> I don't.  I want to deepCopy the form bits when I invoke the
> green-halo it on a SketchMorph, not a SystemWindow.  That's what
> Morph-cmm.1096 does, without affecting it when copying SystemWindows
> or anything else besides a SketchMorph.
>
> But you said the problem with that is that Etoys students are putting
> their behaviors directly on SketchMorphs instead of something more
> abstract like a PlayerMorph.  With a PlayerMorph they could set his
> #fillStyle to some Form which would still share on veryDeepCopy, and
> yet with my #veryDeepFixup: in SketchMorph, the green-halo would ALSO
> work properly when invoked directly on a SketchMorph -- the best of
> both worlds.
That’s not at all how Etoys works. Yes it’s a prototype-based fat-object OO system on top of Smalltalk, but that’s not how students think about it. Students do not deal with morphs or fill styles at all.

As in many prototype-based systems, copying is a fundamental operation, and it needs to be efficient. Duplicating the bits of a form is not efficient, especially not when they get stored in projects.

> But we have to break this common use-case so that this design choice
> to use SketchMorphs everywhere, will be more memory-efficient..
> Sigh..

I’d say that modifying the bits of a SketchMorph using low-level methods while expecting a copy to not be affected is very far from a common use case. It’s not at all unreasonable, but it is not what it’s designed for, or commonly used for.

>>> Instead, before you modify a form (which is an extremely rare operation compared to all uses of forms), make a copy of it.
>
> As I said, that's exactly what I did -- or thought I was doing.  I
> just did it via the green halo because I expected it to behave as it
> does on all other Morphs -- to make a meaningfully separate copy.

I can see what you’re getting at, but we can’t put the burden on the students. But let’s think about what it would take to have our cake and eat it, too.

What if we could automate the copy-on-write behavior? If the form used in a SketchMorph could be “locked down” so that any attempt at modifying it could be caught. Then it could either just warn the user, or it could be duplicated automatically.

I can’t easily think of a solution, but maybe it’s possible.

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

Chris Muller-3
> What if we could automate the copy-on-write behavior? If the form used in a SketchMorph could be “locked down” so that any attempt at modifying it could be caught. Then it could either just warn the user, or it could be duplicated automatically.

I do like the sound of such an idea..

> I can’t easily think of a solution, but maybe it’s possible.

Okay, lets let it simmer, I'm satisfied we at least explored this idea
for now, thanks.  I could also consider extending
SketchMorph>>#veryDeepFixup: into my own package..

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Graphics-cmm.329.mcz

timrowledge

> On 03-04-2016, at 8:22 AM, Chris Muller <[hidden email]> wrote:
>
>> What if we could automate the copy-on-write behavior? If the form used in a SketchMorph could be “locked down” so that any attempt at modifying it could be caught. Then it could either just warn the user, or it could be duplicated automatically.
>
> I do like the sound of such an idea..
>
>> I can’t easily think of a solution, but maybe it’s possible.

Isn’t that what the immutable thingy is for? You try to write, get a trap, work out what happened, make a mutable copy, retry the write...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- S  p  a  c  e  d   o  u  t .