For my BloP extension I'm trying to get rid of arrows in reporter rings and to make them non-draggable, so that users are not confused by the arrows and cannot drag the ring out of the argument by mistake.
// get rid of right arrow
part.children[1].children[1].children[1].isVisible = false;
// make ring non-draggable
part.isDraggable = false;
It seems to work: when I create a new block with a "report" input name (https://gofile.io/?c=AV3aCK), the ring has no arrows and it is non-draggable. If I then drag the new block in the script area everything still works as expected. But when I save and reload the project, the "no arrow and undraggable" feature works only in the palette: in the block that I had previously dragged in the script area the arrow is instead visible, and the ring can be dragged out of the argument. Am I missing something?
Oh yes! To change rings behavior it's not so easy...
You are changing the block slot. Yes, but not the behavior of all rings in Snap!
When you change the block, the ring is not draggable. But if you drag and drop another "ringified" block into this block, then, that ring will be draggable because it is not the created for the block, it is a "free" ring.
The same about your stored projects. Those rings (the content stored) are just normal rings. Snap! does not know their origin. So they are draggable rings. You can see that you can dragg them, but after this, the ring of the block will be again undraggable, because this last ring is created by the block.
Of course, you can also hack RingxxxMorphs. If they are not draggable, you can only create them inside the rings of the block. This is a possibility... but then you are limiting/changing a basic idea in Snap!... And sure you will have inconsistencies.
Thanks a lot Joan, I hadn't thought of it. Luckily enough there are not many places in Snap where BlockMorphs are made draggable. I added several "locks" where BlockMorphs (and, then, RingMorphs too) are duplicated and now everything seems to work fine. Thanks again