Hola. El día 2 de mayo de 2008 15:52, Juan Luis Baptiste <[EMAIL PROTECTED]> escribió:
> 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. > Creo que aquí hay una confusión y es que me equivoqué al decir: "En mi opinión es mucho mejor usar bindings que librerías nativas" Lo que quería decir es que es mucho mejor usar un binding de una librería nativa que usar usar código que corra sobre la JVM (o el CLR o el intérprete de Python, etc). En cuestión de rendimiento, por supuesto. > 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. De acuerdo al sitio web de GTK [1], tiene soporte para: C C++ C# ( incluyendo VisualBasic.NET, Boo, Namerle, y todos los que corren bajo el CLR) Java ( incluyendo Scala, Groovy y todos los que corren en la JVM) Python Perl R Guile Ruby PHP Ada OCaml Haskell Lua S-Lang Ahora, ¿Por qué digo que GTK tiene mejores bindings? Bien, haciendo algunas comparaciones: Perl-QT no se actualiza desde 2005 [2]. La última actualización de Perl-GTK fue en Marzo 30 de 2008 [3] Los bindings de C# para Qt murieron por allá en 2003. La nueva versión de los bindings el proyecto Qyoto/Kimono [4], está incompleta y lleva un año sin actualizarse. Gtk# es activamente desarrollada, la última versión salió en Abril de 2008 [5] Qt-lua no se actualiza desde 2005 [6]. Gtk-lua se actualizó en febrero de 2008.[7] PyGTK y PyQT son ambos activamente desarrollados. GTK-Ruby y QT-Ruby estan ambos medio abandonados. Los bindings de java para ambos toolkits están activamente desarrollados. [1] http://www.gtk.org/language-bindings.html [2] http://sourceforge.net/project/showfiles.php?group_id=64773 [3] http://perlqt.sourceforge.net/ [4] http://cougarpc.net/qyoto/ [5] http://www.go-mono.com/archive/1.9.1/ [6] http://www.codenix.com/~tolua/lua_qt/ [7] http://luaforge.net/projects/lua-gtk > 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. Creo que un ejemplo dice más que mil palabras: Button b = new Button("Press me!"); b.connect(new Button.CLICKED() { public void onClicked(Button source) { System.out.println("I was clicked: " + b.getLabel()); } }); A mi no me parece taaan complejo de utilizar. Habría que comparar con Qtjambi. > 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? Hay varias empresas que dan soporte a GTK+ y usted puede contratarlas si *realmente* lo necesita. La más notable es Imendio. Novell también presta el servicio de soporte para GTK#. Creo que RedHat y Canonical tiene algo parecido, pero no estoy seguro. > 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. Estoy de acuerdo. Se necesitan números. Es muy difícil obtener estadísticas reales. Algo que he hecho es contar el número de paquetes dependientes de ciertas librerías en Ubuntu (que tiene cerca de 25.000 paquetes disponibles). Estos son mis resultados: $ apt-cache rdepends libgtk2.0-0 | wc -l 1388 $ apt-cache rdepends libgtk1.2 | wc -l 199 $ apt-cache rdepends libqt3-mt | wc -l 714 $ apt-cache rdepends libqt4-gui | wc -l 294 $ apt-cache rdepends python-gtk2 | wc -l 229 $ apt-cache rdepends python-qt3 | wc -l 33 $ apt-cache rdepends python-qt4 | wc -l 37 $ apt-cache rdepends libgtk2-ruby | wc -l 14 $ apt-cache rdepends libqt4-ruby | wc -l 2 $ apt-cache rdepends libgtk2.0-cil | wc -l 55 $ apt-cache rdepends libqyoto1.0-cil | wc -l 1 $ apt-cache rdepends libqyoto4.3-cil | wc -l 5 $ apt-cache rdepends libgtk2-perl | wc -l 50 $ apt-cache rdepends libqt-perl | wc -l 12 $ apt-cache rdepends libgtk-java | wc -l 10 $ apt-cache rdepends libqt3-java | wc -l 4 $ apt-cache rdepends libqtjambi-java | wc -l 4 $ apt-cache rdepends libqtjambi-java | wc -l 4 Por supuesto estos datos no son, ni medio cerca, determinantes. Pero de algo sirven. La última encuesta [8] que yo vi, le daba un 45% a Gnome contra un 35% a KDE, pero yo no confío en esas encuestas. [8] http://www.desktoplinux.com/news/NS8454912761.html -- · Manuel Alejandro Cerón Estrada · [EMAIL PROTECTED] · http://ceronman.freaks-unidos.net _______________________________________________ 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
