Hola, 2008/4/30 Manuel Alejandro Cerón Estrada <[EMAIL PROTECTED]>: > > 2008/4/30 Juan Luis Baptiste <[EMAIL PROTECTED]>: > > > > Yo recomendaría QtJambi [1], es una versión de Qt > > en Java, ojo *no* es un binding the Java para Qt, entonces la > > penalidad de comunicarse con Qt con el caso que decían antes de GTK > > no existe. > > No entiendo a que se refieren con lo de "tener que comunicarse con > GTK". Usando el binding adecuado no es necesario tener que comunicarse > ni nada, todo se usa transparentemente. En mi opinión es mucho mejor > usar bindings que librerías nativas ya que el desempeño es mucho > mejor, por eso las aplicaciones SWING parecen tan lentas. >
Un binding nunca va a ser igual de rápido que la implementación nativa, la razón es muy sencilla. Un binding que es ? un wrapper de un lenguaje hecho en otro lenguaje, lo que al final quiere decir que la llamada a una función en el binding tiene que llamar a la equivalente en el otro. Por ejemplo, el llamado a un método en un binding de java tiene que llamar al método correspondiente en la librería gtk (o cualquier otra), para esto tiene que haber algún mecanísmo de comunciación entre los dos objetos por así decirlo. En el caso de java es RMI, lo que ya lo hace inerentemente más lento que una llamada nativa. QtJambi hasta donde tengo entendido no es un binding sino una implementación nativa de la librería menos un pequeño core que sigue estando en C++, el cuál es llamado nativamente desde Java. > > ... > > > empecé a desarrollar en linux hace varios años probé ambas, y se me > > hizo mucho más sencillo la librería qt, más ordenada, más completa, > > con un mejor soporte multiplataforma (por ejemplo la integración con > > cada s.o., look & feel, dialogos de abrir/guardar, etc) y más claro de > > entender el código escrito, Qt utiliza la misma nomenclatura de Java > > CamelCase que llaman, en GTK es algo como > > "pintar_ventana_configuracion_aplicacion" cosas así, que hacen el > > código menos legible en mi opinión > > El estilo de notación es algo que depende del lenguaje en el que se > use GTK+, cuando se usa en C o en Python se usa la > notación_con_guiones_bajos, cuando se usa en Java o C# se usa el > estilo CamelCase, por ejemplo, miren la documentacion de los bindings > de GTK para Java: > > http://java-gnome.sourceforge.net/4.0/doc/api/overview-summary.html De acuerdo, todo depende de la notación que se haya escogido. GTK usa notación con guiones bajos y a lo que yo me refería es que esa notación es menos legible que CamelCase. > > ... Ahhh y más importante aún, GTK es > > > C, no C++ que no tiene mucho sentido para desarrollar aplicaciones > > gráficas, una aplciación visual se modela más claramente como un > > conjunto de objetos, GTK trata de imitar este comportamiento. En este > > caso es mejor usar gtkmm que son los bindings de C++. > > GTK+ esta escrito en C y eso tiene la ventaja de que es muy fácil > hacer bindings para otro lenguajes. En consecuencia, GTK+ tiene más y > mejores bindings en otros lenguajes. Si usted usa GTK+ desde otro > lenguaje usará el modelo de objetos del lenguaje que esté usando. GTK+ > es una librería completamente orientada a objetos, así que se integra > muy bien en lenguajes como Java y C#. > Tienes a la mano una tabla comparativa que demuestre que hay más bindings para otros lenguajes para GTK que para Qt? yo no puedo asegurar eso a menos que tenga una base para decirlo. Lo que sí puedo decir es qué bindings existen para Qt pero sin asegurar que sean más o menos que los de GTK. Los que yo sé que tiene Qt son: java, perl, python, C#, ruby y lua. > > > ... Una consecuencia > > de esto es que el manejo de eventos se hace con callbacks más > > conocidos como apuntadores a funciones, en Qt se hace con un mecanísmo > > llamado "signals and slots", en el cuál un objeto emite señales (ej. > > click en un boton), y estas se conectan a otros objetos para que > > ejecuten un método específico (los slots), todo se hace en una linea > > de código por función. > > De nuevo, esto depende del lenguaje en que use GTK+. Por ejemplo en C > se usan callbacks, pero en C# se usan eventos y delegados. En java se > usan interfaces, en Python se usan objetos función. > > Exactamente, yo estaba hablando de C, no de ninguno de los demás. Cuando te refieres a interfaces en Java debe ser el mismo mecanismo o similar a swing ? de ser así es muy complejo de utilizar. > En resumen creo que una ventaja de GTK+ es que tiene un mejor soporte > para otros lenguajes de programación. Con esto no quiero decir que no > existan bindings de Qt para otros lenguajes, sólo que no para tantos y > no están tan soportados. > Nuevamente, me gustaría que sustentes este punto. > No conozco tanto Qt como para decir sus desventajas, pero una que yo > le veo es que si usted desarrolla con Qt tiene que usar > obligatoriamente la licencia GPL (o QPL que es casi lo mismo) o de lo > contrario pagar una licencia comercial. > No es del todo una desventaja, lo estás poniendo como si el hecho que tener que pagar por la licencia fuera algo malo sólo por el hecho que vale plata. Ese licenciamiento es más bien un servicio en el cual tienes incluido soporte técnico durante el tiempo que sea válida la licencia. Con una liberería gratuíta como GTK no vas a tener este tipo de soporte, sólo el comunitario, lo que para una empresa desarrolladora de software puede que no sea suficiente cuando hay un deadline que cumplir. En estos casos lo que se necesitan son soluciones rápidas y puntuales, el soporte comunitario a veces puede ser muy demorado y en un ambiente corporativo lo más seguro es que no haya ese tiempo para esperar. Además hay estudios (lo leí en un blog hace muuuuchos años, no tengo la referencia en el momento) en los que se demuestra que el costo de este licenciamiento es de al rededor del 1% del costo del proyecto, un costo muy bajo para los beneficios que trae. Entonces bajo esa perspectiva, que inconveniente hay en pagar por soporte técnico? > Una ventaja de GTK es que es ligeramente más popular, esto representa > más ejemplos de programas, más librerías de terceros y más soporte de > la comunidad. > Yo no me atrevería a decir esto sin números para sustentarlo, porque hasta donde recuerdo (y por favor no entremos en el típico flame) de una encuesta que hace algún sitio en internet que en este momento no me acuerdo, KDE tenía al rededor del 35% del mercado y Gnome un poco menos del 30% lo que refutaría lo que tu dices, pero no lo aseguro porque no recuerdo en este momento en donde fué que leí eso. Y si fuera al contrario, que sea más popular no quiere decir que sea mejor, es sólo que han hecho una mejor labor en "marketing", un simple ejemplo de esto es que Windows y sus API's son los más usados del mundo por ende se podría decir que los más populares, pero esto los hace los mejores ? no creo. > En definitivamente ambas librerías son muy buenas. Lo que más le > recomiendo es que, al igual que hicimos Juan Luis y yo, las pruebe > ambas y se quedes con la que más le guste. > > Completamente de acuerdo, aunque son muy similares para lo que sirven, lo mejor es probarlas y hacerse una opinión propia al respecto. Ahh otra cosa que recuerdo en este momento que hasta donde tengo entendido GTK no tiene pero Qt si, es un API muy fuerte para desarrollo de aplicaciones de red y de consola. Un ejemplo muy bacano es Mumble [1], un servidor de voz sobre IP hecho completamente en Qt 4. [1] http://mumble.sourceforge.net/ Saludos, -- Juan Luis Baptiste _______________________________________________ Lista de correo de Colibri Colibri@listas.el-directorio.org http://listas.el-directorio.org/cgi-bin/mailman/listinfo/colibri El Directorio, el sitio del Software Libre en Colombia: http://www.el-directorio.org
