Add gui.get and gui.set

[Jhonnyg]

Gui scripts can now query/set node properties via gui.get and gui.set:

local node = gui.get_node("my_node_id")
local node_pos = gui.get(node, "position")
local node_pos_x = gui.get(node, "position.x")

gui.set(node, "position", vmath.vector3(1, 2, 3))
gui.set(node, "position.x", 1)

We have also added a new property to the gui namespace euler which is linked with the rotation property. When changing one of them, both will change its underlying data. The important change between them is that the rotation property must be set by quaternion values, and the euler property must be set by degree values. You can set a single component of the rotation or the euler properties as usual:

gui.set(node, "rotation.x", math.rad(45))
gui.set(node, "euler.x", 45)

There are no custom script properties available, you can only get and set the already existing node properties:

"position"
"rotation"
"euler"
"scale"
"color"
"outline"
"shadow"
"size"
"fill_angle" (pie)
"inner_radius" (pie)
"slice9" (slice9)

Fixes #5090

[Jhonnyg]

Note about rotation:
For go.get/set we support quaternions for e.g rotation. But for gui when using gui.set_rotation and gui.get_rotation we still use euler angles, so we should probably still support that here as well?

[JCash]

I think this is a good question.
I believe it will be harder to "fix" later on, if we want ppl to merge their code/functions from GUI into GO space.

So, it might be better to return quaternions here?

Let's ask the others in the team as well!

[matgis]

Perhaps we could expose euler_rotation as a separate property and have rotation operate on quaternions like we do in other places?

I think we should look over the other properties as well to ensure their values are consistent with their go counterparts. I.e. the same property on a go vs a gui returning Vector3 values vs Vector4 values or similar discrepancies.

[AGulev]

Perhaps we could expose euler_rotation as a separate property and have rotation operate on quaternions like we do in other places?

If we do so, it's a breaking change then

Currently expected beh. for devs in gui is euler (because this is what gui.get_rotation() and gui.set_rotation() do). I think for now it's better to keep it this way.

[matgis]

I'm not suggesting we change the behaviour of gui.get_rotation() and gui.set_rotation(). I'm simply suggesting that we make the new gui.get(node, "rotation") and gui.set(node, "rotation", value) return and take a quaternion value respectively.

So it would be inconsistent with the existing gui.get_rotation() and gui.set_rotation() functions, but not a breaking change.

[AGulev]

it feels strange

[JCash]

Well, to me it feels like it will feel strange either way (i.e. it won't behave the same as go.get)
Do we have any other votes?

[AGulev]

if we do so, we have to introduce euler in this PR (as well as it is in go.*)

[Insality]

Is gui.animate(node, "rotation", ...) still work in euler values?

Sounds a little bit strange, that leads to additional logic if I want to make a wrappers around all these functions (gui.set, gui.set_rotation and gui.animate)

[JCash]

Looks good.
I'd like to see some restructuring of the Set method

[JCash]

I think this is a good question.
I believe it will be harder to "fix" later on, if we want ppl to merge their code/functions from GUI into GO space.

So, it might be better to return quaternions here?

Let's ask the others in the team as well!