¿Qué ven que le falta a Lazarus para despegar ?

[[Al González]]

Empezado por Ñuño Martínez

El primero es el entorno para generar ejecutables para sistemas con microprocesador ARM y Windows CE, el segundo es el entorno para generar ejecutables para Windows de 32 bit (95, 98, NT, Me y XP) con microprocesadores de la familia i386 y la biblioteca GDI, y el tercero es el entorno para generar ejecutables para Windows de 32 bit con microprocesadores de la familia i386 y la biblioteca Qt.

Yo creo que está claro, ¿no?

Muchas gracias por la descripción, Ñuño. Ya había instalado los tres por no tener claro qué era cada uno. Cuando vi el nombre del primer archivo en la página de descarga me pregunté, ¿qué será eso de "Wince"? (pronunciándolo como si fuera una sola palabra).

Otra pregunta, para seguir enriqueciendo la información de este debate, y ahora que sé que GDI y QT son bibliotecas. A grandes rasgos, ¿qué diferencias tienen entre sí? ¿Cuando conviene usar GDI y cuándo QT?


Variando el tema, por la manera en que me citaste luego (y vaya que me extrañó de ti ), pareciera que te molestaron mucho las observaciones que hice. A ver si sirve esto de algo, pero de cualquier manera lo aclaro: No pretendo descalificar a Lazarus sin conocer la herramienta. Si me he dado tiempo de instalarla y comenzar a explorarla es porque precisamente me ha terminado por interesar. Las observaciones que hice son un ejercicio de lo que podrían estar detectando algunos programadores familiarizados con Delphi u otros IDEs a la hora de usar Lazarus por primera vez. Como dije antes, no son concluyentes, ni se tratan de las características más importantes, pero si creo que son detalles interesantes a los que valdría la pena poner atención.

Se hace mucho hincapié en que no se le compare con Delphi. Pero cuando no pasa un solo mes sin que leas o escuches el consejo de usar Lazarus en lugar de Delphi, resulta muy difícil evitar hacer algunas comparaciones. Seamos honestos, Lazarus se propone como alternativa a Delphi, por tanto son comparables entre sí.

Empezado por Ñuño Martínez

De todas formas, tiene opciones para limpiar el ejecutable de toda la ganga necesaria para la depuración y medición del rendimiento, todas ellas controlables desde los diálogos de configuración del compilador de Lazarus. Bien utilizados permiten generar ejecutables muy compactos.

Esta parte me parece de lo más útil, gracias por mencionarlo. Así vamos desmitificando aquello que muchos hemos escuchado acerca de que Lazarus genera ejecutables muy grandes. Es una buena noticia para los que no teníamos idea de esos cuadros de diálogo.


Para cerrar esta entrada con un poco de más "bla-bla-bla" (a veces creo que escribo en vano ), mi opinión hasta al momento sobre Lazarus (no Firebird, eso es otra cosa ) se aproxima bastante a la de David Esperalta, respecto a que para algunos proyectos sería adecuado usarlo. Ojalá no tarde mucho en volverse una herramienta más competitiva, que la gente tenga a bien usar en muchos más tipos de proyectos.

Un abrazo que pretende construir.

Al González.

[roman]

Empezado por Al González

mi opinión hasta al momento sobre Firebird se aproxima bastante a la de David Esperalta, respecto a que para algunos proyectos sería adecuado usarlo. Ojalá no tarde mucho en volverse una herramienta más competitiva, que la gente tenga a bien usar en muchos más tipos de proyectos.

Je, je. Me parece que andas con un ojo al gato y el otro al garabato.

// Saludos

[[Al González]]

Empezado por roman

Je, je. Me parece que andas con un ojo al gato y el otro al garabato.

// Saludos

Perdón. Es que hoy amanecí con treinta p' correos en la bandeja de entrada, y lo peor es que la mayoría eran unas increíbles declaraciones sobre el "buen manejo" de las reglas de negocios.

Al final terminé borrándolos por llevar tanto fundamentalismo informático.

[mamcx]

A Lazarus lo que le falta es un jodido enfoque. Soporta tantas plataformas, widgets, sub-widgets & demas que no es completamente bueno en nada.

Lo mas crucial al hacer un software es darle un norte definido. Definitivamente, Lazarus no lo tiene... tiene como 7 u 8, no se.

Asi que el problema de lazarus es como esta organizado el proyecto a nivel interno... no tiene un liderazgo claro, no tiene un norte claro y por ende todo queda casi terminado.

Por fortuna, ultimamente ha ido subiendo y hasta empresas han ido portando cosas a este entorno, pero sospecho que era una reaccion a la inestabilidad del asunto con Borland... si Delphi sigue en buen camino como con el 2009 y los de lazarus no se pellizcan y se enfocan, van a perder el momentum.

En mi opinion:

- Concentrarse o en aplicaciones de servidor o en clientes
- Si es en clientes, solo soportar win32, una y sola una de linux y coccoa (o carbon, si lo terminan cualquiera sirve ya) y mandar al carajo al resto. Si va ser pa' hacer software de escritorio, mejorar el soporte pa' Windows & Mac (que es donde esta el mercado) y si es para el servidor mejorar el soporte web profundamente.
- Decidir si van a ser un clon de Delphi, o van a seguir su propio camino.

-- Si son un clon de Delphi, serlo bien. Si no, dejar de intentar que se parece a Delphi, cuando no lo hace.
-- Marcar un deprecated rapido de su propio IDE y usar cualquier otro IDE que sea que este bien para implementar una extension. Hay muchos que son mejores (VS, Komodo, NetBeans, Eclipse). Es claro que no estan haciendo nada bueno ahi... y la verdad, el chiste es el framework. Hay quienes han hecho un mejor trabajo con los IDES y hasta hacer un toolchain bien bueno con editores de texto y otros les quitaria un peso de encima.
- Tratar de hacer una caracteristica principal y reforzarla a lo largo de todo el producto. Ejemplo, Ruby & Python han despegado & mucho porque con Rails & Django se enfocaron en hacer sitios web rapido. Aunque obviamente sirven para mucho mas es claro que tener una obvia & visible caracteristica es vital para atraer & mantener.
- Resolver la instalacion & hacerla mas amigable.
- Tener un plan solido de releases
- Y liderazgo

Basicamente, deberian tener el coraje de mandar al carajo tanto como puedan y concentrarse en un manojo de cosas y hacerlas bien.

[Ñuño Martínez]

Empezado por Al González

Otra pregunta, para seguir enriqueciendo la información de este debate, y ahora que sé que GDI y QT son bibliotecas. A grandes rasgos, ¿qué diferencias tienen entre sí? ¿Cuando conviene usar GDI y cuándo QT?

GDI es el entorno gráfico por defecto de Windows, el que gestiona las ventanas, su representación, etc. Está definida en la "UNIT Windows", por si quieres echarle un vistazo.

QT es una biblioteca que define una serie de clases que facilita la gestión y representación de ventanas de manera que los programas que la utilicen puedan ser compilados en distintas plataformas y sistemas operativos. Es decir, que si escribes un programa utilizando GDI sólo funcionará en Windows mientras que utilizando QT puedes compilarlo en cualquier plataforma que disponga de una versión de QT (varios Windows, UNIX, creo que también MacOS y alguno más).

GTK+ es otra biblioteca al estilo de QT, que sigue una filosofía diferente a QT pero que también está disponible en muchas plataformas. Inicialmente fue desarrollada para servir de base a The GIMP (de ahí su nombre: GIMP Tool Kit), para facilitar su portabilidad.

En resumidas cuentas:

• GDI: Sólo para Windows. Escrito en C. Base del escritoro Windows.
• QT: Varias plataformas. Escrito en C++. Base del escritorio KDE.
• GTK+: Varias plataformas. Escrito en C. Base de los escritorios GNome y Xfce.

Empezado por Al González

Variando el tema, por la manera en que me citaste luego (y vaya que me extrañó de ti ), pareciera que te molestaron mucho las observaciones que hice.

Si lo dices por el "[Blablabla, y tal pascual, y no sé qué mas...]", lo puse solamente para no repetir todos los puntos. No me molestaron, y mi comentario fue sólo para completar información.

Sinceramente, creo que ninguno de los comentarios que has escrito en estos foros y que he leído me han molestado un ápice. Bueno, siendo sincero tal vez hay una cosa que sí me molesta un poquitín: casi siempre das en el clavo, algo que a mi me cuesta bastante, y siento un envidia...

[Casimiro Noteví]

Y ya que estás tan puesto en el tema, Ñuño, una preguntita: si uso GNOME y uso un programa que se ha creado con las QT, ¿me ejecuta QT sobre GTK?, y también imagino que si en KDE uso un programa creado con las GTK, éstas se ejecutarán (e instalarán) sobre QT.
No tengo ni idea de cómo se relacionan entre ambas, pero supongo que será un desperdicio de recursos, por ejemplo, usar KDeveloper sobre Ubuntu (GNOME), no?

[Ñuño Martínez]

Empezado por Casimiro Notevi

Y ya que estás tan puesto en el tema, Ñuño, una preguntita: si uso GNOME y uso un programa que se ha creado con las QT, ¿me ejecuta QT sobre GTK?, y también imagino que si en KDE uso un programa creado con las GTK, éstas se ejecutarán (e instalarán) sobre QT.
No tengo ni idea de cómo se relacionan entre ambas, pero supongo que será un desperdicio de recursos, por ejemplo, usar KDeveloper sobre Ubuntu (GNOME), no?

Gracias por confiar en mi. Espero estar a la altura.

Para responder a tu pregunta te diré que en mi casa tengo un escritorio Xfce (GTK+) y el programa que utilizo para escuchar y gestionar mi música es Amarok (KDE) y hasta ahora no he tenido problemas.

QT y GTK+ son simples bibliotecas que "traducen" las llamadas de los programas a peticiones de servicio a un servidor X Window (que es el programa que administra las entradas del usuario y dibuja las cosas en pantalla), por lo que (en principio) no importa qué escritorio estés utilizando.

En principio no es necesario utilizar QT, GTK+ u otra biblioteca similar ya que se puede programar una aplicación gráfica realizando llamadas directamente a las X Window. Es más, la terminal "XTerm" que viene en casi todos los Linux está implementada de esa forma. Lo que pasa es que X Window implementa sólo lo básico y no incluye ningún tipo de adorno ni facilita el dibujo de "estilos". Es más: no pone títulos a las ventanas ni permite moverlas con el ratón, ya que esto es un añadido del gestor de escritorio (o "Desktop Manager"), esto es, GNome, Wince, KDE, Xfce, etc.

Como curiosidad, y ya que estamos en este hilo, Lazarus tiene su propia biblioteca de controles gráficos: la LCL. Esta está implementada de forma que puede compilarse para el GDI, GTK+, KDE, Cocoa, Carbon y fpGUI. Esta característica hace que, aunque se intenta mimetizar la VCL/CLX, haya cosas que no sean "compatibles" con Delphi, pero en contrapartida tiene la ventaja de que se puede compilar la aplicación en más plataformas sin necesidad de hacer apenas cambios. Normalmente se compila en "default", es decir, que compila para la misma biblioteca en la que esté funcionando, pero a veces viene bien especificar un entorno concreto, sobre todo para hacer algo en bajo nivel, aunque entonces se corre el riesgo de reducir la portabilidad del programa.

Creo que no me dejo nada, y espero que no os hayáis perdido.

[[Chris]]

Empezado por mamcx

A Lazarus lo que le falta es un jodido enfoque. Soporta tantas plataformas, widgets, sub-widgets & demas que no es completamente bueno en nada.

Lo mas crucial al hacer un software es darle un norte definido. Definitivamente, Lazarus no lo tiene... tiene como 7 u 8, no se.

Asi que el problema de lazarus es como esta organizado el proyecto a nivel interno... no tiene un liderazgo claro, no tiene un norte claro y por ende todo queda casi terminado.

Por fortuna, ultimamente ha ido subiendo y hasta empresas han ido portando cosas a este entorno, pero sospecho que era una reaccion a la inestabilidad del asunto con Borland... si Delphi sigue en buen camino como con el 2009 y los de lazarus no se pellizcan y se enfocan, van a perder el momentum.

En mi opinion:

- Concentrarse o en aplicaciones de servidor o en clientes
- Si es en clientes, solo soportar win32, una y sola una de linux y coccoa (o carbon, si lo terminan cualquiera sirve ya) y mandar al carajo al resto. Si va ser pa' hacer software de escritorio, mejorar el soporte pa' Windows & Mac (que es donde esta el mercado) y si es para el servidor mejorar el soporte web profundamente.
- Decidir si van a ser un clon de Delphi, o van a seguir su propio camino.

-- Si son un clon de Delphi, serlo bien. Si no, dejar de intentar que se parece a Delphi, cuando no lo hace.
-- Marcar un deprecated rapido de su propio IDE y usar cualquier otro IDE que sea que este bien para implementar una extension. Hay muchos que son mejores (VS, Komodo, NetBeans, Eclipse). Es claro que no estan haciendo nada bueno ahi... y la verdad, el chiste es el framework. Hay quienes han hecho un mejor trabajo con los IDES y hasta hacer un toolchain bien bueno con editores de texto y otros les quitaria un peso de encima.
- Tratar de hacer una caracteristica principal y reforzarla a lo largo de todo el producto. Ejemplo, Ruby & Python han despegado & mucho porque con Rails & Django se enfocaron en hacer sitios web rapido. Aunque obviamente sirven para mucho mas es claro que tener una obvia & visible caracteristica es vital para atraer & mantener.
- Resolver la instalacion & hacerla mas amigable.
- Tener un plan solido de releases
- Y liderazgo

Basicamente, deberian tener el coraje de mandar al carajo tanto como puedan y concentrarse en un manojo de cosas y hacerlas bien.

Completamente de acuerdo. Un refrán de mi abuela: "El que mucho abarca, poco aprieta" Definitivamente nunca avanzará hasta que se limiten en las plataformas que quieren soportar. Sería sufiente con Win32, Mac OS X y Linux (Qt y GTK2 (olvidense de GTK1)). y también a cómo dijó mamcx, tomar el código de un IDE ya maduro y adaptarlo a las necesidades para hacer un clon de Delphi.

Lástima que este proyecto no tiene a un gran visionario y mente lucida para llevarlo adelante.

Saludos.