SUMaterialGetDisplayName()

[tommash]

1. I would like to read a material name exactly the way it is displayed in SketchUp in live content. Neither GetName() nor GetNameLegacyBehavior() return correct localized name for all built-in SketchUp library materials in localized versions.

To get the correct name we have to first check whether material name is enclosed in the square brackets, then go back to Ruby, find material by .name and read .display_name from it, which is slow. We can alternatively go through Materials.strings list and do the translation of [MaterialName] ourselves, but this is even more exotic.

2. A new function SUMaterialGetDisplayName() looks like a reasonable solution, at least for a live model case.

In case of standalone/external use of the SDK the function could return same string as GetNameLegacyBehavior(), if it would be a problem with supplying the Materials.strings with the SDK.

[DanRathbun]

Could the "Materials.strings" file be converted into a C enumeration for use with the standalone SDK ? Ie, one file for each language and the enduser loads which ever file is needed.

[thomthom]

The list of language that SketchUp support isn't likely to match the list of languages any host application using the standalone API.

I think we'll defer that and focus on getting the Live C API to return the string the SU client is using.

[DanRathbun]

I think we'll defer that and focus on getting the Live C API to return the string the SU client is using.

There's no doubt the live C API will need this.

The list of language that SketchUp support isn't likely to match the list of languages any host application using the standalone API.

Perhaps, but this does not mean that the available set of SketchUp language "Materials.strings" files cannot (or should not) be used by standalone C API users. It is a bit difficult as these language resource files have not been included with the SDK packages. (This means a user needs to download every installer and extract them.)

These users could (as said above) mimic how the Ruby API LanguageHandler class reads the files into a "hashlike" structure for lookups.

Here's example code for the C lookup "bucket" tables ... https://github.com/jamesroutley/write-a-hash-table

But it occurs to me that there should be a way (perhaps using a Ruby script) to read the strings files and build the resource tables for a C program once per release, instead of each and every time a 3rd party application is loaded (or each time a SKP file is imported.)

So how in this case would it be done? With a DLL / DYLIB loaded on demand from set of pre-built language resources ?

[thomthom]

So how in this case would it be done? With a DLL / DYLIB loaded on demand from set of pre-built language resources ?

Not sure, it gets complicated fast to manage these translations outside the client. So it's a much bigger task than handling the Live C API. Would require some research effort.

[DanRathbun]

Perhaps a community GitHub library as an standalone C SDK extension ?

[sketchupbot]

Logged as: SKOR-13725