Nifty popup forwards typed-in keys in a textfield

or in other words, with that new panel open can you still click the buttons on the panel on the right side of the screen?

It’s not a popup and I can interact with the other panel (clicking “More information” will close that info panel). That’s the way I want it. It’d be easy to fix that if interaction was disabled by putting a “Close” button on that info screen (which I will eventually).

The two buttons in that info panel (“Rename Selection” and “Complete specs”) are using popups though because I want nothing else to be processed or interacted with while those are opened. Can’t switch to a different star while the Rename popup is opened right? :wink:

Maybe it should work like this?



http://i.imgur.com/kigyU.jpg

Or - again :stuck_out_tongue: - there is the need for a global switch. In case of my screenshot, when you have that panel open you want to force all key events to Nifty no matter where the mouse is, you could do so with that global “now send all events to Nifty only” switch. Which you would need to control manually from Java of course.

void256 said:
Or - again :P - there is the need for a global switch. In case of my screenshot, when you have that panel open you want to force all key events to Nifty no matter where the mouse is, you could do so with that global "now send all events to Nifty only" switch. Which you would need to control manually from Java of course.

Yes, I agree with that. What happens to conflicts?

Preview panel = Interaction.
Info panel = No interaction.

Preview panel can exist without Info panel.
Info panel CANNOT exist without Preview panel.

I still think my way is better. :P lol

it’s simple, there is no conflict :stuck_out_tongue: because currently you can’t have that in a normal Nifty screen :slight_smile:



we first need to get the event processing sorted out. everything else comes next.

So what takes precedence when doing it your way?



My way of processing events is simple. First you have a tag called “interactionAllowed”. By default it’s set to false. That means that by default, any Nifty screen visible will not allow keystrokes, mouse movement, clicks, to go to the engine.



Setting interactionAllowed=“true” in the screen definition will effectively reverse the behavior for that screen (all events are forwarded)



“interactionAllowed” could also be used on panels and layers (I think using this on controls was a bad idea). When that is set to false, all interactions within that panel will not be forwarded. (Think of the preview window above) That also means that using TAB or arrows will be gobbled up by Nifty, click, SPACE, ENTER will also be eaten (that should be how it works anyway as GUI should always consume inputs used on their stuff) by default.



This way, the only thing you have to worry about is knowing the “interactionAllowed” state of the screen and panels/layers. There is no risk for having conflicts nor is there any precedences of any kind. A panel or layer either stops interaction or it doesn’t within itself. The screen is simply the default behavior when a panel/layer is visible and isn’t setting the “interactionAllowed”.



Maybe it’s clearer that way.

I prefer the idea of focus. When you click on a text field, all keyboard events go to it. Then you click the game and then all keyboard events go to the game because the game is focused. You can kinda emulate it if you place a focusable element in the background, so when its clicked, that element will get all events (but instead of getting the events it should just ignore everything).

Momoko_Fan said:
I prefer the idea of focus. When you click on a text field, all keyboard events go to it. Then you click the game and then all keyboard events go to the game because the game is focused.

What happens if a user makes a GUI with a frame that covers the whole screen but with transparent areas? (A bit the way I was doing it with my game way back then). Technically it would still be Nifty having the focus.


You can kinda emulate it if you place a focusable element in the background, so when its clicked, that element will get all events (but instead of getting the events it should just ignore everything).

Not sure if I follow here.

somehow I have the feeling we might need all of this >_<