When using setVisible method to show an element, all child elements are set to visible as well. This seems as if it may not be doing what was intended.
I would think that each element would only render if the results of a recursive parent element search returned visible at the top-most layer.
The way it works now, it blindly sets all children to the same state as the parent.
Anyways… just an FYI. For the time being, I’ll override the setVisible method.
Working as intended.
I used that a lot in my main menu panel when I wanted all buttons to be disabled at the same time.
@madjack said:
Working as intended.
I used that a lot in my main menu panel when I wanted all buttons to be disabled at the same time.
Making use of it doesn't necessarily mean it is working as intended. If I set the visible state of a parent window to hidden, I don't want the window to show every child it contains when I set it back to visible.
i.e. A targeting window, displays stat indicators when something is targeted. I clear my target, the indicators are hidden (it is no longer bound to an object... but I will reuse the same visual component once a new target is acquired). I toggle the targeting window off and then back on... the indicator shows even though it is bound to nothing and the game state says you have no target.
I intentionally hide the indicator to minimize the dynamic creation of Nifty objects that I can just rebind. Why should showing the parent layer over-write the visible status of the child object?
My guess is this is not working as intended... and a rather easy fix to implement.
Actually… let me clarify that… If I set the state back to visible… I don’t want the children that were set to hidden to display also.
This almost calls for an “inherited” option for visibility as well as on/off…
@t0neg0d said:
Making use of it doesn't necessarily mean it is working as intended. If I set the visible state of a parent window to hidden, I don't want the window to show every child it contains when I set it back to visible.
I know that and yes in some cases you might want to have that behavior, but if you disable/visible off a panel that has other panels and buttons and blah blah, why wouldn't you want those children to be disabled/visible? The point of a panel is to group things that will (usually) be used together. Besides, void mentioned that it was a design choice and that it was working as intended.
@survivor said:
It is working "as intended" but not "as expected" by most people. See here. :D
To me it made sense. *shrug* :)
@madjack said:
I know that and yes in some cases you might want to have that behavior, but if you disable/visible off a panel that has other panels and buttons and blah blah, why wouldn't you want those children to be disabled/visible? The point of a panel is to group things that will (usually) be used together. Besides, void mentioned that it was a design choice and that it was working as intended.
In a normal GUI framework, i'd expect that things stay exactly like they were.
Lets see, we have a panel that contains some elements. Some buttons, a drop-down, and a checkbox. The checkbox only makes sense for certain entries in the drop-down. So, when a user changes the drop-down selection. i set the checkbox to hidden/visible depending on wether it is appropriate for that entry or not. So, the user cklicks some other things in the GUI and the panel gets hidden (for example if you decided to mimic something like a card-layout and tabs). If i set the panel ti visible again, i'd expect the checkbox to be in the exact same state i left it. Everything else makes no sense.
Yes, a recursive setVisible() method *might* be useful in *some* cases, but then it should have two params: setVisible(bool visible, bool recursive).
It wouldn’t surprise me if this is a limitation of the implementation rather than the design.
i.e. if the only way “setVisible(false)” works is to set every button inside it visible false as well then you lose the information as to whether it should be visible independently.
I’m not saying that is how or why it works but it’s just one theory.
For what it’s worth I agree with you about how I would expect it to work polygnome but it doesn’t seem like a massive hardship to update the visibility of sub components as required when making the top level visible.
@zarch said:
For what it's worth I agree with you about how I would expect it to work polygnome but it doesn't seem like a massive hardship to update the visibility of sub components as required when making the top level visible.
I agree, if you know it, you can live with it. But that does not make it good, it just makes it not that bad.
@zarch said:
It wouldn't surprise me if this is a limitation of the implementation rather than the design.
If hierarchy is being used (top to bottom) during rendering, there is no need to even attempt to render anything below the first element set to hidden. So there would be no need to change the visible state of anything contained by the hidden element.
If the render happens bottom to top... the a recursive parent call could get expensive.
I seriously doubt things are rendered bottom to top, so I can't see how this could be an limitation issue.
Whats the point in discussing speculations? Get the man in here 
@void256 whats the status on this? Is it here to stay as is?
I’m reporting back Sir @normen Sir that this issue is intended behaviour. At least for the current Nifty 1.3.x chain of commands. This problem has been discussed by high command in order 3283942, Sir.
If I’m allowed to speak freely, Sir, I’d like to add that this order is still in the status open. High command will probably consider changing this for upcoming Nifty 1.4 or 2.0 campaigns, Sir.
At your service, Sir! o7
2 Likes
Haha, excellent ^^