Unintuitive Minieditor Behavior

Issue #41 new
Enthalpy created an issue

The process of making a selection from an minieditor is as follows: * Open minieditor by clicking on its parent node * Make a selection from the minieditor * Close the minieditor by clicking elsewhere

It's unintuitive for simply "clicking elsewhere" to close the minieditor, and several people have just clicked on the parent node again. That normally works, but in the editor, the music and sound minieditor parents are right on top of each other. Frequently after making a music selection, the mouse will be under the audio cell. Moving the mouse up to try and click the mouse minieditor also opens up a sound minieditor, so now, hovering over the music minieditor destroys it before the mouse reaches the music minieditor parent element.

While the player can get around this by knowing the intended minieditor behavior, it would be better to adopt a more intuitive version. For instance, block creation of new minieditors with a minieditor is currently focused.

(Note: "clicking elsewhere" is imprecise. This bug will be updated with the more precise close conditions when I've found them, which may also adjust the recommended fix.)

Comments (0)

  1. Log in to comment