Clones can't show their own local variable/list monitors

[towerofnix]

(This is more of a feature suggestion / discussion place, since details need to be worked out and this is a very low priority request.)

When a clone of a sprite runs the "show variable" (or "show list") block with one if its own "for this sprite only" (local) variables (or lists) passed, instead of the monitor which corresponds to that clone's variable, what is shown is the monitor that corresponds to the original sprite's variable of the same name. This means it is impossible to show monitors corresponding to a clone.

That is arguably for good reason, because if you could show monitors belonging to clones, you could arbitrarily and easily create new monitors, filling up the screen and making the player unusable. (You would use a script such as "forever: create clone of myself; when I start as a clone, show list fooey" to do that.) However, there are many ways to make the stage unusable. The only reason this way is more problematic is because it is difficult or impossible to clean up, if we make the assumption that the user would need to manually remove the monitors. (There is no way to do that currently: the checkboxes for clone monitors do not show up in the block palette, and that is the only way to hide monitors currently. See #4148.) But we can work around that by making monitors of clones disappear when the clone is deleted, which the user can easily control at any point by pressing the stop sign button.

A particular question is how layouting should work for clone monitors; it would not make sense to just pile all monitors of the same-named variable/list in each clone on top of each other. I suggest that when a clone shows a monitor, the monitor inherits the positioning from the parent monitor, if there is not already a monitor shown in that position. (That is, if neither the original sprite nor any other clones are currently showing the monitor of their instance of that variable.) If there is already a monitor there, it should follow the same layout rules as when ordinarily showing a new monitor.

Besides these design decisions, the implementation could also be difficult. I haven't worked with the hide/show monitor code very indepthly, so I'm not sure how complex it would or wouldn't be to dynamically create new variable and list monitors, and to dynamically destroy them as well.

It should be noted that this is not a high-priority feature request. I'm creating this issue as a place to discuss the feature if anybody would like to, but this is a technical and rarely used suggestion. There are many other issues (nudge) where official design input would be much more appreciated.

[Wowfunhappy]

That is arguably for good reason, because if you could show monitors belonging to clones, you could arbitrarily and easily create new monitors, filling up the screen and making the player unusable.

I don't think that's a good reason. If you want to fill the screen, you can trivially do it with the clone sprites themselves.

I agree that if a clone creates a monitor for one of its local variables, that monitor should disappear when the clone is deleted (whether due to green flag clicked, delete this clone, etc). Other than that, I mostly don't understand the design concerns. Each monitor should be considered a new monitor, and follow the standard positioning rules for new monitors.

I think this feature is relatively important, because as things stand, the way clones handle local variables is a bit confusing. The setting for local variables reads "for this sprite only", and I initially assumed clones were considered the same sprite—largely because of the way monitors currently work. Scratch's behavior reinforces a misconception!

[towerofnix]

I agree, but it's worth keeping mind that it may well not have been a deliberate design decision in the first place. As useful as it would be for clones (and yes! the current behavior is misleading!), it also may be technically involved as it involves coupling watchers to individual sprite objects rather than a given sprite, automatically deleting those watchers when the clone is deleted, and ensuring the watchers aren't serialized (i.e. saved as part of the project file).

Also, when this issue was created (which itself was well after watchers were done being implemented), there still wasn't an option to hide watchers with the context menu. That wasn't implemented until just last year, see scratchfoundation/scratch-gui#4148. So it follows that there were mostly technicality and usability issues blocking this suggestion, rather than necessarily any design decisions (we didn't hear any official word on that angle — OK, or any angle — so we can't assume design-level objections nor acceptance).