Realistic mouse GUI

I don't think this is something that should be too difficult to implement, and it should not affect keyboard-only games either.

Jet released another mouse script recently which adds mouse functionality to Window_Selectable. And seems to have addressed some bugs from the previous rgss3 mouse script. Which means basically every window that matters has mouse support.

However, when you think of a mouse GUI, you'd expect to be able to just move the cursor from window to window and the appropriate window you're hovering over will activate.

I think that should also be reflected in RM, rather than simply simulating how things would be done with a keyboard, especially if you're using the mouse in your game.

Any ideas how to make this efficient?

It'd involve checking which window you're hovering over, but you have to take into consideration overlapping windows, windows that aren't Window_Selectable objects, etc.

Ideally it should just be a couple aliases to the Mouse module and Window_Selectable.

I'm not sure this makes sense. In the RM world, not only is there a built-in notion of window focus, but typically whatever Window_Selectable is active at any given time is basically analogous to a modal window.

Feel free to correct me if I'm wrong, but I can't think of any places where this isn't true, and being able to select different windows is even sensical.

The only way to change focus in the current window design is to press cancel or OK depending on the handler. Of course, strange handlers are used in order to shift between different windows if cancel or OK are not enough, like if you want to press the right key to move to the right-window, or the left key to move to the left window.

It is just not intuitive to have to right-click and left-click just to navigate a GUI.

I want to change focus by simply hovering over a window.

Yes, just because "RM always does it this way with the keyboard" is not a reason to do it that way with the mouse. I agree - a proper mouse interface would not require you to click on things in a certain order when you can already see it all on the screen.

I'm sure you can do it, but you'd have to rewrite a lot of handlers. I'm not sure how to address the issue of overlapping windows.

I wish I wasn't so swamped - this'd be a very interesting challenge to tackle (though I'm more interested in XP)

I think if people stick to some "ok" and "cancel" standards, we wouldn't need to have to re-write any of the handlers. After all, most of the handlers are used to explicitly activate a different window, and don't have any real uses beyond that.

For example, on the item scene, you have your item categories, and then the respective item lists. The category window's OK button only serves to activate the item list window. The item list window's OK button actually selects an item.

But an issue comes up. When you select an item, it may activate the actor window for you to select which actor to use the item on. If I were to move my mouse to another item and left-click, it is not choosing another item; instead, the focus is still on the actor window. But then if focus changes based on where the mouse is hovering, it might make it difficult to actually use an item because you'll be losing focus all over the place.

Maybe it's not as simple as just saying "activate the top-most window you're hovering over"