Opened 10 months ago

Closed 10 months ago

Last modified 10 months ago

#400 closed enhancement (invalid)

Window menu gadget and elements enable on mouse click up

Reported by: walkero Owned by:
Priority: undecided Milestone: 5.0-2018R4
Component: muimaster.library Version: 5.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

Problem

The windows menu gadget items, the radio buttons, and maybe other elements, apply the change on mouse click down and not on mouse click up and release.

Analysis

In my opinion, it would be better to work in a similar way with workbench elements. You can test it if you tryto click on a radio button and keep the mouse button pressed. The change is already applied.

Also, if you open the window menu from the top right corner gadget, and try to move the window to an other screen, if you click on a selection, and keep the mouse button down, the selection is already applied.

This doesn't give the user the ability to undo his selection by moving away.

Enhancement recommendation

I recommend to change the way it works and enable changes on mouse up/release. If you do not agree with that, maybe add a way for the user to set the way he want's this to behave, at the MUI preferences

Change History (2)

comment:1 Changed 10 months ago by Thore Böckelmann

Milestone: future release5.0-2018R4
Resolution: invalid
Status: newclosed

This might become a very philosophic discussion.

For the popup menus I cannot really second your opinion. There is no need to keep a mouse button pressed while the menu is open. There is lots of time to navigate through the items and finally choose whether to click one or not. You simply cannot accidentally release the mouse button on the wrong item. If that approach is not intuitive enough for a sensible selection, then reacting on "mouse up" events instead of "mouse down" won't change anything, from my point of view.

Additionally popup menus make "selection on mouse up" a bit harder than other GUI elements. What if the "mouse down" action happens on one item, but "mouse up" happens on another item? How should MUI react? Discard the action? Invoke the action of the "released" item, even if it wasn't selected upon "mouse down"? Honestly, there are so many possible solutions which extend far beyond "user configuration" - which again has to be done via the same GUI elements which have wrong from your point of view! What if you chose the wrong option due to the reaction you were about to change?

For the radio buttons the situation is similar. I agree that certain GUI systems perform their actions upon releasing the mouse button (while other systems behave like MUI). But in the perspective of MUI prefs the argument "the change is applied too early" is quite void. MUI prefs offers lots of ways to make the accidentally made action undone (reset to defaults, reset to last state, leave MUI prefs via "Cancel" button).

Honestly, how often do you really press down a mouse button on a GUI item, keep it pressed to rethink that action for a while and eventually decide that it was wrong and release the mouse button outside the GUI item? Usually a mouse click (down + up) is a very short action with next to no time between "down" and "up". And if you really chose the wrong option from a radio button, popup menu or whatsoever, it should never be to hard to revert that selection. However, if a revert is really that hard, then the GUI was designed wrong and is not user friendly at all. But that is something that MUI (or any other GUI system) cannot avoid to happen.

To sum it up: I won't change the way how radio buttons and popup menus react on user input. Things have been like this for more than 20 years by now and at least during the last 10 years you are the first to talk about an alternative "time of action".

comment:2 Changed 10 months ago by walkero

Thank you for taking sometime to reply on that.

Of course I didn't demand for you to agree with me. It was just what I had in mind for a lot of time and always wanted to ask.

Thank you for the hard work you are doing.

Note: See TracTickets for help on using tickets.