RS11 - Agregar submenú de análisis/coloreo al menú de pausa

[elarielcl]

El submenú debe ofrecer :

• Diferentes opciones de análisis(PMD, Cobertura, CheckStyle, Git).
• Opciones de configuración propias de cada análisis.
• Opciones acerca del coloreo.

[FrancoPinoC]

Concept Location: En Terasology, uno de los botones dice “Return to Menu” así que buscamos por este texto en la opción File Search de Eclipse.

• Se llegó a “engine\src\main\resources\assets\ui\ingame\pauseMenu.ui”. Un archivo “.ui” donde se definen los botones, su “id” y el texto que muestran.
  • Cada definición de botón está entre corchetes (“{“, “}”) y usa tres parámetros; las definiciones van separadas por comas. Un ejemplo de una definición de botón:

                  {
                  "type" : "UIButton",
                  "id" : "exit",
                  "text" : "Boton"
                  }
    

• Si bien se encontró dónde se definen los botones en un sentido de alto nivel (la UI), debe encontrarse todavía donde se define su comportamiento. Se sabe que el parámetro “id” indica el comportamiento del botón (usando el ejemplo: “exit” quiere decir que el botón termina el juego al ser presionado), así que debe buscarse qué es lo que este parámetro referencia y ver cómo este llama al método adecuado.

[FrancoPinoC]

"Concept Location parte 2, la venganza":

Se quiere buscar dónde se definen los comportamientos de los botones del menú de pausa, el archivo pauseMenu.ui no es una clase de Java, no podemos usar opciones de jerarquía/declaración, entonces para esto, en Java Search de Eclipse se buscó “pauseMenu”

• Esto nos llevó al paquete org.terasology.rendering.nui.layers.ingame, a la clase PauseMenu, en donde podemos ver que se definen los comportamientos relacionados a las “id” antes mencionadas.
  • En PauseMenu los comportamientos de las ID se definen de la siguiente forma:

     WidgetUtil.trySubscribe(this, [id], new ActivateEventListener() {
        @Override
        public void onActivated(UIWidget widget) { [// do stuff] });

    Donde [id] debe ser un String, que es el que se usa en pauseMenu.ui para encontrar el comportamiento del botón (por ejemplo, “exit” o “mainMenu” que coresponden a las ID de los botones Exit Terasology y Return to Menu respectivamente).

[FrancoPinoC]

Concept Location 3: Ya sabiendo donde se definen los comportamientos, queda saber cómo definir un nuevo menú de botones al que se pueda acceder a través de un botón en el menú de pausa.

• Se comenzó viendo en la misma clase PauseMenu, pues se sabe que el botón “Settings” hace esto. Desde el cuerpo del método que define el comportamiento de este botón, se pudo ver que se accede al nuevo menú a través del método “pushScreen”.
• Se usó la opción “Declarations” de eclipse sobre este método para buscar su definición.
• Se llegó al paquete package org.terasology.rendering.nui.layers.mainMenu, a la clase SettingsMenuScreen.
• Entonces con esto debemos analizar como funciona el pushScreen en esta clase para poder usarlo como base para hacer un submenu de coloreo.

[emoreno-94]

Apoyándose en lo anterior se encontraron los archivos necesarios para editar el menú de pausa, con lo cual se pudo añadir el botón de coloreo.

[emoreno-94]

Se agrego el sub-menu de coloreo el cual posee los botones de las distintas opciones para colorear. Por defecto se dejo que todos los botones realizaran la acción "full screen"

[emoreno-94]

Para agregar la funcionalidad a cada botón se debe modificar el archivo /engine/src/main/java/org/terasology/rendering/nui/layers/mainMenu/ColoringMenuScreen.java, donde se tendran metodos del tipo:

 WidgetUtil.trySubscribe(this, ***NOMBRE_COLOREO***, new ActivateEventListener() {
            @Override
            public void onActivated(UIWidget widget) {
                /* AQUÍ VAN LOS COMANDOS */
                CoreCommands c = new CoreCommands();
                c.fullscreen();
            }
        }); 

[FrancoPinoC]

Por el momento los submenús y los botones de cada coloreo están definidos en el engine, mientras que los comandos de cada tipo de coloreo están definidos en su propio module. Los modules están hechos para extender Terasology, de modo que, en principio, los modules pueden conocer el código base, pero el código base de Terasology no debería conocer explícitamente a los modules, así que cabe preguntarse:

Cómo recuperar y ejecutar los comandos de los modules sin tener que acceder a ellos:

. . .
@In 
private Console console; // variable de instancia
. . .
ConsoleCommand ca = console.getCommand(new Name("CoberturaAnalysis"));
List<String> params = new ArrayList<String>(); // Lista de parametros
[Rellenar lista]
EntityRef e = null;
try {
    ca.execute(params, e);
} catch (CommandExecutionException e1) {
    [Manejar error]
}

Cuando se añade un comando por medio del sistema de anotaciones, Terasology permite acceder a un objeto ConsoleCommand con la lógica de ese comando por medio de una "Console" (es como el comando "help" obtiene los nombres y descripciones de todos los comandos, incluyendo los que se encuentran fuera del engine, en modules).

Entonces, se usa el método getCommand([Nombre del comando]) en la variable console, el parámetro que se le da es un "Name", que representa el nombre del comando (basta instanciar un Name usando un String con el nombre del comando como parámetro).

Una vez se un obtiene el objeto que representa el comando deseado, basta aplicar execute en este para ejecutarlo. execute recibe dos parámetros: Una List con los valores de los argumentos para el comando (los que se le dan al usarlo en la consola de Terasology) y un "EntityRef" (basta que sea null para nuestros propósitos).

(ejemplo de implementación aquí )

[elarielcl]

Dado que el submenú fue creado por cada coloreo por separado, el submenú de coloreo se redujo a un menú con botones con un link a cada uno de los subsubmenús implementados por cada grupo de coloreo