6.0beta #21848 - Canceling drag from messageNames pane opens a new window

[tcj]

Dragging a messageName (method list item) from the right-most pane of a browser is a feature that has existed for some time. It used to be that one could "cancel" the drag by returning the drag to its original source pane and releasing the mouse button. This would 'repel' the dragged morph and make the 'garbage can' sound, one of those cute Morphic animations.

But now, in 6.0beta-21848 (and earlier?), letting go of the drag with the pointer over the original position instead opens up a new window with a message list browser.

Screen recording here:

https://youtu.be/DW68lMEc49c

Can the previous behavior of canceling the drag and repelling the morph be resurrected? No window should open in this case.

[marceltaeumel]

This is not a bug. If you want to cancel a drag operation, you have to press the "Escape" key.

This is the first time I heard that a user wants to cancel a drag operation by carefully moving it back to its original source. This sounds very cumbersome and not what you want by default.

What is happening here is that, originally, the drop, which landed on the world (or background) ... not the browser ... would be repelled because the world did not know what to do with it.

We changed this to a meaningful guesture so that you can collect selected code artifacts on your screen.

---

Cancel a drag operation with the "Escape" key. That's the default gesture in most systems out there.

[tcj]

This is the first time I heard that a user wants to cancel a drag operation by carefully moving it back to its original source. This sounds very cumbersome and not what you want by default.

Dragging icons on macOS, Atari TOS, Amiga Workbench, Mac OS classic through current, Windows Explorer, Gnome file manager, Google drive, iOS, etc., all will cancel a drag when the user returns the dragged object to its original location. I'm surprised this is the first time you have heard of this @marceltaeumel . Oh, and ... probably Squeak pre-6.0

This is also an operation that is not necessarily "carefully" done — sometimes one begins a drag unintentionally (say, if one has muscle control issues), and thinks of letting go over the original source. With the new behavior, the original source is obscured and the user must go find a way to close the new window that has appeared over their work. Or, that person must be ready to hit the "escape" key should they accidentally/unintentionally begin a drag.

We changed this to a meaningful guesture so that you can collect selected code artifacts on your screen.

OK, I will try this. (I guess I do this by having Workspaces and Browsers minimized inside Projects.) Is there a demo of this in use?

Dragging a message name from this pane to another browser (to move it to a different class) or another message category (to recategorize) is a gesture that already existed in Squeak. This new functionality gets-in-the-way-of the "stop, I don't want to do this anymore" portion of that gesture.

It sounds like the new idea here is also to have a "tear-off" gesture to create a new window onto the selected message name. And, that the gesture should work even if the message name is dragged over itself. "OK," though I believe there are keyboard shortcuts and menu items to open browsers on selected message names already without impact existing behavior. I am aware that there is a preference available for turning this off, so thank you.

[marceltaeumel]

With the new behavior [...]

Well, that "drag back to original source" was never implemented. It was just an unintentional side effect of the world morph repelling all such drop operations...

This new functionality gets-in-the-way-of the "stop, I don't want to do this anymore" portion of that gesture.

Let's not mix up things. That new gesture only applies of the tool itself does not want that drop operation. So, I think you just found a bug with that method-drag-drop interaction between browsers.

I believe there are keyboard shortcuts and menu items to open browsers on selected message names already without impact existing behavior.

Such keyboard shortcuts are hard to learn. Keyboard-based and mouse-based navigation are two different concepts that are often not exclusive but rather redundant.

[marceltaeumel]

Dragging a message name from this pane to another browser (to move it to a different class) or another message category (to recategorize) is a gesture that already existed in Squeak.

When was that? I just checked Squeak 4.4. Dragging methods betwen classes is not supported.

[marceltaeumel]

[...] menu items to open browsers on selected message names [...]

It is not convenient to collect methods via the regular System Browser. Too much visual clutter. Just using a CodeHolder is much more compact.

[tcj]

When was that? I just checked Squeak 4.4. Dragging methods betwen classes is not supported.

Not true. I can do it. Here's a video.

https://youtu.be/MaVPlWQ9sjc

And a screenshot:

Note that dragging while holding Shift changes the visuals to have a red "+" sign indicating the method will be copied.

[tcj]

[...] menu items to open browsers on selected message names [...]

It is not convenient to collect methods via the regular System Browser. Too much visual clutter. Just using a CodeHolder is much more compact.

My point is that one can already quickly open new browsers on message names using existing menus, without resorting to dragging. Here is a video.

https://youtu.be/2K1FPX3fjA8

[tcj]

Such keyboard shortcuts are hard to learn. Keyboard-based and mouse-based navigation are two different concepts that are often not exclusive but rather redundant.

I'm just thinking of this statement in context of "press Escape on your keyboard to cancel your mouse drag operation." I realize it does not relate 1:1, but philosophically there is some resemblance. Esc to cancel mouse drag is common across platforms, but is often not the only way to cancel a drag. (Some platforms allow one to press a secondary or tertiary mouse button to cancel as well, for example.)