Hola, la forma de leer y escribir los settings desde ncl es mediante un objeto media de tipo application/x-ginga-settings. Entonces si se quiere definir una variable se puede realizar de la siguiente manera: <media id="misVariables" type="application/x-ginga-settings"> <property name="nombreDeVariable" value="unValor"/> </media> Por otro lado hay variables de sistema o usuario, por ejemplo la edad del usuario que está utilizando el STB. Un ejemplo de como leer esta variable podría ser en la definición de una regla: <ruleBase> <rule id="esMayor" var="user.age" comparator="gt" value="18" /> </ruleBase> y esa regla se podría utilizar en un switch para decidir si mostrar o no un contenido. Ahora bien, quien debe mantener estas variables a mi entender es el firmware del STB, dado que el mismo es el que tiene la información sobre el usuario, control parental, OS, etc. slds! 2010/12/23 Ezequiel García <[email protected]>
Hola,
Quisiera saber si alguien tiene idea de como se pueden leer y escribir los "media" tipo "property" en la implementación Ginga.ar 1.1.0. En el documento "NORMA BRASILEÑA ABNT NBR 15606-2" (que se puede bajar, yo lo encontré por Google) se especifica lo siguiente:
10.3.4 Módulo settings Exporta la tabla settings con variables definidas por el autor del documento NCL y variables de ambiente reservadas, contenidas en el nudo application/x-ginga-settings. No se permite atribuir valores a los campos representando variables en los nudos settings. Un error debe ser generado en el caso que ocurra un intento de atribución. Las propiedades de un nudo settings solo pueden ser modificadas por medio de eslabones NCL. La tabla settings particiona sus grupos en varias subtablas, correspondiendo a cada grupo del nudo application/x- ginga-settings. Por ejemplo, en un objeto NCLua, la variable del nudo settings “system.CPU” es referida como settings.system.CPU. Ejemplos de uso: lang = settings.system.language age = settings.user.age val = settings.default.selBorderColor settings.service.myVar = 10 settings.user.age = 18 --> ERRO!
Sin embargo, en los programas de ejemplo que he intentado hasta ahora, la variable settings es siempre "nil". Lo mismo vale para el módulo "persistent".
Quisiera saber si alguien tiene idea como es la sintaxis que permite acceder a estas variables desde NCL y/o Lua. Parecería que quizás las mismas no están implementadas en Ginga.ar 1.1.0, pero un vistazo rápido a los fuentes demuestran lo contrario.
De hecho si hacemos un grep de "SYSTEM_OPERATING_SYSTEM" obtenemos:
$ grep -r "SYSTEM_OPERATING_SYSTEM" .
(Entre otras cosas) ./gingancl/src/adaptation/context/.svn/text-base/PresentationContext.cpp.svn-base: (*contextTable)[SYSTEM_OPERATING_SYSTEM] = si->getOperatingSystem();
Es decir que la variable SYSTEM_OPERATING_SYSTEM (que se mapea al campo system.operatingSystem del módulo settings) obtiene su valor del método getOperatingSystem(). Veamos pues que tiene ese método:
En el archivo "gingacc-contextmanager/src/system/SystemInfo.cpp" encontramos:
string SystemInfo::getOperatingSystem() { return sn.sysname; }
Y a su vez, esta variable se inicializa con la función uname() (ver man 3 uname). Como verán las propiedades están implementadas. Ahora bien, ¿cómo se acceden?
Saludos, Ezequiel.
_______________________________________________ Ginga-argentina mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/ginga-argentina
-- Alejandro Alvarez