Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
Trying to read on RSG, i can't help but notice there are so many weird contraptions in Roku's xmlography that remind me the saying:
To wit, the just documented magic XML attribute "role", described understatedly as:
Translation: because XML cannot have structured attribute values (only strings), let's flex shoving head between the legs. I found a good visual for the situation - it's yoga's Karnapid asana:
[spoiler=Karnapidasana:3pbguhi7]
[/spoiler:3pbguhi7] In fact t seems such a good fit, that i propose Karnapidasana for official logo of Roku Scene Graph! Check out the "interface fingers" - such a nice touch.
You'd think the Maker of RSG would have wisened up the first time they scribbled down something like:
What's the alternative, you may ask? Using pure BrightScript for SG instead of XML comes to mind - B/S nested structures have none of the XML limitations - nor for that matter would you have to write your functions into <![CDATA[ ]]> text blobs nor exile them to different files (cue yoga uri-asana).
Couple of months ago I whipped a sample BrightScript syntax for SG in an afternoon - mind you, not the only approach but a reasonable one - and would have implemented and using it by now if the "BrightScript/XML Markup Equivalence" were complete - which it isn't. RSG remains belligerently hostile to BrightScript functions^ - they are not allowed as field types, get stripped on structure copy, can't pass them between threads nor re-assign them to events like init() and onKeyEvent()...
(^) even as functions in B/S are literals, completely lacking context/closures - the one true advantage, a blessing-in-disguise that BrightScript has here over all other scripting languages i know. In Python, Lua, Javascript, Ruby, you-name-it - functions drag with them lexical scope entrails, not so in B/S - Brightscript function's byte-code could cross unchanged (or even be shared) between different VM instances. B/S functions are immutable and context-free, so clean for the purpose of multithreading - it's beautiful! And RSG squanders that - why? Is it resentment by the "XML people" for the "BASIC people"?
The difference between a clever man and a wise man is that
- the clever man can extricate himself from difficult and intricate situations that
- the wise man would never have gotten into in the first place
To wit, the just documented magic XML attribute "role", described understatedly as:
The Scene Graph node markup elements contained in the <children> element may include a special XML element attribute, role. The role attribute allows a node element to be defined as a child node of a parent node, and the child node to be assigned as the value of the parent node field identified by the role attribute value
Translation: because XML cannot have structured attribute values (only strings), let's flex shoving head between the legs. I found a good visual for the situation - it's yoga's Karnapid asana:
[spoiler=Karnapidasana:3pbguhi7]
[/spoiler:3pbguhi7] In fact t seems such a good fit, that i propose Karnapidasana for official logo of Roku Scene Graph! Check out the "interface fingers" - such a nice touch.You'd think the Maker of RSG would have wisened up the first time they scribbled down something like:
translation = "[130, 160]"Shiver me timbers, structures in strings surely give me pause. But apparently not to the Maker, who'd rather extricate himself with wickedly clever hacks from a corner where a wise man would have never painted himself in the first place. Roku's "SDK2.0" is full of valiant contortions in attempt to (a)dress the self-inflicted wounds of committing to XML for SG!
rowItemSize = "[ [536, 308] ]"
What's the alternative, you may ask? Using pure BrightScript for SG instead of XML comes to mind - B/S nested structures have none of the XML limitations - nor for that matter would you have to write your functions into <![CDATA[ ]]> text blobs nor exile them to different files (cue yoga uri-asana).
Couple of months ago I whipped a sample BrightScript syntax for SG in an afternoon - mind you, not the only approach but a reasonable one - and would have implemented and using it by now if the "BrightScript/XML Markup Equivalence" were complete - which it isn't. RSG remains belligerently hostile to BrightScript functions^ - they are not allowed as field types, get stripped on structure copy, can't pass them between threads nor re-assign them to events like init() and onKeyEvent()...
(^) even as functions in B/S are literals, completely lacking context/closures - the one true advantage, a blessing-in-disguise that BrightScript has here over all other scripting languages i know. In Python, Lua, Javascript, Ruby, you-name-it - functions drag with them lexical scope entrails, not so in B/S - Brightscript function's byte-code could cross unchanged (or even be shared) between different VM instances. B/S functions are immutable and context-free, so clean for the purpose of multithreading - it's beautiful! And RSG squanders that - why? Is it resentment by the "XML people" for the "BASIC people"?
