LLops Blog

Una vez comentados los motivos por los que de momento no voy a prescindir de FlashDevelop en Mac, toca explicar cómo lo tengo instalado yo y que workflow utilizo para que sea cómodo trabajar con Flash Professional.

 

Virtualización

Como no hay magia que valga, lo primero es hacerse con un programa de virtualización para instalar Windows. Los dos más conocidos son VMware Fusion y Parallels Desktop.

Cuando me pasé a Mac estuve leyendo bastante sobre ambos. Al final me acabó convenciendo más el primero, así que me compré una licencia de Fusion. Sin entrar en comparaciones, Fusion arranca bastante rápido, soporta copy/paste y drag&drop entre sistemas operativos, puedes acceder a las mismas carpetas desde ambos lados y tiene alguna otra característica interesante que ahora veremos.

No explicaré el proceso de instalación porque no es muy complicado y hay mucha información en la red, únicamente detallaré mi configuración por si sirve de ayuda.

 

Configuración de Windows y VMware

Yo tengo instalado un Windows 7 de 32 bits, FlashDevelop y poco más. Obviamente, si se necesitan más programas pues no pasa nada, pero es importante no tener procesos que se inicien en el arranque consumiendo memoria inútilmente, así que mejor instalar sólo lo imprescindible. Desaconsejo totalmente antivirus, ya que me parece muy difícil infectarse sin instalaciones ni navegación. Si se es muy desconfiado en este aspecto, mejor desactivar internet en Windows.

Importante desactivar el tema Aero, que para nuestro caso es absurdo. Yo utilizo el tema Windows 7 Basic y queda más que bonito. Y si no quieres dedicar ni un recurso a la estética, en "Herramientas de rendimiento", "Ajustar efectos visuales", activas "Mejor rendimiento" y te lo deja pelado.

En cuanto a la configuración de VMware, lo más relevante:

• Compartir: útil si vas a trabajar en Windows, ya que podrás acceder a cualquier directorio de Snow Leopard que añadas.
• Aplicaciones: aquí podemos añadir un acceso directo de FlashDevelop al Dock.
• Procesador: 1 núcleo. Esto quiere decir que el sistema virtual utilizará un nucleo del procesador, pero no de manera exclusiva. Nuestro Mac continuará utilizando los dos.
• Memoria: 1024 MB. En este caso la memoria sí que se reserva entera, es decir, que cuando Windows esté corriendo tendrá 1 giga reservado que no podrá utilizar Snow Leopard. Con Aero desactivado, para correr Windows y FD hay más que de sobras, así que no os preocupe darle "un poquito más" de este mínimo.
• Pantalla: sino tenéis dependencia de DirectX 9 (para juegos) ni utilizáis Aero, desactivar la opción "Acelerar Gráficos 3D".
• Disco duro: yo tengo una partición de 40 gigas, pero realmente bastaría con el espacio de Windows y poco más. Siempre es interesante cubrirse un poco para la memoria virtual, por si tomas muchos snapshots, porque al final siempre se acaban instalando cosas...

Una de las ventajas de virtualizar es que si la máquina no está corriendo, se puede cambiar toda la configuración, así que no tengáis miedo de ir probando configuraciones hasta que os sintáis cómodos. Pero si no queréis perder tiempo, con lo ya comentado, en un MacBook Pro Core 2 Duo de 2'66 y 4 gigas de ram, corriendo Windows 7 con FlashDevelop, más Flash, Chrome, Safari, Spotify y unos cuantos programas "menores" más, el ordenador "vuela" :)

Y un último apunte: cuando no se trabaje con la máquina virtual lo más cómodo y rápido es suspenderla, no apagarla, recuperando todos nuestros recursos y pudiendo volver luego en segundos.

 

Modo Unity

Una de las cosas más agradables y útiles de Fusion es su vista "Unity". En este modo, el escritorio de Windows desaparece y las aplicaciones aparecen como una ventana más de Mac. Perfecto, ¿no?

Y como comentaba antes, hacer un drag&drop de archivos, un copy&paste o cualquier típica operación entre programas funciona a la perfección. Un gran paso para sentirnos como si estuviéramos en un único sistema.

 

En busca del workflow perfecto

A pesar de que así está todo bastante integrado, falta una cosa básica: poder ejecutar películas en Flash desde FlashDevelop. Al principio pensé que mucha gente habría buscado una solución a esto y no sería difícil. No estaba equivocado ni nada...

Parece ser que en Parallels se puede instalar una herramienta llamada "Shared Applications" que te permite mapear programas, con lo que se puede configurar en FD la ruta a Flash.app (también vi que está lejos de ser perfecto y que muchísima gente tenía problemas). Desgraciadamente, en Fusion no existe nada similar.

Así que me puse a darle vueltas a la cabeza hasta encontrar un camino.

 

QuickSilver

QuickSilver es un programa que mucha gente del mundo Mac considera imprescindible y que sirve para lanzar aplicaciones rápidamente (esta es la utilidad más básica, realmente puede hacer mil cosas). Por ejemplo, yo para ejecutar Flash CS4 no lo busco en Aplicaciones ni el Dock, simplemente hago cmd+space, tecleo Fl y enter. Al principio puede parecer tonto, pero cuando te acostumbras no hay vuelta atrás.

Me acordé que el programa tiene un apartado llamado "Triggers" e indagé un poco. Un trigger permite asociar una acción (abrir una aplicación, correr un script, etc) a una combinación de teclas. Pensé que si podía correr un script funcionaría también con un jsfl... ¡y bingo!.

Así que abrimos Flash, creamos un nuevo archivo del tipo "Flash Javascript File" y escribimos la siguiente linea:

Lo guardamos en el escritorio como testmovie.jsfl

Ahora abrimos QuickSilver, vamos a "Preferences" y activamos la opción "Enable advances features" (no estoy 100% seguro que sea imprescindible, pero por si acaso). Después vamos al menú "Triggers", añadimos uno nuevo (parte inferior, en el +, "HotKey"), y nos sale una nueva ventanita. En "Select an item", sólo hace falta empezar a teclear el nombre de nuestro archivo y QuickSilver lo encontrará y nos pondrá por defecto la "Action" de "Open". Guardamos.

Nota: si al empezar a escribir no nos detecta el script seguramente sea porque no lo tiene indexado todavía. En el menú, junto a Triggers, hay una opción llamada "Catalog". Buscamos nuestra ubicación, en este caso Desktop, la seleccionamos y en la parte inferior, clicamos en el icono de refrescar (Rescan Source). Debería aumentar el número de elementos indexados. Ahora seguro que ya encuentra nuestro archivo.

Nota: QuickSilver no indexa todo el disco duro, sino que tiene unos directorios por defecto (el escritorio es uno de ellos). Si prefieres agrupar tus scripts en otro directorio tendrás que incluirlo a mano. Esto se hace también en "Catalog", en "Custom". Ahí añadimos un archivo o carpeta. Atención que si añadimos una carpeta, en el nuevo submenú que aparece, hay que indicar en "Include contents" que los queremos todos, sino coge el directorio pero no su contenido. Lo seleccionamos y volvemos a refrescar para que lo indexe.

Ahora que tenemos nuestro trigger, sólo falta asignarle una tecla. Click sobre la palabra "Hot Key" (o en la "i" del menú inferior, "Trigger Info"), "Edit" y ponemos nuestro atajo. En mi caso he elegido "alt+z". Para activar el trigger, desactivar-activar una vez el check de la izquierda.

¡Voilá, ahora ya podemos ejecutar en cualquier momento nuestra película desde FlashDevelop! (realmente desde cualquier sitio :p )

 

Guardar y compilar

Aunque ahora el flujo es bastante bueno, todavía falta que con el mismo comando se pueda guardar la clase que se está modificando y luego saltar a Flash para compilar. Sino eres tan purista-pesado-friki como yo, con la opción anterior es suficiente; si lo eres, a seguir leyendo.

La primera idea era buscar un script que pudiera guardar en FlashDevelop e intentar correrlo luego con QuickSilver, de la misma manera que hemos hecho con el jsfl. Lo primero, no encontré la forma de generar dicho script, y lo segundo, en QuickSilver con un único comando no puedes ejecutar dos opciones (realmente si he visto una forma, pero no entendí ni la mitad).

Leyendo leyendo fui a parar a un post de un tío que manipulaba Spotify vía AppleScript, así que ahí vi otro camino: crear un applescript que se comunicara con FlashDevelop y ejecutarlo desde QuickSilver también. Como seguía encontrando el escollo de "un comando, dos scripts", primero me puse a buscar la forma de poder hacer un "TestMovie" con AppleScript también, para tenerlo todo en un único archivo. Así que descarté el jsfl inicial y adapté el código del Spotify a Flash CS4.

Mac Os cuenta con "Apple Script Editor", que va de coña para ir probando los scripts. Lo abrimos, creamos un nuevo fichero y copiamos este código:

Este código pone en primer plano Flash o lo abre si no lo está, y simula un clic en la opción "Test Movie". La traducción del script es esta:

menu item "Test Movie" of menu "Control" of menu bar item "Control" of menu bar 1 of application process "Adobe Flash CS4" of application "System Events"

Increíble, ¿no?

Muy importante: es probable que el script os arroja un error similar a este "El acceso a los dispositivos de ayuda está desactivado". Esto pasa porque el comando "System Events" no puede operar. Para que funcione, hay que ir a "Preferencias del sistema" (sí, de Mac), "Acceso Universal", y abajo activar "Activar Acceso para dispositivos de ayuda".

Pausa para desahogo: ¿quién carajo sabe esto? ¿Por qué en todos los tutos que vi sobre AppleScript no lo comentan? Lo encontré tras un buen rato de búsqueda en un foro de frikis de World of Warcraft que lo utilizaban para configurarse nosequé del juego... En fin, para llorar.

Nota: Otra cosa que descubrí por la vía dolorosa es que los separadores del menú cuentan como 1, de ahí que "Test Movie" corresponda al número 8 aunque esté en la posición 6. Ojo con esto si intentais manipular cualquier otro comando.

Cuando por fin pude ejecutar el script y ver que funcionaba, fue fácil pensar que para FlashDevelop sería lo mismo. Así que me dispuse a probarlo. Una cosa que mola mucho del editor de AppleScript que si pones el nombre de un programa que no reconoce (yo por ejemplo ponía -tell application "FlashDevelop" to activate-), al ejecutar te pregunta dónde está y te ofrece la lista de programas (¡incluso los de Windows!) para resolver el nombre correcto:

Así que puse la ruta para llegar hasta el menú "File > Save" en FD y corrí el script, pero no funcionaba por un error de base que tarde un poco en detectar:

Efectivamente, el menú de FlashDevelop cuando tiene el foco no es el del programa de Windows, sino el del "wrapper" de Mac, así que otro "fail" para la lista.

Vuelta a leer tutoriales sobre AppleScript y posibilidades y encontré algo superútil: igual que se pueden simular clics de ratón se pueden simular pulsaciones de tecla. Así que tras unas pruebas pude comprobar que ganando el foco del programa y lanzando un "Ctrl+S" (estamos en Windows) guardaba el documento. ¡Por fin!

Nota: el 1 corresponde a la "s" en key code. Aquí os podéis bajar un pdf con los "key code" de un teclado Mac. Lo necesitaréis para configuraros vuestros propios atajos.

"Pues ya sólo queda ponerlo todo en un script", pensé, pero había una última sorpresa: el script saltaba a FD, acto seguido a Flash y compilaba, pero no guardaba. ¿WTF? Cuando volvía a ejecutar únicamente el código de guardar funcionaba, pero me di cuenta que tardaba unas décimas de segundo, y pensé que seguramente al intervenir la máquina virtual no era lo suficientemente rápido al enviar el comando y ganaba el foco Flash antes de poder guardar. Esta vez me costó apenas unos minutos encontrar una instrucción "delay", y efectivamente, era eso.

Finalmente, nuestro script queda de la siguiente manera:

Lo dejo para descargar aquí: http://llops.com/descargas/applescripts/save-test-movie.scpt

Dos cosas a tener cuenta:

1. la ruta que hay en el script para FD y Flash quizá no corresponda con la vuestra. Setearla como he comentado antes.
2. el delay de medio segundo es suficiente para mi máquina, pero quizá en otras deba aumentarse a un segundo o más.

Una vez guardado el script, volvemos a QuickSilver, repetimos los pasos para hacer un trigger con nuestro nuevo script, y ahora sí que sí, con una tecla podemos guardar nuestro fichero activo y compilar en Flash (ueeeee).

 

Guardar todos los archivos y compilar

Pero... ¿y si se quieren guardar todos los archivos en vez de únicamente el que tiene el foco? Esta es una opción que utilizo mucho, ya que voy saltando de archivo en archivo, picando código y compilando "de golpe". Pues otro problema, porque FlashDevelop tiene un atajo para "Save" y "Save as...", pero no para "Save all".

Esta vez no tuve que perder mucho tiempo, porque en la "investigación" inicial de FlashDevelop descubrí los "macros" (eso a lo que nunca se presta atención). Vamos a "Edit macros..." (Ctrl+F10), creamos uno nuevo, y en "Entries" añadimos el siguiente comando:

Asignamos el shortcut que queramos y guardamos. Ahora podemos añadir dicho atajo en nuestro script y cada vez que compilemos guardará todos los archivos abiertos.

 

Cerrar la película de Flash y volver a FlashDevelop

Y ya para acabar (lo juro), un script tonto que mejora un poquito más mi flujo:

Simplemente pone el foco en Flash, cierra la película y asigna el foco a FD. En mi caso tengo "cmd+0" para guardar/compilar, compruebo que va bien y pulso "cmd+9" para cerrar el test y volver a FlashDevelop para seguir trabajando.

Nota: a tener en cuenta que si no hay una película en test cerrará el archivo fla. Está con el método del "click" porque con teclas (cmd+w) no acaba de ir bien... no sé porqué...

 

Conclusión

Si no quieres renunciar a seguir trabajando con FlashDevelop y Flash Professional en Mac, hay mecanismos suficientes para tener un workflow "perfecto" en el sistema de la manzana. Todo el tema de guardar/compilar quizá sea un poco geek, rebuscado o como se quiera llamar, pero funciona. Y de eso se trata la tecnología, de ponerla a nuestro servicio para facilitarnos las tareas.

Por otro lado siento lo larguísimo del post. Soy consciente de que lo podía haber acortado mucho, pero QuickSilver y AppleScript me han parecido herramientas terriblemente potentes, y creo que ha sido interesante hablar sobre ellas y que cada uno le saque partido no sólo para esto, sino para lo que se le pueda ocurrir que facilite los flujos de trabajo diarios. Me encantará si a alguien se le ocurren nuevos scripts y los comparte.

Por último, espero el comentario que diga "Pero vaya matada! si esto se puede hacer así y así de fácil" :) Aún así, volvería a pasar por este proceso. A veces nos tiramos tanto tiempo rodeados de Flash que nos creemos que únicamente somos programadores Flash, cuando al final ser programador es tener una base para enfrentar problemas y sacar soluciones.

Con mucha ayuda de Google, claro.