visibleToMouse and visible working as intended? or?

From what I have read, visibleToMouse should either set a component to consumer mouse events or not. I have moved away from using XML definitions completely and ensured that ALL elements/components are set to visibleToMouse(false) or setVisibleToMouse(“false”) respectively. This is having no effect in certain circumstances. Let me explain some of what is happening.



In scenario 1: (mouse movement consumption)



I have a cursor “slot” defined for grabbing objects. This has an Image element (not nifty) that follows the cursor to give a graphical representation of the item that has been picked up. No matter what I do to disable event consumption by Nifty, when I mouse over a nifty component the image stops following the cursor. It seems mouse movement is being consumed.



In scenario 2: (mouse click consumption)



I am resizing a window (or moving) a window. If I release the mouse left button while over another nifty component, the mouse release event is consumed and the client “thinks” it is still resizing (or moving). It seems mouse button clicks are being consumed.



In scenario 3: (mouse wheel consumption)



I am using an orbital camera, if nifty gui is present, the mouse wheel (zoom) is consumed 80% of the time whether or not I am over a nifty component.



In scenario 4: (visible issue… though this is not a problem when not using xml definitions… worth mentioning)



Create a nifty component (such as a button) inside of a panel. use the visible=“false” param in the panel tag to hide the panel. The button is not visible, but still responds to mouse clicks until you show and re-hide the panel via code.



There is more, but… this should be a decent start to helping figure out what I can do to stop event consumption by nifty (or jme if that is where the problem is).

Question:



Can you have interaction set on an Element or Control and still have it set to visibleToMouse(false)? Or does this override visibleToMouse?

I experience similar problems with mouse input being consumed. Mainly when I rotate the camera using Hold RMB. When I move the mouse and it’s hovering above a nifty component it will consume the rotation/pan/etc.



As for the mouse wheel, I also have that behavior. Once in a while it’ll go through, but most of the time it is consumed.

Nifty currently does not know about Mouse Wheel Events and therefore is very unlikely consuming them.



If you set any interact stuff on an element it will be visibleToMouse=true by default. The logic behind is, that for instance onClick does not make much sense when the element is not visibleToMouse :slight_smile: I think it should be possible to manually set visibleToMouse to false after Nifty has created the elements.

I agree about the logic of visibleToMouse. However, I am evaluating this prior to interaction and can enable/disable as necessary… as long as it is possible, and just wanted to know if this was an approach worth pursing. As for events that Nifty is unaware of, I have a feeling it is the implementation into jme3 that is causing some of these issues, I am just not sure which events are and which are not, and want to report any and all errors I encounter in case they are useful. If they are something I am doing, I am good about posting the reason I was causing the errors so others can avoid making the same mistakes and bothering you with the same reports.



One other question I haven’t had any success in finding an answer to:



How do you set the zOrder of elements?

void,



I don’t know if it would be easy to implement, or that good of an idea really, but I’m thinking maybe if we could specify the kind of event we want a nifty element to ignore/process (visibleToMouse), like maybe an enum containing LMB, RMB, mouse movement, wheel, etc, or all of them. By default it would be all.



What do you think?

t0neg0d said:
How do you set the zOrder of elements?

I doubt there is one, the display logic is defined by the xml structure.. In swing you also don't have anything like zOrder?
normen said:
I doubt there is one, the display logic is defined by the xml structure.. In swing you also don't have anything like zOrder?


The old window control brought the elements to the front of the screen, but I never could track down how :(

And in swing:

Container.setComponentZOrder("stringname", order); or some such thing... can't remember exactly.

no zorder in nifty. as normen said it, the order of the elements in the tree determines the order they get rendered. if you need special orders you can use childLayout=“overlay” or an overlay effect.



@madjack: I don’t see much use of having that much control at the element level. what I think might be more useful would be what t0n…dudewithaoddname suggested: having a global switch to disable handling events by nifty completly. BUT on the other hand if you have nifty and something else on the screen at the same time, you’d really want to click the elements :slight_smile: why would you want to have them rendered on a first place if you can’t interact with them at all? doesn’t make much sense to me right now.

@void256

Let’s say, for example, that you have a slotted toolbar or a “popup” panel that can be left opened while the user does its thing. Now, like in my case, if the user holds the right mouse button to move the camera around, nifty will gobble up the camera movement as the (now invisible mouse cursor) move above the element/panel. As soon as the mouse moves off that area, events are once again dispatched to the app.



Does that makes sense to you?

yeah, but that’s a problem of the “now invisible mouse cursor hovering nifty stuff” which should be handled inside the jme3 inputsystem. when you hover the camera then those events should not be forwarded to Nifty at all.



restricting the events that a nifty element can handle really feels like a workaround to fix a problem that should be handled elsewhere …



Edit: Maybe having the “now disable all nifty events” switch would be a solution but not filtering the kind of events at the element level.

Yeah, I guess @Momoko_Fan should only let mouse button events be caught by nifty if possible…

The invisible cursor isn’t the problem really. It is invisible because I’ve set it so. All I’m saying is that when the user will see the game stop responding to his movement, he’ll think there’s some problem, but it’ll be because he’ll be over the panel/whatever.



Anyway, if you think the behavior is wrong maybe @nehon or @normen should verify this.

Sorry I’m tired.



I get what you mean now. If the event has been initiated outside of nifty is shouldn’t be forwarded. Gotcha.

I fixed this in SVN: Mouse events will be handled by nifty only if the cursor is visible

1 Like

Thanks @Momoko_Fan :smiley:



I confirm the event isn’t forwarded. :slight_smile:

@Momoko_Fan

Is there any way you can change this to mouse clicks instead of mouse movement? Though, Mouse click is a serious problem as well, it may be a little better than current. Having jme3 decide what mouse interaction is supposed to do is EXTREMELY stifling. Actually, a way of enabling and disabling Nifty notification would be perfect! I can’t even begin to describe all of the scenarios where passing mouse events to Nifty to be consumed causes problems.



On a related note, the mouse wheel is still being consumed 80% of the time, whether or not you are over a nifty component. This seems to only be a problem when Nifty is present though. Also, it is worth mentioning, if you are moving the mouse while using the mouse wheel, it seems to work. If the mouse is not moving, neither does the wheel.



The rest of the issues would more than likely disappear if I could just disable/enable the notification to Nifty as I need them to happen.



EDIT:



On second thought, here are a list of scenarios that are critical in the game I am developing… and I am sure you will see how others will eventually find the same sorts of problems with current event forwarding to Nifty:



Before:

You could determine the mouse position over a Nifty element and capture mouse wheel interaction. forward this to a custom scroll control and execute code to scroll the window.



Currently:

This no longer works



Before:

You could determine the mouse position over a Nifty element and capture right click events. Convert them to left click and forward them to Nifty to show right-click menus ONLY when a right-click was used.



Currently:

This no longer works



Before:

You could determine the mouse position over a Nifty elements and capture clicks. If they were no intended for your game, but for the GUI only, you could stifle them and point them to Nifty only.



Currently:

This decision is made for you and it no longer works



There are more… buuuut… anyways