Developers

[hclapp_1]

Really its getting confused while working with component xml. What's the use of <Interface> in XML

<interface >
    <field id = "description" type = "string" onChange = "showdescription" /> 
  </interface>

Please explain 

[EnTerr]

The <interface/> element in XML descriptors for RSG is just a way to declare additional fields for the custom component you are writing. In a rather vague sense they are akin to interfaces of modules when doing OOP - and declaring which methods you want exposed to the external world. Except there it is parts of code/behavior that you expose and here is just data.

[belltown]

Interfaces are a way of communicating between components, a way to pass data between components.

A component can write to an interface field, or read from an interface field, or both.

One use would be for one custom component to set some property of another custom component. To do this, one component writes a value to the interface field of the other component, which the other component then reads when it is notified (using an event observer) that the value of the interface field has changed.

Let's say you have a component (ComponentA) that contains a Label component, and you want to set its text from another component (ComponentB).

In ComponentA.xml, you'd have a Label whose text you want to change defined inside the <children> element:

<Label id="idLabel" />

In ComponentA.xml, you'd define an interface field along with the name of the event observer function that will be executed when the field value changes:

<interface>
    <field id="labelText" type="string" onChange="onLabelTextChange" />
</interface>

  
In ComponentA.brs, you'd set up a reference to the Label field:

sub init()
    m.label = m.top.findNode("idLabel")
end sub

In ComponentA.brs, you'd define an event observer that gets executed when the value of labelText changes, by referencing the interface field:

sub onLabelTextChange()
    m.label.text = m.top.labelText
end sub

To change the text of ComponentA's label from ComponentB, you'd set up a reference to ComponentA in ComponentB.brs:

sub init()
    m.componentA = m.top.findNode("ComponentA")
end sub

Then set the value of the interface field somewhere in ComponentB.brs:

m.componentA.labelText = "Hello, World!"

[EnTerr]

Great examples @belltown, only a clarification - what you explain is tad different from the exact question. It asked about <interface/> - you answered about <field/>. The same can be done without <interface/> or XML for that matter. The XML part here is just syntactic saccharin ("... causes cancer of the angle-brackets" )

Thanks to your answer it just dawned on me the nasty name clash that Roku Scene Graph's unfortunate choice of name <interface/> has with BrightScript interfaces. Even worse, it clashes with RSG's own... Scene Graph Interfaces!

For new developers that don't know the history of SDK1 and SDK2, that will be mind-blowing moment
[spoiler=mind blown:32l3tjk1][/spoiler:32l3tjk1] No siree - i am deciding that for the common good i'll restrain from referring to roSgNode fields as "interface fields".

[belltown]

"EnTerr" wrote:
Great examples @belltown, only a clarification - what you explain is tad different from the exact question. It asked about <interface/> - you answered about <field/>.

Good point, but I was just trying to keep it simple, maybe not comprehensive. Until recently, all you could put in an <interface> was <field> elements, so I figured that would get the OP started on understanding what to do with them. The Roku documentation, although giving a description of an <interface>, is a little thin when it comes to what you do with them. I though a simple example might give some context.

I'm still trying to figure all this stuff out myself. I'm finding that a lot of it only makes sense to me when I see things in the context of actual code. For instance, I've read the "Thread Rendezvous" stuff about 10 times, but still haven't got the foggiest idea what it's talking about.

[EnTerr]

"belltown" wrote:
I'm still trying to figure all this stuff out myself. I'm finding that a lot of it only makes sense to me when I see things in the context of actual code. For instance, I've read the "Thread Rendezvous" stuff about 10 times, but still haven't got the foggiest idea what it's talking about.

Oh, that one is a riot! I have already rated it "the darkest, scariest corner of RSG" (with befitting clip from "The Empire Strikes Back"), which was leading to the "2nd most crippling mistake of RSG". That problem has been hastily plastered and repainted over in 7.5 by disabling rendezvous timeouts - which in turn leads to new but arguably less damaging problems (see BUG-0025 "Debug rendezvous with Godot" in the Centercode beta if you enrolled).

It was actually easier to explore the threads before with the multiple consoles - i like the idea of the new integrated console but the rendezvous just don't work there because all threads are stopped. Probably best learning if you have pre-7.5 fw somewhere. I found the
getAll(), getRoots(), getRootsMeta(), getAllMeta() of ifSGNodeChildren insightful when exploring.

[belltown]

"EnTerr" wrote:

It was actually easier to explore the threads before with the multiple consoles - i like the idea of the new integrated console but the rendezvous just don't work there because all threads are stopped.

I'm really not liking the intermingled console so far. I was much happier when all my tasks had their own debug ports, and I could set up a separate tab or window for each one. Now my 8085 window is just a jumbled mess. Even my screensaver tasks all output to 8085.

[EnTerr]

"belltown" wrote:
I'm really not liking the intermingled console so far. I was much happier when all my tasks had their own debug ports, and I could set up a separate tab or window for each one. Now my 8085 window is just a jumbled mess. Even my screensaver tasks all output to 8085.

Regretably (since i liked the idea of single console), true - if there were multiple consoles, an IDE could ostensibly merge them into one stream if it wants to - and even prep-ending them with the thread (or port) ID, i.e.

0: i am Main thread
0: blah de blah
1: and i am rendition thread

That's easy to fix but debugging between threads is impossible now because of the all-stop and the threadlocks (rendezvous)