Give Your Eyes a Treat —IEBlog, sobre cómo utilizar la tipografía Consolas en el emulador de terminal de Windos.
Pensar que yo uso esa misma fuente pero en urxvt (con las mismas vueltas para configurarla). Margaritas a los chanchos.
Margaritas a los chanchos.
Give Your Eyes a Treat —IEBlog, sobre cómo utilizar la tipografía Consolas en el emulador de terminal de Windos.
Pensar que yo uso esa misma fuente pero en urxvt (con las mismas vueltas para configurarla). Margaritas a los chanchos.
Publicado el 23 de abril de 2008 en las categorías Linux
Un sistema de variables (o constantes) en CSS puede destruir la web sólo por satisfacer un capricho de los desarrolladores.
La historia se repite y aparece otra propuesta para CSS Variables, via New features proposed for CSS en CCS3.info.
Pero personalmente considero que no solucionan ninguna falencia de la especificación actual sino que sólo satisfacen el capricho de los desarrolladores.
Entre los requerimientos mencionan que un navegador que no implementa variables puede utilizar una regla más convencial. En este caso es redundante con la propia funcionalidad de CSS porque si yo quiero que cierto elemento tenga sí o sí cierto color no voy a delegar eso a una funcionalidad que puede fallar. Entonces el sistema de variables termina en una redundancia como:
@variables {
mycolor: green;
}
p {
color: green; /* para asegurarme que el texto sea verde */
color: var(mycolor); /* redundante usando variables */
}Otro problema es que no se especifica cómo funcionaría en el caso de las tipografías. En este ejemplo no existe forma de incluir una regla que no produzca un conflicto entre los navegadores que implementan variables y los que no.
@variables {
myfont: monospace;
}
p {
font-family: sans-serif;
font-family: var(myfont);
}Un navegador que implementa variables usaría una fuente monoespaciada, pero en el caso contrario no se usa una fuente sans-serif sino la fuente que esté configurada como por defecto (generalmente una fuente serif) —font-family es un caso excepcional entre las demás propiedades.
Esta funcionalidad rompe completamente (de una manera indirecta) con el proposito de CSS, que es que un navegador que no implemente cierta propiedad pueda aún así sacar provecho de todas las demás. Funciona como un filtro con el que si cierta funcionalidad no está implementada, no se puede acceder a todo el resto de las propiedades; por ejemplo, que se requiera contenido generado para que también se indique qué color de fondo usar. En el caso de las variables esto se logra de manera muy sencilla:
@variables {
mybg: black;
myfb: white;
}
html {
background-color: var(mybg);
color: var(myfg);es perfectamente equivalente a
html {
background-color: black;
color: white;
}
sólo que el primer ejemplo no podría ser interpretado por ciertos navegadores. El uso de variables crea un limite infranqueable (manejado por los desarrolladores) entre navegadores viejos y nuevos.
Organización
Esto no es tanto una falencia de la propuesta sino una cuestión más ideológica: el sistema de variables sólo existiría por la ineptitud de los desarrolladores. Si ciertos elementos tienen que usar el color rojo, lo más inteligente sería organizar las declaraciones de tal manera que la declaración sea hecha una sóla vez. En lugar de un despelote como
p {color: red; /* varias propiedades más */}
ul {color: red; /* varias propiedades más */}
h3 {color: red; /* varias propiedades más */}p, ul, h3 {color:red;}
p, ul, h3 { /* otras propiedades */ }Existen montones de artículos que repiten hasta el cansancio cómo organizar las declaraciones de CSS.
¿Algún pro-variables y pro-innovacion que quiera contradecirme?
Publicado el 10 de abril de 2008 en las categorías CSS
Si un archivo no es libre, el paquete no es libre.
Descargo: Esto no es una burla a los desarrolladores de IceCat. Es una simple jugarreta sobre lo díficil que es controlar cada pequeño detalle cuando se trata de licencias. Eso no quita que sí creo que esos dos logos deberían ser removidos del paquete (si es que todavía no fue hecho).
Publicado el 3 de abril de 2008 en las categorías CSS
Soporte para XHTML en el navegador web Lynx (o algo así).
En Summary of changes in Lynx v2.8.6 mencionan que se incluye una cierta forma de implementación para XHTML.
Aún así esto no parecer significar que Lynx realmente pueda analizar XHTML (y por extensión XML), sino que sólo le da una vuelta de tuerca a los media-types. Lynx ahora asume que cualquier documento servido como application/xhtml+xml, application/xml y text/xml puede ser analizado como si fuera HTML, entonces no hace falta descargarlo para pasarlo a otra aplicación.
De esto se desprende que Lynx no comprueba que un documento XML esté bien formado (porque lo analiza según las reglas más laxas de HTML) y también que no reacciona a los namespaces —un elemento de SVG es simplemente un elemento desconocido que se muestra como un elemento en linea.
Publicado el 31 de marzo de 2008 en las categorías HTML, Lynx
Konqueror y otras aplicaciones de KDE corriendo nativamente en Windows.
Nuevamente con noticias viejas: KDE y sus aplicaciones están siendo portadas a Windows luego de que Trolltech liberara las librerias QT, base de KDE, bajo la GPL.
El sistema consiste en bajar un pequeño instalador que se encarga de descargar un gran paquete de aplicaciones y dependencias. La primera versión pública ya apareció en 3 de noviembre de 2007 (November 3rd, 2007: KDE-Beta4 packages are available for download —por eso mencionaba lo de noticias viejas).
Lo interesante del asunto es que una de las aplicaciones que (obviamente) está siendo portada es Konqueror, lo que aumenta la cantidad de navegadores web en Windows y convierte a la dupla Internet Explorer/Trident en la única (actualizada) disponible (nativamente) para una única plataforma —esto también significa que la cuota de mercado de Internet Explorer no tiene por qué ser (por siempre) proporcional a la de Microsoft Windows, disminuyendo la importancia del mismo.
Epilogo: Remarqué el hecho de que fuera una implementación nativa porque hacer funcionar aplicaciones (de KDE) en Windows tampoco es una novedad. Desde hace rato es posible usando cygwin y también es posible recurriendo al sistema de andlinux. La diferencia es que ambos proyectos se basan en una cierta forma de emulación o al menos de hacer creer a la apliación de que está corriendo en un verdadero entorno UNIX. En el proyecto oficial de KDE se menciona la remoción de código especifico de la plataforma Linux en su paso a Windows. Visualmente hablando habría que comprobar la diferencia en cómo se integra con el resto del sistema, especificamente las ventanas —en el caso de cygwin las aplicaciones parecen funcionar dentro de una ventana creada por cygwin. Y por otro lado comprobar que se respetan las convenciones de directorios de Windows (incluyendo letras para las particiones y discos).
Publicado el 24 de marzo de 2008 en las categorías Konqueror
Evitar que cada nueva pestaña utilice el contenido del portapapeles.
En una instalación por defecto de Opera en Linux, al hacer un click con el botón del medio del mouse sobre la barra de pestañas se abre una nueva pestaña usando como URL el texto cualquiera que esté en el portapapeles.
Para que esto no ocurra (porque es una reverenda porquería) hay desactivar la opción En PageBar Open URL On MiddleClick en opera:config.
Un problema menos desde mi paso (definitivo) a Ubuntu Linux.
Publicado el 18 de marzo de 2008 en las categorías Opera, Linux
La versión 4.0 del navegador web iCab es el primero de la serie en abandonar el motor de renderizado propietario y utilizar WebKit.
Esta noticia ya tiene unos meses pero vale comentarla.
Cuando se habla de navegadores web populares siempre se mencionan al omnipresente Internet Explorer, a su rival Firefox y a mi favorito, Opera. Lamentablemente siempre se menosprecia a Opera cuando se habla de estadísticas por su porcentaje de mercado ronda el 1%. Lo que pocos parecen pensar es que una cantidad del 1% es algo si se compara con otros navegadores más oscuros (dejando de lado a Safari que tiene una cuota de mercado similar).
El verdadero navegador alternativo ha sido (para mi gusto) iCab para Mac OS. iCab se ha mantenido como un desarrollo con código cerrado de una única persona que funciona en versiones antiguas de Mac OS. Lamentablemente iCab tiene un oscuro pasado por un motor de renderizado comparable a Netscape 4; pero para el lanzamiento de su versión 3 no sólo logró mejorar este aspecto sino que quedó como uno de los primeros navegadores en superar el test Acid2. iCab, al igual que Opera, es un navegador que ha logrado sobrevivir aún siendo shareware en un mercado aún más alternativo como son las Macintosh —una minoría en la minoría— basando su éxito en las funcionalidades.
Lo bueno algún día acaba. Desde principios de 2008 cuando fue publicada la versión 4 de iCab, el motor de renderizado propietario que se venía utilizando, junto al intérprete de JavaScript InScript, fueron reemplazados por WebKit, el núcleo de Safari (que incluye a WebCore para renderizado y JavaScriptCore para JavaScript).
Lo más triste de esto es que Macintosh venía siendo la plataforma con más diversidad de motores de renderizado (decentes) hasta el profundo cambio de iCab (si la comparamos con Windows y Linux). Hagamos cuentas de los navegadores más usados (por motor de renderizado):
En Linux se cuentan cuatro (todavía):
En Macintosh quedan sólo tres, o tres y medio si contamos a Tasman en Internet Explorer para Mac que fue un motor de renderizado pionero y de muy buena calidad).
En Windows se cuentan cuatro que se continuan desarrollando:
Dejo de lado lo que se refiere a navegadores para plataformas móviles porque soy un ignorante total, a navegadores que podrían correr en cualquier cosa como Lynx y otros que están en estado vegetativo como Dillo.
Adios a un motor de renderizado; una extravagancia menos al momento de planear testcases.
Más para leer en Requiem for a rendering engine y The Year in Browsing: The Little Engine That Could y el anuncio oficial sobre el cambio en iCab en iCab 4.0.0 and iCab 3.0.5 Public Releases.
Publicado el 28 de febrero de 2008 en las categorías iCab
Problema porque metacity no se ejecuta al inicio de la sesión.
En mi loca carrera por desinstalar todo aquello que consideré superfluo en la instalación de Ubuntu Gutsy, removí los paquetes correspondientes a Compiz; para ello realice un apt-get remove compiz-core. El problema surgió en el siguiente arranque del sistema, (el manejador de ventanas) metacity no se inicia automaticamente —basicamente esto significa que las ventanas no tenian bordes—. El problema es que Ubuntu aún seguía usando Compiz como manejador de ventanas —aparentemente Compiz de alguna manera ejecutaría también a metacity.
La solución consiste en ejecutar el Configuration Editor —no aparece en el menú de aplicaciones a menos que lo editemos—; para eso desde una terminal ejecutamos gconf-editor y buscamos la sección /desktop/gnome/applications/window_manager y modificamos los campos current y default por /usr/bin/metacity.
Publicado el 9 de febrero de 2008 en las categorías Linux
