Not sure if this is a "technical issue" or other, but...

I'm wondering about the rationale for Pd's UI behavior when dragging an object on the canvas.

As I see it, there are two things you want the mouse to do with an object: edit its contents, or move it. These are separate use cases: when you're editing an object, you're not moving it; when you're moving an object, you're probably not interested in editing it.

The Pd interface actually blends these separate use cases in an awkward way: dragging an object on the canvas, when you release the mouse button, the object enters text-editing mode!

Why?

Does anybody actually want or like this behavior?

Is there any precedent, anywhere, in any other point-click GUIs for this?

Common user-interaction case: Use the mouse to pull the object close to where it should go, and then nudge by arrow keys for precise positioning. But arrow keys in fact move a text cursor through the box's content. To execute this arguably most-common object-positioning action requires an extra step in the middle: drag; rectangle-select the object (which was already selected, when you dragged it!); arrow-key nudge. Multiply by hundreds of times in a session.

If there is a concrete reason for this behavior that I'm overlooking, I'd like to know what it is.

Thanks,
hjh

@ddw_music I totally agree with you. That makes me nervous sometimes

Maybe @Miller Puckette could change this behaviour in future releases? I would be glad

@ddw_music That drives me nuts to no end, also how the right click/contextual menu is sticky on objects, click and release, menu stays, but not on the canvas, click and release selects, I am forever accidently opening canvas properties, especially on my laptop when I accidently palm the touchpad. I would love sticky menus all around and a general sticky mouse, having to hold the mouse button down to drag is awkward on touchpads. Some configureability for mouse buttons would be great as well, would love to be able to set button #4 to control click. Perhaps all of this can be adressed through the TCL? Isn't most of this interface stuff stuck in there?

@oid Yes...... using a Mac trackpad my lazy middle finger grabs the Properties menu nearly every time I try to draw a cord.
Maybe time to buy one of those last century devices before they disappear.
I think it was called a "Mouse".
@ddw_music But it makes sense that a new object "put" enters text editing mode as it is an empty object that needs to be defined.
Drag and drop an existing box......select and drag then...... click outside = drop...... click inside = drop and edit.
To edit and not move click inside without selecting.
It makes sense to me.
David.

@ddw_music I agree and i it may have gotten worse. At least one thing that gotten worse is that when you create an object, type in the name of the object and press ctrl + e it does not leave edit mode. You have to press crtl + e a second time to get out of edit mode.

Here's the "mouseup --> edit" culprit: https://github.com/pure-data/pure-data/blob/d883936354056ff89a2f8391364fbe9c962e9c41/src/g_editor.c#L2923

The comment seems to indicate that this is deliberate, though it doesn't explain why.

Will poke around more later.

hjh

@ddw_music I think it is best to put this on the mailing list where the developers are. From a quick search i think the issue haven't brought up yet.

What you can do as a workaround is to use the tab button to select the next object and then shift + tab to select the object again. Now you can move it with the arrow keys.

@ingox Sure, I can take other follow-ups to the mailing list.

FWIW, it seems to be a hack: AFAICS, both clicking on an object (without dragging) and dragging the object set an onmotion flag to MA_MOVE -- that is, there's no distinction between moving and selecting. Then, as a result of failing to make that distinction, the only way to enter an object's text for editing is to assume that a "move" action should mean "edit" as well.

So the rationale is purely developer convenience, which I don't accept.

This drives me insane enough that it's worth it to me to patch it.

hjh

OMG it appears to be easier to fix than I thought:

Old:

    else if (x->gl_editor->e_onmotion == MA_MOVE ||
        x->gl_editor->e_onmotion == MA_RESIZE)

New:

    else if ((x->gl_editor->e_onmotion == MA_MOVE && !x->gl_editor->e_lastmoved) ||
        x->gl_editor->e_onmotion == MA_RESIZE)

So... it took someone who's not even that good at C, and completely unfamiliar with Pd's codebase, about 15-20 minutes to find this... and it's just been left like this for years? OK. Fine

Next step, pull request.

hjh