Las ventanas no deberían superponerse. Al menos esa era la idea original.

Cuando en los años setenta se pensó cómo una pantalla podría dar cabida a varias cosas a la vez, nadie imaginaba un caos de rectángulos superpuestos. Se pensaba en particiones. En superficies que se dividen en cuanto algo nuevo llega — como mesas donde los libros se colocan uno junto a otro, no apilados. Los primeros sistemas de ventanas en las Lisp Machines de Symbolics, en el proyecto Andrew de la Universidad Carnegie Mellon, incluso Microsoft Windows 1.0 en 1985: todos basados en teselas. Las ventanas superpuestas eran una opción, no la norma.

Luego prevaleció la superposición. Apple la popularizó con el Macintosh, Microsoft siguió, X11 en Unix acompañó. La razón no fue que la superposición funcionara mejor — solo parecía más intuitiva. Podías tratar las ventanas como papeles sobre un escritorio, llevar la superior hacia delante, ocultar otras. La metáfora era tangible. La eficiencia no. Quien quería ver algo oculto primero tenía que sacarlo a primer plano. Quien pretendía abarcar varias cosas a la vez tenía que disponerlas a mano. El precio de la metáfora era un trabajo manual constante — un precio que nadie cuestionaba ya, porque no parecía haber alternativa.

Hoy, quien usa un escritorio Linux suele elegir entre dos grandes entornos: GNOME y KDE Plasma. Ambos son excelentes. Ambos son flotantes. Ambos organizan las ventanas según el paradigma popularizado en 1984. Y casi nadie pregunta si ese paradigma se sostiene.

Qué es realmente el tiling

Los gestores de ventanas tiling disponen las ventanas no superpuestas sino en mosaico. Cada ventana nueva recibe un área rectangular de la pantalla; las existentes se encogen para hacer sitio. Nada queda oculto. Cada píxel trabaja.

Existen dos subcategorías. El tiling manual —como en i3— exige que dividas activamente las ventanas en contenedores; el gestor reparte el espacio en consecuencia. El tiling dinámico —como en dwm, AwesomeWM o xmonad— calcula la disposición automáticamente mediante un algoritmo: maestro-pila, espiral, cuadrícula, lo que sea. Abres una ventana, el gestor ordena. Cierras una, las demás rellenan el hueco.

El resultado no se parece a un escritorio. Se parece a un panel. Y cambia cómo trabajas con la máquina.

El dominio de lo flotante

Hablemos del presente. GNOME y KDE Plasma dominan el escritorio Linux. Ambos entregan entornos completos: panel, menú de aplicaciones, notificaciones, gestor de archivos, ajustes, temas, gestión de pantalla, gestión de sesión. Están totalmente provistos. Quien los instala tiene un escritorio funcional — no una pieza de construcción que haya que ensamblar.

Eso no es un defecto. Es la razón por la que la mayoría permanecen. Un entorno de escritorio es infraestructura. Debe funcionar, no ser explorado. La mayoría de los usuarios — incluso quienes eligieron Linux por convicción — no tienen apetito por tratar un gestor de ventanas como un proyecto perpetuo.

Las distribuciones ponen de su parte. Fedora, Ubuntu, openSUSE, Arch — todas entregan un entorno flotante por defecto. Los gestores tiling existen en los repositorios, pero tras una decisión deliberada: hay que buscarlos, instalarlos, configurarlos. Nadie tropieza con i3 por accidente. Quien los descubre o bien los buscó — o conoció a alguien que los usa.

Y aquí empieza la paradoja. La misma comunidad que compara distribuciones, debate sistemas de inicio, combate formatos de paquete y libra guerras santas de editores — la comunidad que enarbola la elección como valor — trata la elección del paradigma de ventanas como si solo existiera uno. Sin embargo, existe una alternativa al menos tan consecuente como todo lo demás que distingue a Linux. Se llama tiling. Y lleva una existencia en la sombra.

Lo que ofrecen los gestores tiling

Las ventajas no son románticas. Son mecánicas.

Manejo centrado en el teclado. En un gestor tiling navegas principalmente con el teclado. Modos, cambios de foco, creación de divisiones, saltos de área de trabajo — todo secuencias de teclas, ningún movimiento de ratón. Quien pasa ocho horas diarias frente a la máquina y dedica dos a arrastrar ventanas pierde tiempo. Suena marginal. Acumula.

Aprovechamiento completo de la superficie. Las disposiciones flotantes se superponen. Superponer significa que parte del contenido está oculto — y que hay que indagar activamente para revelarlo. El tiling muestra todo lo abierto simultáneamente. En una pantalla ultrapanorámica seis terminales, un navegador y un chat quedan visibles lado a lado — sin olimpiada de Alt-Tab.

Configuración programable. i3, sway, Hyprland, AwesomeWM: todas las configuraciones son ficheros de texto. AwesomeWM va más allá — su configuración es código Lua. Quien quiera puede generar áreas de trabajo dinámicamente, enrutar ventanas a ciertas superficies según su título, cambiar de disposición programáticamente. Los dotfiles se vuelven reproducibles. Una configuración puede confirmarse, versionarse, clonarse en una segunda máquina. Eso es pensar en ops aplicado al escritorio.

Huella mínima. dwm ocupa menos de dos megabytes residentes. sway, Hyprland, i3 — todos notablemente más ligeros que un entorno completo. En hardware envejecido, en clientes ligeros, en máquinas que hacen sobre todo trabajo de terminal, eso no es lujo — es margen relevante.

Flujo antes que fragmentación. Quien trabaja simultáneamente en terminales, editores, navegadores y documentación normalmente hace malabares con las ventanas. El tiling convierte el malabarismo en estado estable: todo visible, accesible, descubierto. El cambio de contexto mental disminuye.

Una mañana comparada

Consideremos una mañana corriente. Un administrador entra en la oficina, café en mano, y la máquina espera.

En el mundo flotante: abrir el lanzador, clic en el terminal — aparece centrado, oculta todo. Tirar de una esquina, apartarlo. Abrir un navegador, apretarlo al lado, se superpone al terminal. Sacar el visor de registros, otra ventana que no encaja en ningún sitio. Tras diez minutos de cacería de Alt-Tab tienes seis ventanas, tres medio cubiertas, y has movido el ratón más que el teclado.

En el mundo tiling: Mod+Intro abre un terminal — mitad izquierda, automático. Mod+Intro otra vez — mitad derecha, dividida. Navegador en el área 2, Mod+2, ahí está, a panel completo. Registros en el área 3, supervisión en 4, wiki en 5. Seis áreas de trabajo, cada una claramente asignada, alcanzadas con las teclas numéricas. Las manos no abandonan la fila inicial. Tras diez minutos sostienes el mismo panorama — sin haber desplazado una sola ventana.

La diferencia parece pequeña aisladamente. Se acumula a lo largo de ocho horas, cinco días por semana, año tras año. Quien ha trabajado en este ritmo percibe alargar la mano hacia el ratón como una interrupción — no como una herramienta.

El panorama

El panorama de los gestores tiling no es homogéneo. Un resumen de los relevantes:

i3. El clásico. Desde 2009, mantenido por Michael Stapelberg y la comunidad. Tiling manual, excelentemente documentado, predecible. Quien aprende i3 suele conservarlo. El patrón oro para principiantes.

sway. i3 para Wayland. Compatible en configuración, sustitución directa. Quien quiere migrar de i3 a Wayland encuentra aquí el camino directo.

Hyprland. El nuevo. Nativo de Wayland, acelerado por GPU, animado, pulido. Iteración rápida, ocasionalmente cambios disruptivos entre versiones. Quien privilegia la modernidad sobre la estabilidad está en su sitio. La comunidad es grande, la energía alta, los bordes aún ásperos.

AwesomeWM. Tiling dinámico, programable en Lua, extremadamente flexible. Quien prefiera programar antes que configurar halla aquí su terreno. La curva de aprendizaje es más pronunciada, las posibilidades ilimitadas.

dwm. Del proyecto suckless. Minimalista, código fuente en C como configuración, tiling dinámico. Quien valora la pureza filosófica — aquí. Ningún fichero de configuración; se parchea el código.

bspwm. Particionado binario del espacio. Las ventanas se dividen recursivamente en mitades. Concepto elegante, ejecución consecuente.

xmonad. Configurado en Haskell. Para quienes quieren llevar la pureza funcional hasta dentro del gestor de ventanas.

Siguen siendo destacables: herbstluftwm — tiling manual, configurable vía una herramienta de línea de comandos en tiempo de ejecución — y river, un proyecto Wayland ascendente con disposición dinámica.

Ninguna de estas soluciones es equivocada. Difieren en filosofía, método de configuración y madurez. Pero comparten un rasgo: presuponen que uno se compromete con ellas.

Las barreras honestas

Los gestores de ventanas tiling no son para todos. Ocultarlo es proselitismo, no consejo.

Curva de aprendizaje. Los primeros días son incómodos. Hay que aprender combinaciones de teclas, construir un modelo mental de la jerarquía de contenedores, reestructurar flujos. Tras décadas en modo flotante, se agarra el ratón por reflejo — y en un setup tiling suele ser inútil o contraproducente. Se pasa, pero no al instante.

Integración. Un entorno de escritorio aporta polkit, notificaciones, bandeja, bloqueo de pantalla, gestión de pantalla, accesibilidad, métodos de entrada, consistencia de tema. Un gestor tiling desnudo aporta: gestión de ventanas. Todo lo demás hay que ensamblarlo. Wayland ha mejorado mucho, pero el esfuerzo sigue siendo real. Quien quiere una experiencia totalmente provista no la obtiene lista para usar.

Mantenimiento. Los dotfiles exigen cuidado. Las actualizaciones pueden romper configuraciones — especialmente en proyectos de iteración rápida como Hyprland. Quien construye un setup una vez y luego no lo toca durante años puede quedar congelado. Quien sigue el desarrollo invierte periódicamente.

Valores predeterminados austeros. Los gestores tiling traen valores por defecto parcos. Bien si piensas en minimalista. Menos bien si esperabas una experiencia acabada. La belleza emerge de la configuración — y la configuración es trabajo.

Fracturas del ecosistema. Wayland fracturó el universo X11. Algunos gestores tiling son nativos de Wayland (sway, Hyprland, river), otros siguen siendo solo X11 (i3, awesome, bspwm, xmonad, dwm). Quien opera un flujo mixto debe comprobar la compatibilidad. XWayland ayuda pero no es infalible.

Dotfiles: del inconveniente a la ventaja

El mantenimiento de los dotfiles se mencionó arriba como barrera — y lo es, mientras se atienda en solitario. Un usuario aislado que cuida su propia configuración no responde ante nadie más que ante sí mismo. Pero en cuanto más de una máquina entra en juego, la presunta debilidad se convierte en la ventaja decisiva.

Ansible — o herramientas de templating comparables — puede mantener los dotfiles como plantillas Jinja2. Una configuración de i3, un config de sway, una barra de polybar, un rc de shell: todo plantillas con variables. Nombre de host, nombre de usuario, identificadores de monitor, distribución de teclado, paleta de colores — inyectados por máquina, variados por equipo. Un playbook, un repositorio, una invocación — y todo el escritorio queda configurado. No en una máquina. En cien.

Idempotente. Repetible. Con control de versiones. El mismo playbook corre en el portátil del desarrollador, el servidor en rack, el cliente ligero de la sala de reuniones — y produce cada vez la configuración correcta desde la misma plantilla. El escritorio se vuelve infrastructure as code. No como palabro de moda, sino como práctica.

Prueba lo mismo con GNOME. GNOME guarda sus ajustes en dconf — una base de datos binaria que sirve de backend para GSettings. La interfaz es gsettings o dconf en la línea de comandos, pero lo que hay detrás no es texto. No se puede leer, ni diferenciar, ni mantener como plantilla. Quien quiere automatizar los ajustes de GNOME debe exportarlos, envolverlos en scripts, recargarlos vía dconf load — un rodeo por datos binarios que se resiste a toda lógica de templating. Funciona, pero sigue siendo un cuerpo extraño en el flujo de infrastructure-as-code.

KDE es algo más accesible en este aspecto — muchos ajustes viven como ficheros de texto tipo INI —, pero la consistencia es irregular. Algunos valores migran a bases plasmarc, otros a ficheros rc, y la estructura cambia entre versiones mayores. Quien intenta templatar un setup KDE con Ansible lucha contra un modelo de configuración heterogéneo nunca diseñado para la automatización.

Los gestores tiling, en cambio, fueron construidos para ello. Su configuración es texto desde el principio, un único fichero desde el principio, determinista desde el principio. Sin base de datos, sin formato binario, sin estado oculto. Una plantilla que genera un config de i3 es tan natural como una que genera un nginx.conf. Las herramientas encajan porque el material encaja.

Para equipos esto significa: un administrador define un setup tiling — áreas de trabajo, atajos de teclado, colores, inicio automático — y lo despliega vía Ansible a cada máquina. Los nuevos compañeros obtienen el mismo escritorio el primer día. Las máquinas averiadas se reconstruyen y convergen al estado deseado. Una auditoría pregunta: ¿cómo está configurado el escritorio? La respuesta reside en el repositorio Git. No en una base de datos binaria que primero hay que volcar.

No es un argumento cosmético. Es la diferencia entre un escritorio que administras y uno que se presta a ser administrado.

Quién se beneficia

Los gestores de ventanas tiling hablan a un tipo específico de usuario.

Desarrolladores que trabajan simultáneamente en editores, terminales, navegadores y documentación. Administradores de sistemas que quieren mantener seis sesiones SSH, registros, monitorización y una wiki abiertas. Científicos de datos que necesitan notebooks, REPL y ventanas de gráficos lado a lado. Usuarios avanzados que entienden su escritorio como taller, no como superficie de consumo.

Pero también: gente que aprecia la reproducibilidad. Quien confirma sus dotfiles posee un escritorio que puede destruirse y restaurarse — en segundos, en cualquier máquina. No es un juguete. Es estrategia de respaldo para el puesto de trabajo.

Y gente que insufla vida a hardware antiguo. Un gestor tiling en un ThinkPad de 2015 corre con fluidez donde un entorno completo jadea. Eso es relevante económicamente y ecológicamente — los dispositivos viven más cuando el software no crece con ellos.

A la inversa: quien trabaja ante todo en programas gráficos de paletas — retoque de imagen, ilustración vectorial, montaje de vídeo, CAD — suele encontrar en el tiling la respuesta equivocada. Estas herramientas viven del libre arreglo de grandes lienzos, de paletas flotantes, de líneas de tiempo superpuestas. Meterlas a la fuerza en una rejilla rígida no crea ventaja alguna, solo fricción. El tiling no es un dogma. Es una herramienta para un cierto modo de trabajo — y quien tiene otro haría mejor en dejarlo estar.

Una cuestión de actitud

Los gestores de ventanas tiling encarnan valores nucleares del movimiento open source: transparencia, configurabilidad, hackabilidad, reproducibilidad. La configuración es legible. El comportamiento es trazable. Las dependencias son mínimas. Nadie decide sobre mi escritorio salvo yo.

Es el mismo impulso que atrae a la gente hacia Linux, hacia el autoalojamiento, hacia los estándares abiertos. Solo que en el escritorio — el lugar que contemplas ocho horas al día y que, aun así, cuestionas menos.

Se suma una cultura que comparten los usuarios de gestores tiling: la comunidad de los dotfiles. Las configuraciones se publican, se confirman, se debaten — en plataformas que por sí solas equivalen a foros. Un setup no es posesión privada sino un borrador que otros estudian, adaptan, mejoran. Eso es pensamiento open source a la menor escala: la transparencia no como obligación sino como algo natural. Quien explota así un escritorio no lo hace como consumidor sino como coautor.

Quien elige KDE o GNOME no se equivoca. Ambos son software formidable. Pero quien los elige sin haber sopesado jamás la alternativa no toma ninguna decisión. Adopta un producto estándar. Y eso, para una comunidad que debate cada otra faceta de su infraestructura, resulta llamativo.

Qué supone esto para libcom.de

Desde hace veinticinco años trabajo con escritorios Linux — en entornos de un único puesto, de equipo y empresariales. Conozco ambos lados: la completitud redondeada de un entorno de escritorio y el rigor purista de un setup tiling. Ambos tienen su justificación. La pregunta no es cuál es mejor. La pregunta es cuál es mejor para quién.

Quien viene a mí no recibe una recomendación estándar. Recibe un análisis: ¿Cómo trabajas? ¿Qué aplicaciones, qué pantallas, qué flujos? ¿Dónde hay dependencias que imponen un setup determinado? Luego planeamos — por etapas, documentado, reversible. Quien quiere probar tiling no necesita tirarse al agua fría. Se puede probar, pilotar, evaluar. Y si no encaja, se vuelve atrás — sin pérdida.

Si te preguntas si un gestor de ventanas tiling conviene a ti o a tu equipo, o simplemente quieres una valoración honesta de tu configuración actual de escritorio: escribe a contact@libcom.de. Hacemos un inventario honesto. Sin presión comercial. Con la vista en lo que dura a largo plazo.

Las ventanas no estaban hechas para superponerse. Esa era la idea original. Tal vez sea hora de volver a sopesarla.