Roku Developer Program

[EnTerr]

roFontRegistry is descibed in two places in SDK - once in BrightScriptReferenceManual.pdf as

Boolean Register(String path)
roArray GetFamilies(Void)
Object GetFont(String Family, integer size, Boolean bold, Boolean italic)
Object GetDefaultFont(integer size, Boolean bold, Boolean italic)
Object GetDefaultFont()
Integer GetDefaultFontSize()

and another time in ComponentReference.pdf, this time as

Boolean Register(String path)
roArray GetFamilies(Void)
String Get(String Family, integer size, integer weight, Boolean italic)

I find the difference confusing, can someone explain what's going on?

There also seems to be duplicated functionality in

' roFontMetrics (from Component Reference guide) 
roAssociativeArray Size(String stringToDraw)

' vs analogous roFont (from B/S Reference) 
Integer GetOneLineHeight()
Integer GetOneLineWidth(String text, Integer MaxWidth)

[TheEndless]

I don't think the documentation in the Components reference is valid anymore. I believe with 3.0, the BrightScript reference version took precedence, and the component reference version is for legacy purposes only (i.e., it'll still work for backwards compatibility, but shouldn't be used moving forward).

[EnTerr]

"TheEndless" wrote:
I don't think the documentation in the Components reference is valid anymore. I believe with 3.0, the BrightScript reference version took precedence, and the component reference version is for legacy purposes only (i.e., it'll still work for backwards compatibility, but shouldn't be used moving forward).

The separation in two parts is weird, as long as we look only from RokuDVP point of view. It's illogical to proclaim roScreen, roAudioResource etc as part of BrightScript "Core", since all the other UI elements are in the "Component" manual. If this is not due to negligence, then perhaps there is another reason/pragmatic criteria what-goes-where in those manuals, as say: all things shared between B/S platforms go to "BrighScript"/core, things unique to DVP go to "Streaming Player Components". Those UI elements popping for the first time in "core" would thus imply they be shared with the other platforms (BrightSign? something else?)

I have skimmed both manuals end to end and have to say the situation with roFontRegistry is untypical for Roku writing. Deprecated methods tend to be marked as such, plus justification why. In this case while two APIs don't contradict directly, they seem to duplicate functionality - in one case using string as a handle, in the other roFont.

I'd like clarification from Roku, who do i shout to - RokuJoel?

[RokuKevin]

The way components are divided between the Brightscript Reference and the Component Reference has to do with whether the component is supported in all Brightscript implementations. In addition mass market Roku Streaming Players, there is another company (BrightSign) using Brightscript in commercial signage and kiosk solutions.

Components supported in core Brightscript exist on both of these platforms and are documented in the Brightscript Reference. Components that are platform specific to Roku are documented in the Component Reference.

I agree the documentation of roFontRegistry is confusing and we will clean it up in a future version. The actual implementation supports both interfaces, in the Component Reference and the Brightscript Reference. roFontMetrics is also still supported and is used to support drawing text on the roImageCanvas.

When drawing text on an roScreen, you should always use the roFont as documented in the Brightscript reference. So the best way to think of them is to use the Brightscript Reference documentation for drawing on an roScreen and the Component Reference documentation for drawing on an roImageCanvas.

--Kevin

[EnTerr]

aha, so my gut feeling about manual organization was right.

thanks RokuKevin - your explanation is quite complete and makes it clear which is what!