Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Kylix 3.0 Open Edition lista para bajar

Programación
Por tuxete
departamento programación-RAD-ical , Sección Desarrolladores
Puesto a las Sat Aug 24th, 2002 at 01:39:59 PM CET
Primero se anunció su salida que provocó la alegría de muchos al saber que tendría soporte para C++ además de Object Pascal, más tarde salió la versión Enterprise Trial, pero ahora ya tenemos una versión completa para desarrollo de aplicaciones GPL.

La podeís encontrar aquí.

¿Usas alguna de sus versiones anteriores? ¿Crees que es conveniente desarrollar aplicaciones con Kylix o hay que seguir la tradición GTK/Qt?

 


< Resumen de seguridad de la semana (0 comments) | Bailando Samba (fácilmente) (0 comments) >
Enlaces Relacionados
· aquí
· More on Programación
· Also by tuxete

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Kylix 3.0 Open Edition lista para bajar | 12 comentarios (12 temáticos, editoriales, 0 ocultos)
Librerías compartidas (5.00 / 1) (#1)
por NoP a las Sat Aug 24th, 2002 at 01:00:11 PM CET
(Información Usuario)

Le comentaba al autor de la noticia en el IRC de escomposlinux que creo que una de las cosas más importantes para que Kylix sea usado en Linux masivamente (lo cual creo qué sería bueno, siempre que lo vayan depurando y optimizando, por cuestiones de portabilidad de programas Windows -> Linux) es el tema de las librerías compartidas.

Con Kylix 2 (y 1), tu programa necesitaba una librería compartida de 6MB que tenías que copiar en el mismo directorio del programa, y hacer un script que añadiera el directorio actual "." en el LD_LIBRARY_PATH (para que encuentre la librería). Esto lo hace muy "a la windows" (programas en directorios separados, como /opt/miprograma, etc).

Creo que alguien (y se lo he propuesto al autor del artículo con mi ayuda si procede) debería crear paquetes DEB y RPM de estas librerías (de las 3 versiones de kylix, si fuera posible) de forma que los usuarios sólo tuvieran que bajar los binarios de los programas por separado (que ocupan poco) y éstos fueran directamente instalables en el árbol de directorios de Linux. Además las librerías compartidas se instalarían en /usr/lib o similar, que es donde deben estar, y no tendríamos que tener varias librerías por cada programa Kylix. Esto es, en resumen, INTEGRAR kylix en Linux, que es lo que hay que hacer.

¿qué opinais?





Un carajal (5.00 / 1) (#8)
por DopeRider a las Sat Aug 24th, 2002 at 09:52:30 PM CET
(Información Usuario)

Cuando Borland se decidió a hacer Kylix descartó tras los primeros estudios crear el armazón de interfaz gráfica como lo tenían hecho en Windows, es decir directamente sobre el API (GDI en Windows, Xlib en Linux). Así que les quedaban dos opciones. GTK o QT.

Dijeron que QT se adecuaba técnicamente mucho mejor a su forma de trabajar que GTK. La verdad es que detrás de QT hay una empresa y pensaban que podrían entenderse más fácilmente con ellos. De hecho soltaron "mucho dinero" a QT para comprar la licencia implícita para Delphi de uso profesional de QT.

A la larga creo que la elección de QT fue un error por varias razones. En primer lugar, hay una dificultad técnica de enlace con C++ por el "name mangling" que no sufres con GTK, que es C plano. ¿Sabes qué es la librería ésa que te falta?. Es un envoltorio que importa clases C++ y las aplana, exportándolas en C. O sea, un puente entre QT y Kylix.

Después nos dicen a los de Delphi que C++ es un estándar, cuando resulta que cada compilador tiene su algoritmo de "mangling" y encima lo cambian con las versiones :-P

La pasta que le hayan soltado a Troll Tech se la podrían haber gastado en subvencionar a media docena de hackers para mejorar GTK. Porque además no les ha servido para nada. Dicen que QT 3 tiene demasiados bugs y al menos hace tres meses, cuando estuve mirándolo la última vez, seguían instalando QT 2 en directorio particular.

Lo que hay que integrar en Linux no es Kylix. Es a Borland :-)

[ Padre ]


Cof cof (none / 0) (#12)
por rvr (rvr@infoastro@com) a las Sat Aug 31st, 2002 at 04:44:04 PM CET
(Información Usuario) http://rvr.blogalia.com/

Las Qt son bastante más profesionales que las GTK, la documentación es inmejorable y tienes un soporte técnico de lujo. Sobre si tienen fallos o no, cualquier soft lo tiene y cuando dispones del código fuente, es una ventaja.

Para mi, el problema de Kylix es que usa una versión modificada de las Qt y no puedes distribuir tus programas fácilmente.

[ Padre ]


 
Problemas de licencia (2.00 / 1) (#3)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Sat Aug 24th, 2002 at 02:22:37 PM CET
(Información Usuario)

Para hacer eso habria que consultar a Borland para que lo deje hacer, pero hay un problema bastante serio en lo que dices, culpa de Borland.

Quien use el Delphy o el Builder (mi caso), sabra que dentro de unos meses, B. sacara un parche para corregir algunos fallos garrafales (y para generar otros), y entonces las librerias cambiaran por lo menos de contenido si no de nombre, y seran completamente incompatibles entre si, con lo que vuelta a empezar.

Por otro lado, ¿no se pueden mejorar las fuentes en el editor de texo? Joer, dan pena.

[ Padre ]


 
Totalmente de acuerdo (1.00 / 1) (#4)
por tuxete a las Sat Aug 24th, 2002 at 02:58:28 PM CET
(Información Usuario)

Eso que dices de las librerias compartidas es imprescindible, y para rematar la faena, las distros deberían incluirlas, para que tambien pudiesen incluirse programas hechos en kylix:

apt-get install mi-programa-kylix
y que tirase de las dependencias... sería perfecto.

[ Padre ]


Compatibilidad descendente... (none / 0) (#5)
por NoP a las Sat Aug 24th, 2002 at 03:32:44 PM CET
(Información Usuario)

¿Son las librerías de Kylix 3 compatibles hacia atrás con las del 2 y 1? Es decir, ¿un programa hecho en Kylix 2 funcionaría con las librerías del 3?

(He puesto este comentario antes pero no sé porqué NO ha salido :-?).



[ Padre ]


No y No (none / 0) (#6)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Sat Aug 24th, 2002 at 04:38:43 PM CET
(Información Usuario)

Y ni siquiera entre dos parches sucesivos. Cada librería va con su versión de programa, y si usas otra, peta. Y no tiene control de versiones ni nada, al estilo de "La versión de esta DLL no es compatible con el programa"... simplemente da un error y ya está. Eso vienen siendo así desde el Builder 1 hasta el 6, e incluso a veces ni siquiera son compatibles en código fuente.

[ Padre ]


 
¿No se puede compilar estáticamente? (none / 0) (#9)
por xsidius (xsidius@QUITAESTOescomposlinux.org) a las Mon Aug 26th, 2002 at 03:09:38 PM CET
(Información Usuario) http://tira.escomposlinux.org

¿Esas librerias no hay opción de meterlas en el binario? En el C++ Builder puedes compilar muchas estáticamente como por ejemplo las VCL (hablo de memoria y se me dan mal las siglas) que hace que muchos programas simples no necesite instalador.

[ Padre ]


 
Moderación y votos (none / 0) (#2)
por NoP a las Sat Aug 24th, 2002 at 01:41:39 PM CET
(Información Usuario)

Por cierto, perdón pero al votar no vi lo de "Indiferente" y voté sin saber que se podían elegir las categorías. Obviamente la noticia me interesa, y la habría marcado como tal :-(.



[ Padre ]


 
Impresiones varias (5.00 / 1) (#7)
por NoP a las Sat Aug 24th, 2002 at 04:42:35 PM CET
(Información Usuario)

Equipo: Pentium 1 - 233Mhz, 96 de RAM.
O.S.: Debian Woody

[sromero@tatil:~]$ ls -l /dos/d/kylix3_open.tar.gz
-rwxrwxrwx 1 root root 333403609 ago 24 15:43 /dos/d/kylix3_open.tar.gz

[sromero@tatil:~]$ du -sh /opt/kylix3_oe/
175M /opt/kylix3_oe

Para arrancarlo, 2 binarios separados: startdelphi y startbcb.

Tengo que decir que el arranque inicial (donde crea las fuentes y tal) es muy lento LA PRIMERA VEZ, pero luego me arranca en unos 15 segundos, el IDE es muy usable, aunque la compilación lenta en mi PC.

Los binarios no son muy gordos (ejem) y NO usan libwine (como yá sabíamos) aunque las librerías sí que son algo gordas:

[sromero@tatil:~]$ ls -l Project2
Project2 Project2.o Project2.tds

: [sromero@tatil:~]$ ls -l Project2
-rwxr-xr-x 1 sromero sromero 826060 ago 24 16:34 Project2

: [sromero@tatil:~]$ ldd Project2
libborqt-6.9.0-qt2.3.so => not found
libdl.so.2 => /lib/libdl.so.2 (0x4001e000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40022000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400fc000)
libc.so.6 => /lib/libc.so.6 (0x40110000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

: [sromero@tatil:~]$ ls -l /opt/kylix3_oe/bin/libborqt-6.9.0-qt2.3.so
-rwxr-xr-x 1 root root 7526184 ago 16 01:53 /opt/kylix3_oe/bin/libborqt-6.9.0-qt2.3.so

Y la demostracion de que necesitamos paquetizar las librerías:

[sromero@tatil:~]$ ./Project2
./Project2: error while loading shared libraries: libborqt-6.9.0-qt2.3.so: cannot open shared object file: No such file or directory





 
Opinión de un principiante (none / 0) (#10)
por runlevel0 (exterATvullferPUNTes) a las Mon Aug 26th, 2002 at 09:57:55 PM CET
(Información Usuario) http://perso.wanadoo.es/exter

> ¿Crees que es conveniente desarrollar
> aplicaciones con Kylix o hay que seguir la
> tradición GTK/Qt?

Después de leer los comentarios (librerías enormes y no integradas sobre todo) he parado la descarga.

El hecho es que estoy empezando a hacer cosas con C++ y GUIs y estaba probando tanto Anjuta+Glade como Kdevelop+Qtdesgner.
Así que decidí hecharle un vistazo a Kylix3 a ver que tal...

Uno de los puntos fundamentales que tenía en mente al escribir el pequeño proyecto que estoy haciendo era no depender de librerías "exóticas", ya que mi idea es hacer una aplicación para novatos (instalación de drivers nVidia) y no quería tener que bregar con "no lo puedo instalar, me pide una librería y no sé qué es eso...", así que me ciño a la libstdc++ y lo que no domino lo implemento en C y tirando de llamadas al sistema.
Bueno, un "problema" que tengo con mi distro es que tiene el gcc-2.95.x, así que pensé que quizá Kylix podría proveerme de un compilador más moderno hasta que consiga meter el gcc-3.2 (o cambiar de distro).

Bueno, resumiendo; Kylix no aporta nada que necesite; kdevelop me proveé de documentación, depurador (aunque uso DDD, no kdbg), y automatización de proyectos, además de todos las campanitas y silbatos (como dicen los USianos)... Anjuta idem de lo mismo, sólo que la docu la tengo que abrir yo (aunque con la cantidad de pdf que tengo hasta es preferible), glade y qtdesigner me van muy bien, quizá mejor glade que el de QT.

Así que símplemente no veo la necesidad de Kylix, a menos que fuera un aunténtico "crack", lo que no parece ser...

¿Para Delhi Kylix es igual de "freaki" ?



-- S41002


Desde Delphi (5.00 / 1) (#11)
por DopeRider a las Mon Aug 26th, 2002 at 11:35:54 PM CET
(Información Usuario)

¿Para Delhi Kylix es igual de "freaki" ?

No tener que cambiar de lenguaje es una ventaja muy grande... cuando evitas el C++ :-)

Además, sólo has visto la crítica de lo que hay que criticar. Pero también está lo bueno.

  • Editor de código con auto-completar, plantillas y otras muchas formas de acelerar.
  • Diseño visual de interfaces de usuario mucho más completo que el resto de herramientas en Linux. Hablo de oídas. No conozco Anjuta ni KDevelop. Pero es muy fácil: si fueran la mitad de buenos que Kylix en este terreno, habría un güevo más de aplicaciones gráficas hechas con estas herramientas.
  • En la programación de aplicaciones para bases de datos simplemente no hay color. Kylix está muy bien para eso.
  • Ayuda en línea completísima.
  • Un manual... "así de gordo" (viene numerado por capítulos, debe tener unas 400 o 500 páginas).
  • Librería componentizada para hacer cualquier cosa (en Windows) y "muchas cosas" (en Linux). Algunas cosas como hacer un módulo para Apache te vienen convenientemente envueltas hasta hacerlo un juego de niños.
  • Extensibilidad del entorno. En Linux está todavía a medio hacer hasta que se quiten winelib de enmedio. Supongo que para la siguiente versión.


En resumen: habrá un Kylix muy atractivo en una o dos versiones más. NoP ha puesto el dedo en la llaga: falta integración con la forma de trabajar en Linux, lo que ha provocado esa descoordinación que queda tan mal.

Porque las librerías gordísimas no son más que una versión vieja de QT.

[ Padre ]


 
Kylix 3.0 Open Edition lista para bajar | 12 comentarios (12 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda