Hace unos días consulté en las news de CodeGear qué opciones hay usando sus herramientas para crear la interfaz de usuario de un programa cuyo "back-end" ha sido escrito en C#. La experiencia ha sido sorprendente por varias razones. No sabía que CodeGear hubiese "congelado" su C#, no sólo como producto independiente, sino también dentro del RAD Studio, en el que no tiene acceso al diseño de formularios. Realmente tampoco esperaba, por eso es bueno preguntar :-) que hubiese buenas opciones para crear la interfaz con Delphi.NET. CodeGear ha desechado Winforms y se ha quedado con el otro toolkit, VCL.NET. La ventaja de éste es que tiene un diseñador de formularios bastante más usable que el de Visual Studio y que las interfaces creadas responden con más agilidad que las construidas con Winforms. En el lado negativo, parece que cualquier librería gráfica no apoyada directamente por Microsoft necesita privilegios especiales para ejecutarse.
Pero si hay algo que me ha sorprendido es la falta de opciones. Hace unos años Microsoft dominaba el mercado de herramientas de programación para escritorio con su Visual Basic "clásico" (quiero decir el que no era .NET) con bastante más usuarios que entornos como Delphi u otros lenguajes de su Visual Studio como el C++. Ahora han dejado de desarrollar ese producto y se vuelcan con .NET donde, sea con VB o con C#, no parece haber opción para crear interfaces de usuario con la misma riqueza que la anterior generación de herramientas. No tengo experiencia directa, corregidme si me equivoco, pero lo que me llega es que el diseñador de formularios es incómodo y los controles son pobres y responden con lentitud. La frase literal ha sido que "parece Java". ¿Es realmente tan malo? ¿Qué han hecho los programadores de VB? ¿Siguen con la versión 6?
Los partidarios de .NET parecen pensar que se arreglará en las próximas versiones, que WPF (que ahora mismo tampoco se encuentra en un estado verdaderamente usable) sustituirá finalmente a Winforms y que el entorno de desarrollo mejorará. Pero es difícil entender por qué se habría de meter Microsoft en semejante berenjenal con vistas al futuro, cuando ya tenía en el presente el dominio, cabreando además a sus programadores y perdiendo una ventaja sobre la competencia.
Si hay un terreno de importancia estratégica en las guerras del software, es el de la programación de interfaces gráficas de usuario. Hay pocas organizaciones que hayan sido capaces de crear un "ecosistema" suficientemente rico y fácil de usar. Los lenguajes emergentes como Ruby o Python suelen tirar más bien por la socorrida interfaz web, ya que para usar Qt o el API de Windows cómodamente es poco menos que imprescindible tener un IDE. A pesar de todos los pesares, Delphi sigue teniendo un algo que no tienen los demás :-)
Comentarios
Lo que he visto
Hola Nico.
En mi caso particular cuando usaba VS 2003 la idea sobre la que funcionaba Winforms me parecía muy interesante, ya los controles propiamente dichos eran una basura, especialmente la grid de datos. En VS 2005 ( y .NET 2.0 ) mejoraron suficiente para mi gusto, sobre todo porque la mayor parte de las aplicaciones que hago son en general servicios y los módulos que necesitan de ventanas son básicamente configuradores. Por otro lado cuando trabajo no-.NET me fuerzan a usar Delphi 5 lo cual para mi es una verdadera tortura en todos los aspectos , ya que no soy aficionado a estar cargando con miles de componentes de terceros solo para poner botoncitos. Supongo que en versiones posteriores hayan mejorado mucho, sin olvidar que seguramente con todas sus limitantes en su época debió ser de lo mejor que habría. A mi en particular me gusta mucho eso de que cualquier componente sea capaz de visualizar información estática o sacada de un origen de datos , al igual que un origen de datos pueda ser cualquier cosa y desde que tuve esa posibilidad cada vez que tengo que hacer algo en D5 sufro lágrimas de sangre, además me encanta tener a la mano el código que genera, esa es otra de las cosas que me molesta de D5. También es verdad que para una buena parte de las aplicaciones que hacemos cada vez se justifica menos usar una interface basada en Winforms a menos que sea algo puntual para alguien que va a correrlo solo en una máquina de lo contrario es mucho mas práctico tener una interfaz web, es mucho mejor para el cliente y para el mantenimiento. VB por su parte nunca fue santo de mi devoción, pero siempre pensé que Microsoft no necesitaba hacer un VB.NET, la mayoría de la gente que usaba VB no debe estar muy contenta y supongo que debe haber montones que no hayan soltado el VB 6, C# por su parte me parece una de las mejores cosas que han inventado.
Saludos
Angel Ochoa
Varias cosas
Angel, en primer lugar disculpa si el comentario no ha salido inmediatamente. El sistema anti-spam no está afinado y preveo que le va a costar pues llegan muy poquitos comentarios, ni siquiera de spam.
Lo de los componentes de terceros lo he sufrido también. Hubo un momento en que era una buena idea porque Delphi era un mercado bullicioso. La situación cambia cuando encoge. Muchos de esos componentes han sido abandonados y no te digo nada de los que no vienen con código fuente. Quizás la peor faena es quedarse estancado en una versión antigua. Puede que las versiones nuevas tengan pegas, pero al menos están mantenidas. Lo del código generado no lo entiendo. Delphi no genera código para la interfaz visual. La definición está en el DFM en su lenguaje particular y sí que tienes acceso (Alt-F12) y puedes editarlo.
Lo demás que me cuentas sí que me resulta conocido, de forma más o menos directa. Sobre las interfaces web tenía pensado escribir una historieta uno de estos días. Lo que ocurre es que hay por ahí programas para los que es muy importante una interfaz ágil y en ese sentido creo que vamos para atrás.
En fin, gracias por comentar y felices fiestas :-)
DFM
Hola Nico.
No te preocupes que me imaginé que era eso lo que habia pasado con el comentario.
En cuanto al DFM es mas una descripción de la interface que el código que la crea. De forma general es una versión muy mejorada de las diálogos como recursos pero hay algunas "sutilezas" que tienen que ver mas con el código final que se usa, por eso me gusta mas ver el código que el DFM. Yo he usado mucho el DFM y lo encuentro muy útil ( como cuando quiero hacer que una forma ya hecha herede de otra, hacerlo cambiando el DFM es rápido y facil ), sin embargo he tenido situaciones donde me hubiera gustado mas ver el momento exacto de creación de un objeto y el momento en que se le asocian sus propiedades , etc. Yo se que son casos rebuscados pero me ha pasado, no creo que el DFM sea malo, pero prefiero el código.
Y es cierto que en cuanto a agilidad de interface gráfica .NET no se lleva las palmas, a pesar que funcionalmente me gusta, parece que en MS los encargados de estos temas piensan que la gente debe comprar supermáquinas de escritorio y eso si es frustrante, yo por eso no he abandonado C++.
Saludos y felicidades,
Angel Ochoa
DFM
sin embargo he tenido situaciones donde me hubiera gustado mas ver el momento exacto de creación de un objeto y el momento en que se le asocian sus propiedades , etc. Yo se que son casos rebuscados pero me ha pasado, no creo que el DFM sea malo, pero prefiero el código.
No creo que sean rebuscados. Es muy común querer asignar una propiedad al crear el objeto y, si lo haces en el constructor como parece lógico, te encuentras con que después no está. Reescribir el método Loaded es la respuesta, que ésa sí parece un poco rebuscada. Creo que tendrían que haber creado un evento.
Lo de código contra DFM es una polémica vieja. Hay un libro de Danny Thorpe donde se explicaban bastantes decisiones de diseño de la VCL, entre ellas la de usar DFM. No tengo ya el libro, pero creo recordar que no me terminaba de convencer.