Hello Everyone, Hope yours are all well,
Here I’m back with one of my inputs I know you Guys love;) I here and then, continue to monitor the inspector and output from the recorded and lately I found this one:
" Anyone noticed that from whatever you change for the GUI controls (in this case, a button BABYLON.GUI.Button.CreateSimpleButton), you do not get anything from the recorder in the PG "
I started a recording and next applied, in order, the following changes to the button and scene:
‘color: black’; lineSpacing: “10px”; (and actually you can add more or I believe any parameters for this GUI control)
To make sure I also record a change in the scene, I select the sphere node and apply a rotation to it.
End of record and this is what I get:
{“meshes”:[{“rotation”:[0,2.539454061651749,0],"__state":{“id”:“sphere1”}}]}
Obviously, this doesn’t really help me if I wanted to retrieve the information for my GUI/control, does it?…
In case, shouldn’t there be a mention somewhere that these type of interactions are not recorded (or not recorded here or not with this method…?) Just wanted to let you know of this finding that could possibly create ‘frustration’ among users (though I, personally, don’t really need it). But somehow, it looks and ‘tastes’ like it is there and somehow, it’s not… just my opinion and feeling.
Have a great week-end,
It will only record simple changes. Creating a new GUI system is definitely part of it unfortunately because GUI is not stored in a scene state (When you save a .babylon file, GUI is not serialized)
Yes, I certainly do understand this part with ‘#limitation’ and also with ‘#sustainability’.
The point is, it did it (for the GUI) with the (r.i.p, pseudo-code.
The handling of the BJS GUI can be quite cumbersome in some aspects and I guess one would really need to try or fine-tune with the Inspector/PG (since it is there). But then, zero way to even just get the correct name or declaration. Not to mention that some text parts (headers) of the interface use a different name than the actual API name. Next, all you can do is either go to the API, check the doc or attempt type/guess in the PG until you get the correct one. And for the values, all you can do is retype them in your codeI from what you have set in the Inspector.
Conclusion: It’s just somehow frustrating to have it right there, but cannot retrieve… Again, knowing that you have it in the API description as well as most of the doc as well as in the PG (code-side).
May be an idea would be to add a helper on the header/label of those ‘unhanded’ parameters that would simply display the correct name/form?…
Don’t expect anything ‘spectacular’ though. As I said, it’s basically reviewing some labels/headers (and eventually add a helper). This is really about ‘consistency’ because most of the names of categories, headers&labels actually match the API name (in english language). Most’of em…
Second part of my suggestion is still about #consistency and #ux/cx:
It would be around trying to find an easy (and sustainable) way to lower the impact of the ‘unhanded’ parts (VS the very complete and enjoyable ‘handed’ part) by ‘easing’ the work (and basically look backs). I mean, in the inspector, I can always rely on the shown class and ID. It gives me the right class and ID. And ID (label) is ID. And (class) label is class. Which means, I’d expect my (any element shown in the inspector) to be the equivalent for name, class or id. But, it is not. Not always.
pseudo-code.