Decíamos en la anterior entrega de esta serie, que un caso que se suele dar a conocer como de éxito es el de los toolkits gráficos. En parte es cierto, hay muchas aplicaciones que utilizan este tipo de módulos. Pero claro, en realidad encierra lo que yo entiendo es un fracaso: solo se puede considerar que aquellas aplicaciones que utilicen ese toolkit específico están construidas sobre esos módulos. Es decir, hay muchas aplicaciones que están construidas sobre, por ejemplo, Win32, Gtk, Qt, o wxWidgets, comparten todas el mismo módulo base para el dibujo de la interfaz gráfica, algo de lo que se abstraen completamente. Pero una vez que una app se construye sobre uno de estos toolkits, a no ser que esté muy bien diseñada, va a estar atada a él. Y aún así, un port a otro toolkit tomará un considerable esfuerzo. La pregunta entonces es: ¿realmente son tan diferentes los estos módulos de interfaz gráfica como para requerir código totalmente distinto? Vamos a ver cómo podemos crear una pequeña interfaz gráfica para una app en C#, con la desaparecida (excepto para Windows) Windows.Forms. var panel = new Panel{ Dock = DockStyle.Fill }; var btTop = new Button{ Text = "Top", Dock = DockStyle.Top }; var btBottom = new Button{ Text = "Bottom", Dock = DockStyle.Bottom }; var btLeft = new Button{ Text = "Left", Dock = DockStyle.Left }; var btRight = new Button{ Text = "Right", Dock = DockStyle.Right }; var btCenter = new Button{ Text = "Center", Dock = DockStyle.Center }; panel.Controls.Add( btTop ); panel.Controls.Add( btBottom ); panel.Controls.Add( btLeft ); panel.Controls.Add( btRight ); panel.Controls.Add( btCenter ); Y ahora, otra en Java, utilizando Swing: var panel = new JPanel(); panel.setLayout( new BorderLayout() ); var btTop = new JButton( "Top" ); var btBottom = new JButton( "Bottom" ); var btRight = new JButton( "Left" ); var btLeft = new JButton( "Right" ); var btCenter = new JButton( "Center" ); panel.add( btTop, BorderLayout.NORTH ); panel.add( btBottom, BorderLayout.SOUTH ); panel.add( btRight, BorderLayout.EAST ); panel.add( btLeft, BorderLayout.WEST ); panel.add( btCenter, BorderLayout.CENTER ); ¿Cómo? ¿Que esos son toolkits muy antiguos? Vale, veamos Avalonia para C#: var btCenter = new Button{ Content = "Center" }; var panel = new DockPanel{ LastChildFill = true }; var btTop = new Button{ Content = "Top" }; var btBottom = new Button{ Content = "Bottom" }; var btLeft = new Button{ Content = "Left" }; var btRight = new Button{ Content = "Right" }; DockPanel.SetDock( btTop, Dock.Top ); DockPanel.SetDock( btBottom, Dock.Bottom ); DockPanel.SetDock( btLeft, Dock.Left ); DockPanel.SetDock( btRight, Dock.Right ); panel.Children.Add( btTop ); panel.Children.Add( btBottom ); panel.Children.Add( btLeft ); panel.Children.Add( btRight ); panel.Children.Add( btCenter ); Esta no es la única forma de disponer controles gráficos en una app. También se pueden crear paneles unos dentro de otros, en vertical u horizontal, o utilizar una disposición de cuadrícula (grid). Todas esas posibilidades están disponibles en todos los toolkits gráficos... y sin embargo, todas ellas se llaman de forma total o ligeramente distinta. Y es que el problema es ese. Nadie se preocupa por una estandarización o compatibilidad. Cuando Google desarrolló Android, ya existían numerosos toolkits gráficos disponibles, entre ellos algunos con tanta solvencia como Qt, por poner un ejemplo. Y sin embargo, resolvieron crear el suyo propio. Desde cero. Soportando las mismas características. Pero, claro está, con nombres distintos. Y construcciones ligeramente distintas. Uno de los consejos que se da para desarrolladores es: no reinventes la rueda. Excepto que lo estés haciendo para aprender, claro. Y sin embargo, cada vez que una nueva plataforma (cualquiera), soporta una vista gráfica, acaba desarrollando un nuevo toolkit desde cero. Con nombres total o ligeramente distintos, pero soportando exactamente las mismas funcionalidades. No puedo dejar de mencionar específicamente a uno de los toolkits más odiosos en este sentido: gtk. Como muestra un botón: no puedes (o al menos, no debes), cambiar colores de ventanas o botones. Ellos saben mejor que tú cuál es la interfaz perfecta (utilizan este tipo de frases como "no less than perfect user interfaces"). Este virtuosismo permea también a cómo programar una interfaz con Gtk. De hecho, una app hecha con Gtk 2 será totalmente incompatible con Gtk 3, y a su vez, lo mismo para una con Gtk 3 hacia Gtk 4. Portar una app de una versión a otra es un laberinto de APIs obsoletas, funcionalidades refactorizadas, y cambios tan significativos como que los paneles (en Gtk son cajas, Box) han pasado de ser clases separadas para HBox (horizontal) y VBox (vertical), a ser una sola clase Box con un parámetro en el constructor, Orientation.Vertical, u Orientation.Horizontal. Necesitamos estandarización. Especialmente, si las funcionalidades son las mismas, no es necesario, y de hecho, ni siquiera es aconsejable, crear versiones con interfaces distintas. Recordemos la analogía del iceberg, de manera que las interfaces deben ser mínimas independientemente de su implementación; y también que el primer lenguaje de programación orientado a objetos, Simula, estaba orientado a la simulación, por ejemplo, de piezas de un motor, de manera que distintas piezas podían intercambiarse... solo si soportaban la misma interfaz, claro.