Correción: Core Image ya está aquí

[Warning, este es el típico post rollo que trata de analizar como funcionan las cosas que a nadie le importa como funcionan y que solo les gustan a los geeks]

En mi lista de "cosas que van a suceder 2006" uno de los puntos es que Apple sacaría un sistema análogo a XAML/edje. Hoy pensando un poco he recordado que básicamente, Apple ya añadió eso en Tiger, o al menos la tecnología para poder hacerlo.

Supongo que tendría que haber explicado cual era mi "predicción" exactamente. XAML y edje son cosas que incluso a día de hoy nadie usa. La idea que tratan de implementar aun no se utiliza en el mundo de los ordenadores a día de hoy.

El objetivo es poder utilizar toda la potencia de las tarjetas gráficas de hoy en las aplicaciones. Algunos pensaran que eso ya ocurre hoy en Mac OS X, porque con Quartz está todo acelerado (o lo estará cuando se incluya la aceleración 2D que estuvo a punto de entrar en Tiger). O que Xgl en linux hará lo mismo. O que portar GTK completamente a cairo utilizando el backend opengl aprovecha todo. Nada más lejos de la realidad: Todo eso está muy bien. Pero ahí precisamente está el problema: Aceleran APIs que fueron diseñadas para dibujar cosas con tarjetas lentas y cutres. Es decir: Está muy bien que se acelere el dibujado de un cuadrado. Pero lo que no se ha hecho y está aun por hacerse es diseñar APIs que permitan utilizar toda esa potencia de las tarjetas en las aplicaciones. Las APIs de hoy en día dibujan ventanas y widgets y todo lo que quieras. Pero no van más allá: Si se diseñara una API de cero pensando en tarjetas modernas, no se limitaría a crear widgets y a aplicar transparencias. Te permitiría aplicar ciertos efectos que podrían ser útiles (o no, algunos efectos no tendrán sentido al igual que hoy tampoco tiene sentido hacer una ventana 100% transparente para que el usuario no la vea).

Como digo, debería haber sido más claro al hablar de lo que "predecía". No quería decir XAMl, quería decir Avalon: Avalon es lo que permite a XAML ser así. XAML es básicamente un dialecto XMLsiano para diseñar interfaces en el que puedes decir: "Quiero el botón que se pulsa por defecto al pulsar enter tiemble con un efecto de ola". Es una especie de Glade con esteroides. Y edje, más de lo mismo, es una especie de lenguaje que al decirle que haga algo, utiliza el resto de tecnologías de Enlightenment 17 para aplicar ese efecto automáticamente. Avalon y evas son el equivalente de Core Image de Apple, no XAML y edje

No se 100% como es XAML, pero si he utilizado versiones de CVS de E17. Y no se 100% como funciona edje a bajo nivel, pero espero poder describirlo correctamente: Edje básicamente es algo análogo a glade, un archivo con una descripción de como debe ser la interfaz. La diferencia como he dicho antes, es que va más allá de poder describir unos simples widgets, te permite describir efectos que se van a aplicar a esos widgets. Esas descripciones son los "archivos EDC" (Edje Data Collections), que en un mundo perfecto se crearían con una herramienta de creación de interfaces. Si a alguien le interesa la sintaxis de esos archivos que se lea la documentación, aquí no viene a cuento. El caso es que ese archivo EDC se "compila" y se obtiene un archivo EET, que es un archivo binario que contendrá todas las imágenes, fuentes e historias que haga falta, incluida una especie de bytecode. Luego, la API de edje te permite conectar a esos objectos con el código, al igual que se hace en glade. Y al igual que pasa en glade, puedes sustituir un .eet por otro que tenga los mismos nombres de cosas, etc. ¿Que significa esto? Que en Enlightenment 17, las aplicaciones utilizan esto como sistema para suministrar "themes", y he tenido la oportunidad de cambiar entre themes que hacían que engage (el equivalente de gdm y kdm) cambiara radicalmente de aspecto, themes con efectos totalmente distintos (naturalmente, alguien dira que GDM y KDM tambien pueden, pero compara una tecnología genérica que es base del sistema y utilizable por cualquier programa a la API de GDM, que básicamente se trata de un XML donde especificas como tiene que ser "el botón de salida" limitado por todas partes e implementado como solucion cutre y rapida solo utilizable por GDM)

Bueno, y ahora quiero decir por qué estaba equivocado. Resulta que Apple añadió en Tiger core image. Y el caso es que Core Image proporciona toda la tecnología capaz de utilizar ese tipo de efectos en las aplicaciones. Lo que no tiene es algo análogo a XAML o edje. No se si Apple sacará algo análogo a edje y XAML (el por qué lo empiezo a dudar, más adelante). Tampoco importa: A día de hoy, un programa de Mac OS X puede decirle a Mac OS X Tigerque la transforme con 4 líneas de código, y tener un efecto como este:


Es como una especie de Photoshop integrado en el sistema, de manera casi literal: Se trata de implementar los típicos filtros y efectos de los programas de dibujo como recurso a disponibilidad del programador. Puedes decirle que aplique un efecto a una zona de la imagen. Etcétera. Mac OS X tiene a día de hoy alrededor de 110 filtros diferentes, y tiene APIs para que las aplicaciones incluyan los suyos propios - como es habitual, todo está perfectamente documentado, merece la pena echar un ojo a la guía de programación de core image. Tambien pueden aplicarse filtros a videos. Las capacidades son infinitas. Por cierto, el hecho de que Windows y Apple estén incorporando este tipo de tecnologías debería servir de pista a aquel que quiera hacerse rico escribiendo programas de dibujo: No empiezes a crear programas de retoque fotográfico por muy de moda que estén las fotografías, porque en un par de años cualquier aplicación que trabaje con imágenes podrá añadir un botón que aplique efectos fotográficos en cualquier lado.

¿Dije antes infinitas? No, las capacidades no son infinitas. El modelo de Core Image parece aplicarse solamente a imágenes. No parece aplicarse a Widgets (quizás tampoco debería), y lo más importante: No parece poderse aplicar como sistema para crear "animaciones", tan solo se aplican filtros a cosas. Enlightenment 17 tiene la capacidad de decir que sobre una superficie se aplique continuamente un efecto brillo similar al del metal que deslumbra. Eso va más allá de lo que puede hacer Core Image. Pero Core Image está ahí de serie y eso pone a Apple delante de todos. Ahora puedo rectificar y predecir que junto a la activación por defecto de la aceleración 2D de toda la interfaz, lo que Apple sacará es algún tipo de API complementaria que permita aplicar animaciones. Las capturas de video de Windows vista muestran efectos de animación realmente interesantes, y se que Mac OS X no va a quedarse atrás, asi que espero con ansias saber qué se está cociendo en Mac OS X 10.5 (¿o bordará la jugada Jobs y conjugará el cambio a intel con la salida de un Mac OS X 11.0?).

Y como broche final, la razón por la que creo que Apple no creará un lenguaje para diseñar interfaces análogo de Edje/XAML: Las animaciones y filtros son acciones que los elementos de la interfaz "sufren" sobre si mismas. XAML y edje se acercan peligrosamente y cruzan la barrera de lo políticamente correcto: No es bueno mezclar el diseño con algo que "se ejecuta". No es bueno mezclar el diseño que dice donde está un widget, con el efecto que debe hacerlo dar vueltas cuando se pulse, eso es tarea del código.

Supongo que XAML y edje en su "ceguera" piensan que las animaciones forman parte del sistema, pero mi sentido arácnido unixero me dice "KISS, KISS" y eso significa que el diseño de la interfaz es el diseño de la interfaz y debe utilizarse para diseñar interfaces. ¿Que luego quieres aplicar animaciones sobre esa interfaz? Bien, pero no mezcles las cosas. XAML aparte de mezclar el diseño de la interfaz con las reacciones que los widgets deben sufrir lo hace con XML. Por supuesto se pueden conectar las partes de XAML con código y no se hasta que punto llegan, pero tener que decir en un archivo XML lo que deben hacer las cosas me parece absurdo, XML no se pensó como "herramienta de programación de efectos". Ojo, que edje, en sus .EDC tiene varias secciones, y hay una que puede que precisamente hace eso, pero llegado a este punto las cosas se ponen muy abstractas y pensar y discutir cual es la "manera correcta" de hacer las cosas sin tener idea del tema (probablemente Javier Santana que parece darle al tema de la programación de juegos tenga mejor opinión de estas cosas, los juegos llevan décadas de ventaja en experiencia en estas cosas, los escritorios están dando los primeros pasos). Pero yo creo que los aspectos estáticos y dinámicos de una interfaz deberían ir por separados. Para describir los aspectos estáticos XML va bien, pero lo otro lo más lógico hacerlo en el código, y creo que esa es la ruta que Apple va a tomar: proporcionar APIs que permitan hacer esas cosas