search

jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.5k stars 745 forks source link

Position of white drop-here line inconsistent #1196

Open brianharvey opened 8 years ago

brianharvey commented 8 years ago

This is a tiny, tiny UI problem, but when someone has some time... If you make a stack of regular old stack blocks and then drag another one near them, the drop-here line if you drag into the middle of the stack is (correctly in my view) at the edge between two stack blocks, ignoring the fact that the upper one has a little tab extending into the lower one. But if you drag to the bottom of the stack, the white line goes at the bottom of the tab, not the bottom of the rest of the bock. This is arguably okay even though inconsistent.

Now, however, consider the situation when you nest C-shaped blocks and drag a stack block nearby. Dragging to the bottom is like dragging to the bottom of a non-C stack: the white line is below the tab. So far so good.

But if you drag below the inner C-shaped block but still inside the outer one, the white line is also below the tab. I think this is dead wrong. I never noticed until I mistakenly dropped a block inside the inner one instead of inside the outer one because I thought the position of the white line in the latter case meant that my new block would be below the whole thing. The position of the line is really unclear, dead center in the bottom part of the outer C-block.

In that case it should be between the two bottom edges, ignoring the tab.

jmoenig commented 8 years ago

So, this is a problem for me, because - if you ever look at the code - I've gone to extreme lengths to exactly mimick Scratch 1.4/BYOB's drop-target-feedback's positioning behavior, mostly because I didn't like Scratch 2.0's way of showing a 3D-ish outline of the whole script in hand. This has gotten somewhat better in recent renditions of Scratch 2.0, where they only show a condensed marker, but - bottom line - Snap wants to do exactly what Scratch 1.4/BYOB does, and it succeeds in that. Same, btw, with GP. So, given that this behavior is precisely meeting its requirement (do as Scratch 1.4 does), I'm reluctant to encourage anyone to tamper with it.

brianharvey commented 8 years ago

There was a time in our history when compatibility with Scratch 1.4 was strongly desirable, but we're past that, especially when 2.0's behavior is different. Nobody is now expecting this behavior except our own users. And this isn't about portability of projects; it's about the user interface. And if this is what 1.4 did, then imho 1.4 was wrong too. (I know I lived with this behavior in BYOB for a long time, but all that time, whenever I'm in a situation like this, I have to jiggle the block I'm inserting up and down for a while to work out where to let go.) I'm not proposing to uglify it, just to make one visually ambiguous situation unambiguous. What's not to like?

jmoenig commented 8 years ago

Haha, it's like Knuth's definition of how after his death all remaining bugs in Tex become features. Scratch 1.4 has died, so now it has become the gospel to me :-)

brianharvey commented 8 years ago

I still have a 1.4 on my Mac, if that makes you feel better about moving the white line. :-)