We had a question come in regarding best practices for buttons.
This was about the Fullscreen button which has two buttons that will show the two different states, Enter and Exit Fullscreen.
The e-mail then when on to ask should the actions be in each button with actions to also hide and show the other button, so creating a toggling effect between the two.
I thought this was a good question and to this end bring your attention to the default skins, namely the Silhouette V6 skin.
If you open it up in the skin editor and scroll down to the "controller" container and expand it in the tree you will see "controller_slider", also expand this in the tree.
What you will see is the buttons that have different states such as Fullscreen are in containers.
The Skin was designed so that if you wanted you can map the keyboard to the buttons.
Looking at the Fullscreen button, the container, "fullscreen_buttons" has the one action which is Toggle Fullscreen. So a single key can be mapped to it, in this case, I have mapped the F key.
The buttons change by using the Alpha logic block using the trigger Fullscreen.
So if Fullscreen is true the Enter Fullscreen button hides by changing the alpha to 0.00 and the Exit Fullscreen button shows.
Otherwise, if the actions were in the buttons then you would need to map two keys.
This gets a bit more interesting if there are more than two states, for example, the Projections button.
This has three states but to be able to still use a single keyboard key it uses action filters.
If you look at the last three actions in the container, projection_buttons you will see that there is a mouse click, change projection for each projection type.
So not all three projections are select at once there are actions filters in the actions. This is denoted by the *
The panorama opens in the Rectilinear Projection.
The first action to change to Stereo has the action filter:
So only this action will be actioned as the others have different projections:
The second action has the filter:
And the last has:
So in this case, because we wanted you to be able to map the keyboard to the buttons this was the best practice for the default skins.
I hope this has given you a bit of insight into the thought process behind this skin and gives you food for thought when building your own, more so when building components to use with other projects.
Special forum to share and discuss skins for Pano2VR and Object2VR
1 post • Page 1 of 1