Make mouse clicks instantly trigger menu entries (while touch behaves as it previously did)

[ghost]

I found the mouse navigation with RPG Maker MV a bit unintuitive, because for unselected menu entries you need to click twice to trigger the entry which is unusual. However, that behavior is nice to keep for touch to avoid accidental triggers.

Therefore, I added code to detect mouse vs touch events, and made the menu entries in Window_Selectable.js instantly trigger when clicked by mouse while keeping the current behavior when clicked/triggered by touch.

This is my first pull request, so if I did something incorrectly about this please let me know 😄

Important: I have a laptop with a touch screen but sadly I couldn't get the browsers to generate touch events. Therefore I haven't tested yet if the touch events still work as previously on an actual mobile touch device. If you have a mobile device, it would be nice if you could help test and report back if it works as intended. (touching an unselected menu entry should select it, and only a second touch should trigger it)

[krmbn0576]

Okay, this is certainly a better behavior for me.
However, many users may be confused by sudden specification change?
Furthermore, plugins can also be used to implement this feature.
It's hard to decide whether we should accept this PR. 😖

[ghost]

@krmbn0576 with plugins the problem is that many people won't notice the problem and/or they won't know that there is a plugin to change it, so unless this is fixed in the core there will always be plenty of games with the old, worse behavior out there. (and the old behavior is quite annoying for mouse users!) Therefore, merging this will fix it for everyone's games instead of just those where the game makers are savvy enough to notice it and do something about it.

Also I think it is better if plugins are mainly used for features (I consider this behavior a bug) because having a larger amount of plugins just to fix such basic bugs makes upgrades to newer RPG Maker MV versions annoying when you need to make sure all your bug fix plugins still work. So in my humble opinion, in the long run it is always better to fix stuff that everyone can agree is a bug in the core instead of leaving it to the plugins.

But that's only my view of things 😄

PS: I don't think the new behavior will notably confuse anyone. If at all, it will lead to pleasant surprises ❤️

[ghost]

So what's the plan for this? I can write it differently if required

[krmbn0576]

There is no need to change any more!

I can't decide whether to accept your proposal for a long time. 😖

[ghost]

In the future, we may change UI behavior, but not now.
I'm afraid to say, if you need changing UI behavior, it's by plugin for now.

[ghost]

Any rough roadmap on when this is going to change?

The problem is that I have a plugin for this and many other basic UX bugs (e.g. no visible "back" buttons on any of the menus which would make mouse navigation again much more intuitive) that conflicts with some actual FEATURE plugins which add new menus and screens, which makes RPG Maker MV very cumbersome to work with for me unless I never use any UI feature plugins ever.

I can choose to either have a working UI but have pretty much no special features / new screens (unless I do everything on my own), or have nice features but those basic UI annoyances unfixed which in overall makes it an unnecessary pain to use for the player - especially to many other modern much more mouse-compatible RPG games it just seems somewhat outdated.

So basically I'm at a point where as long as the UI issues are not fixed in the core so that feature plugins work with it, I might as well rewrite the entire UI just for me and at that point I'm wondering why I even need to use RPG Maker. (instead of e.g. libgdx, SDL2 or some other more lowlevel framework,...)

I'm really not planning to make any feature suggestions for actual new UI additions, but if at least the basic underlying problems with just using what is already there could eventually go in the core that would make a really huge difference for me!

Edit: and yes this particular merge request here is one that might actually be still fixable with a plugin without conflicts. However, if not even such a simple change has a chance of being accepted I'm wondering if I should even go ahead and try to create merge requests for the more invasive ones..

[ghost]

Maybe this would be a good candidate for VER 1.5 (according to the roadmap) with the planned UI overhaul?

[krmbn0576]

In VER 1.5, of course we will consider improving the UI including your proposal!
But it is now postponed. 🙇