Respuesta corta: Acabo de subir la versión 0.3.10 a gitlab y a la Granja.
Respuesta Larga:
[code]
Tras las sugerencias de Tincho sobre los Iconos svg versus png, me sumergí en el apasionante mundo de los gráficos (nótese la ironía) para el que los dioses no me dotaron demasiado... y descubrí cosas interesantes.
El sistema de manejo de los svg de Tincho no me gustó (sorry). Es demasiado rígido y costoso en tiempo y esfuerzo, creo. Rígido porque sólo funciona parra archivos "svg puros", es decir que sólo contengan la información vectorial. No sirve para archivos svg creados a partir de gráficos .png, jpg o lo que sea. Lo que probé fue a instalarme un editor de svg (Inkscape) y convertir los png a svg. Se convertían muy bien, pero al destriparlos descubres que lo que contienen es una "cabecera vectorial" y el png más o menos como estaba antes. No se generaban "svg puros" o al menos yo no supe hacerlo. Por otra parte, el sistema de Tincho exige que el svg sólo contenga un color azul de un tono concreto (#0066b3), lo que exige un esfuerzo en creación y una limitación respecto a ampliar el sistema a cualquier otro svg. Por último en gbamp los iconos son de tamaño fijo por lo que gran maravilla de los svg que es que se pueden escalar sin pixelar, no se llega a usar nunca. Me hubiese venido de maravilla para la imágenes de fondo de los picpanel, que al maximizar la ventana, si su resolución no es muy buena, pueden quedar algo distorsionadas... pero sospecho que los svg no son para imágenes complejas (en mi ignorancia veo los svg en imágen como equivalentes a los midi en sonido).
Sin embargo toda esa investigación me descubrió cosas que no sabía sobre los png y me abrió a nuevas posibilidades. A saber:
-No me gustó la solución de Tincho con svg porque era muy rígida... pero ¿acaso la mía, basada en png, era más flexible? No. Había que flexibilizar el tratamiento de los iconos.
-Los png ocupaban más que los svg, pero descubrí que eso es así porque la mayoría llevan más metadatos que imagen. Si a un icono .png le quitas todos los metadatos se quedan en cosas muy pequeñas. Un rato de aplicar esto a los iconos que contiene gbamp y los 31 Iconos que contiene ocupan ahora 18.9 Kb. Donde antes eran casi 2.9 Mb. Además, no tenía por qué guardar dos juegos de iconos, unos blancos y otros oscuros, con uno de ellos era suficiente y que el programa los invirtiese cuando fuese necesario.
Hice un pequeño proyecto que comparaba los tiempos de carga de las imágenes svg y las png reducidas y este era el resultado:
Cinco veces más rápida la carga de los 32 iconos png que la de los svg.
-Por otra parte, aún pudiendo elegir en el editor de temas si los querías oscuros o claros, era demasiado rígido ¿Y si los querías de otros colores? ¿y si los querías con otros dibujos? Lo que hice entonces es lo siguiente:
El programa sólo contiene ese set de iconos que ocupa tan poquito y en la primera ejecución:
a) Se crean los tres "Temas Oficiales" Dark, Light y Bronce dentro de user.home/.config/gbAmp/Themes y cada uno contiene una carpeta Icons, donde se guarda el set de iconos que que el tema requiere.
b) Se añade al editor de temas la opción de asignar los iconos que se desee, salvo al tema "Desktop", que utiliza los del sistema.
Queda así:
Aquí puedes (constato que se me ha olvidado traducir las nuevas strings) seleccionar el tema de iconos Claro u Obscuro. Luego, pulsando click en cada icono puedes seleccionar en tu disco el archivo que quieras, de manera que puedes asignar el conjunto de iconos que te de la gana. Así, por ejemplo tenéis esto:
Donde se reemplazan algunos de los iconos por otros más coloridos. Pulsando "Save Icons" (lo traduciré, claro). Ya tendríais un tema personalizado y único.
Para terminar, perdí un rato con mi nieta buscando fondos de pantalla bonitos por internet y así quedó el aspecto cuando una niña de 5 años es la que decide:
O así, que se empeñó que ahora viene el invierno:
Por último me auto-critico:
En todos mis años de programador he visto muchas veces un error muy común en los novatos: Poner en sus programas todo lo que saben hacer. Hacer programas orientados al usuario es lo adecuado. Hacerlos para lucimiento de uno o, simplemente, arrastrados por las maravillas que continuamente vamos descubriendo es hacer programa orientados al programador. Así podéis ver un montón de programas con colores horribles, con interfaces que se ven de maravilla en la máquina del programador y son un desastre en la de los usuarios, con funciones y dependencias que no funcionan en máquinas distintas a las suyas, etc. etc.
Pues vale:
En el gbAmp he vuelto a caer en ese error.
No creo que ninguno de vosotros pierda el tiempo buscando fondos bonitos ni diseñando fondos para botones ni seleccionando iconos de colorines en este programa. Eso, creo, lo he hecho para mí... y es, creo, un error. El mismo que cometen los fabricantes de hornos modernos, que añaden un selector de un montón de programas que en 10 minutos olvidas para qué son y añaden una app para conectar el teléfono con el horno... y que nunca te descargas porque vaya coñazo, oiga, etc. etc.
Si estuviese en un entorno profesional lo que haría, como en su momento hice con muchos programas míos, es eliminar todo esto y dejarlo en lo más escueto y familiar para el usuario posible (digamos el tema Desktop con ventanas de escritorio y punto). En un entorno profesional todo este tiempo dedicado a investigar y a ajustar colorines es tiempo desperdiciado (No hablo de software que pienses vender, hablo de programas internos para la empresa). Peeero... como estoy jubilado, mi tiempo es mío, no perjudico a nadie y lo mismo alguno de vosotros de lo pasa bien jugando con los colorines y los dibujitos... pues
ahí lo tenéis.
Que os guste.
Saludos.
Actualizada la traducción.