DD.
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[decaio]](/images/smilies/nuevos2/decaido.gif "decaido")
FuckingFreaky escribió:Sí, la verdad que me fui a google y encontré esa y otra página.
Así como para otras cosas no, para manejar portage a mí me resulta más cómoda la consola. Voy a ver el Kuroo ese de todas formas.
Salu2!
P.D: Kuroo... buaaaaah!!! Mierda de Qt!
![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
. No sé, soy un poco maniacoparanoico con esto de las librerías.
FuckingFreaky escribió:Jajaja! No vamos a empezar aquí un GTK VS Qt, ni me voy a poner a explicar por qué no me gusta Qt... Pero vamos, en este caso, si fuera una "killing application", como GIMP ó Firefox... me lo pensaría. Bueno... la verdad es que no, porque si no me pondría K3B,
Pero vamos, que por una aplicación para manejar portage que no sé si me va a aportar algo realmente bueno, tampoco me voy a comer el coco. Realmente créeis que merecen la pena este tipo de aplicaciones? Es que no sé realmente lo que me puedo ahorrar... pero bueno, seguramente le dé una oportunidad a alguna.
Salu2!
Muchas veces esas barreras no 'nos las ponemos' si no que 'nos las ponen'. Por ejemplo las Qt funcionan horriblemente en Alpha (como todo kde) y las GTK de lujo; sin embargo si vas a otros SOs como Windows o MacOSX entonces las GTK empiezan a apestar de lo lindo y las Qt a funcionar 'de miedo'.
).
Por cierto, estás emocionado con los Alpha, eh?. ¿Tan bien van? ¿Tienes uno? ¿Uso doméstico ó sólo servidor? Todas estas cosas siempre me han intrigado bastante. Ya de paso... me recomiendas alguna página para saber un poquito más de alpha? Sus ventajillas, cosas mejorables y demás...
Sé que me vas a odiar... pero allá vamosbpeople escribió:FuckingFreaky: si no es mucho preguntar, ¿por qué las librerías QT no van con la filosofía que quieres seguir?
...Jué, pero qué feooooo!!! Ya sé que para ti es secundario, pero es que a mí me gustan más las pijaditas gráficas mientras no recarguen mucho.Ferdy escribió:Por eso tiendo a usar aplicaciones basadas en slang o ncurses
FuckingFreaky escribió: Sé que me vas a odiar... pero allá vamos
1. Ante todo... Qt es horribleeeeeee!!! Dios... se le pueden poner más brillos y pijadas a las aplicaciones Qt? Yo es que me siento como agobiado. Más y más rediseño gráfico, más y más brillo y colorines y pijaditas. Las aplicaciones KDE/Qt tienen a tener todas las vistosidades del mundo que, en mi opinión, acaban afectando mucho a la usabilidad. Prefiero algo más ligero, más directo, más... GTK
FuckingFreaky escribió:
2. Segundo... Ahora no sé si seguirá así el tema (dudo que haya cambiado por su origen), pero hasta donde yo sé las Qt no siguen el estándar de C++. Están programadas en C++ pero sin embargo utilizan un montón de funciones propias para realizar operaciones estándar de C++. Han hecho un rediseño de C++ adaptándolo a sus Qt, y eso es algo que no me gusta nada de nada.
Por ejemplo, GTK, están hechas en C, aunque hay "bindings" para distintos lenguajes como GTKmm, que son las destinadas a C++. Bien, tú con GTK puedes utilizar cualquier función estándar de C++ y lo puedes aplicar en la realización de la propia interfaz. Puedes utilizar herencia, polimorfismo, etc. Muchas de estas cosas, ya digo que hasta donde yo vi, en Qt las tienes que hacer con funciones rediseñadas para la ocasión. Soy muy pijo ó muy gilipollas para estas cosas, sí... pero es que me jode muchísimo el tema de saltarse estándares. Si lo podían hacer estándar, ¿por qué no lo hicieron? Soy un aférrimo defensor de éstos, y más en casos así dnode no ha sido por imposibilidad de realizar algo.
FuckingFreaky escribió:
3. Esto pasa tanto con una como con otra, pero ya que me he puesto a criticar, lo digo todo. Igual esta crítica es injustificada por no tener ni puñetera idea de programación seria, así que ya me diréis... El caso es que ODIO que se vinculen GTK/Gnome y Qt/KDE. ¿Por qué cuando yo voy a instalar una aplicación preciosa GTK de repente me encuentro conque tengo que instalar tropecientas librerías de Gnome? ¿Por qué para instalar casi cualquier aplicación Qt me tengo que meter el kde-libs pa' dentro? Sencillamente, me jode. Pero ay digo que ésto seguramente sea muy infundado por falta de conocimiento. Pero... realmente es necesaria esa dependencia? No se pueden hacer aplicaciones independientes del escritorio?
Ferdy, cómo cuánto cuesta una estación alpha? No encuentro sitios con precios por internet!
A no ser que busques alguna en el ebay....Perdón por el ladrillo, pero espero que haya quedado clara mi postura
Pero las Qt van muy destinadas a ese tipo de diseño... Esto es totalmente personal, ni bueno ni malo, pero yo cada vez soy más simplista. Me gustan las aplicaciones gráficas, pero sencillas y nada "bloated" (será posible de que no me acuerde de la palabra equivalente en español?xD). Pero bueno, esto no es ni bueno ni malo, simplemente personal.episode96 escribió:Bueno, eso es personal y ahí no me meto. A lo que en GTK/Gnome le suelen llamar usabilidad yo muchas veces le llamo falta de funcionalidad, pero como digo eso es cuestión de gustos y del enfoque que se le quiera dar. Sólo ten en cuenta que no depende tanto del toolkit, sino de lo que el programador quiera hacer con su aplicación.
Sí, pero el tema es que a la hora de programarlo... por lo que yo he entendido, cosas que podrías hacer con funciones estándar de C, tienes que hacerlas con funciones definidas por Qt. Y lo que no recuerdo ya de Qt es si utilizaba absolutamente todas las posibilidades de polimorfismo, herencia, encapsulamiento, etc... No lo recuerdo ya, la verdad.episode96 escribió:QT usa un "preprocesador" de modo que implementa nuevas construcciones en el lenguaje -principalmente signals y slots-, eso es cierto. Pero decir que eso es saltarse los estándares es como decir que con el preprocesador estándar de C ya no estás creando C por poder definir construcciones que no son C propiamente dicho. Una vez procesado el código que tu escribes por la herramienta moc de QT, el código resultante es 100% C++ puro y duro, y la prueba es que al final es justo ese código C++ lo que compila el compilador GNU.
), pero por ver si te aclara ó me aclaras algo , que ya digo que no soy ni mucho menos experto.
Why not just use Qt if you like C++ so much?
gtkmm developers tend to prefer gtkmm to Qt because gtkmm does things in a more C++ way. Qt originates from a time when C++ and the standard library were not standardised or well supported by compilers. It therefore duplicates a lot of stuff that is now in the standard library, such as containers and type information. Most significantly, they modified the C++ language to provide signals, so that Qt classes can not be used easily with non-Qt classes. gtkmm was able to use standard C++ to provide signals without changing the C++ language.
How does gtkmm compare to Qt?
1. gtkmm uses pure C++. Qt requires extensions to C++ that are parsed by the moc pre-processor.
2. gtkmm uses std::string, std::list, std::vector, iterators, etc. Qt has it's own Qt-specific containers.
3. With gtkmm normal C++ memory management can be used. Qt demands that all widgets are dealt with as pointers, and that deletion of widgets is surrendered to parent widgets.
4. Arrangement of widgets seems to be simpler in gtkmm. In Qt, Containers and Layouts are separate classes, and child widgets must be added to both.
5. The gtkmm API tends to be more explicit. The behaviour of Qt classes is often dependent upon the implicit effects of confusingly-overridden constructors.
Does the gtkmm API use C types, such as structs?
No, we wrap almost all parameters as C++ classes. which use C++ memory management. If you find parameters that use C types without good reason then we want to know about it.
Does gtkmm support all the C++ goodies like inheritance, polymorphism, etc?
Yes. gtkmm objects are normal C++ objects which implement the GTK+ inheritance model through C++ inheritance. You can do with the gtkmm widgets everything that you can do with any other C++ class.
Does gtkmm use Standard C++ (STL) containers such as std::string and std::list?
Yes, we believe in reusing standard C++ code wherever possible. This might not be obvious at first because:
1.gtkmm has Glib::ustring which has almost the same interface as std::string. This new type exists because the C++ standard does not support UTF8-encoded strings.
2. The gtkmm API uses types such as Glib::ListHandlewhich can be assigned to almost any standard C++ container, such as std::list or std::vector. These intermediate types have been used instead of forcing you to use any particular container.
In addition, some widgets, such as Gtk::TreeView, have interfaces which are very similar to the standard containers. For instance, you can iterate through the selected rows.
Sí, sé que Qt no va necesariamente acompañado de KDE, aunque van muy unidos, como bien dices, porque la inmensa mayoría ha congeniado con ese tándem Qt/KDE.episode96 escribió:Te hablo de KDE/QT que es lo que más conozco. Las aplicaciones QT ya lo dijimos alguna otra vez no dependen de kdelibs. Lo que ocurre es que hay muy pocas aplicaciones que sean sólo QT (ahora mismo sólo se me ocurre Psi). Respecto a si las dependencias son necesarias... a no ser que quieras reinventar la rueda todo el puñetero rato en cada aplicación que escribas, mi respuesta es un rotundo sí. ¿Por qué demonios inventarse un selector de fichero propio si kdelibs ya trae uno? ¿Por qué crear tu propio motor HTML si KDE ya tiene uno? ¿Por qué crear tu propio editor de texto si KDE ya tiene un componente para ello? ¿Por qué crear tu propio parser XML si QT o KDE tienen uno ya hecho? Así puedes seguir hasta que te aburras.
Ahora ten en cuenta que cada uno de esos componentes probablemente están más probados y son más eficientes que los que tú podrías crear tú mismo. Recuerda además que tú estás interesado en crear una aplicación con un objetivo X, pero tu especialidad no son los parsers XML, ni los motores HTML, ni tienes que perder tiempo desviándote del objetivo que a ti te interesa rehaciendo algo que otros ya han hecho.
Por si fuera poco, cada vez que otros actualicen o mejoren esos componentes, tu aplicación automáticamente se va a beneficiar de ello, y eso es justo lo que ocurre en toda aplicación KDE cada vez que mejoran kdelibs/kdebase. Y por eso no tienes más que pasarte por kde-apps.org y verás surgir aplicaciones muy completas en KDE como la espuma, cada vez más, porque el framework de KDE ha alcanzado ya una madurez considerable.
) hacerlo con kde-libs que con librerías independientes, pero en mi opinión el software deberái estar portado ó al menos preparado para poder hacerlo si alguien quiere/necesita hacerlo.Oye! Y por qué tú sí y yo no? Eh, eh! Tú que sabes si soy yo el tío al que le han tocado los 115 millones de € de los euromillones?XD. No, la verdad que no, pero vamos que es más por curiosidad que por otra cosa. Las que he visto por ebay tampoco son excesivamente caras, pero claro supongo que serán patatilla porque tampoco me he patado demasiado.Ferdy escribió:No te la puedes pagar A no ser que busques alguna en el ebay....
Hay una cosa que no entiendo de wxWindows... ¿Se supone que con sólo escribir la interfaz una vez ya la puedes portar sin problemas a los distintos sistemas? Las librerías son propias? Vamos, es que no acabo de ver muy bien la diferencia entre wxGTK y GTK, por ejemplo, y eso de que se vea nativo en cada sistema.Ferdy escribió:Si queda clara... pero tienes el problema de la portabilidad. Una aplicación que utilice kdelibs solo va a correr en Linux. En ese sentido los wxWidgets tienen mucha mejor pinta.
Oye! Y por qué tú sí y yo no? Eh, eh! Tú que sabes si soy yo el tío al que le han tocado los 115 millones de � de los euromillones?. No, la verdad que no, pero vamos que es más por curiosidad que por otra cosa. Las que he visto por ebay tampoco son excesivamente caras, pero claro supongo que serán patatilla porque tampoco me he patado demasiado.
Debería haber dicho que probablemente no te la vendieran así como así... a particulares es complicado comprarlas nuevas (por pasta y porque por alguna razón no te las venden jeje).Hay una cosa que no entiendo de wxWindows... ¿Se supone que con sólo escribir la interfaz una vez ya la puedes portar sin problemas a los distintos sistemas? Las librerías son propias? Vamos, es que no acabo de ver muy bien la diferencia entre wxGTK y GTK, por ejemplo, y eso de que se vea nativo en cada sistema.
FuckingFreaky escribió: Pero las Qt van muy destinadas a ese tipo de diseño... Esto es totalmente personal, ni bueno ni malo, pero yo cada vez soy más simplista. Me gustan las aplicaciones gráficas, pero sencillas y nada "bloated" (será posible de que no me acuerde de la palabra equivalente en español?xD). Pero bueno, esto no es ni bueno ni malo, simplemente personal.
FuckingFreaky escribió: Sí, pero el tema es que a la hora de programarlo... por lo que yo he entendido, cosas que podrías hacer con funciones estándar de C, tienes que hacerlas con funciones definidas por Qt. Y lo que no recuerdo ya de Qt es si utilizaba absolutamente todas las posibilidades de polimorfismo, herencia, encapsulamiento, etc... No lo recuerdo ya, la verdad.
Te pongo varios extractos de la doc de GTKmm (sí, muy imparcial no es,
gtkmm has Glib::ustring which has almost the same interface as std::string. This new type exists because the C++ standard does not support UTF8-encoded strings.
FuckingFreaky escribió: Sí, sé que Qt no va necesariamente acompañado de KDE, aunque van muy unidos, como bien dices, porque la inmensa mayoría ha congeniado con ese tándem Qt/KDE.
Vale, siempre he pensado si habría alguna razón más para usar kde-libs que la que mencionas... Así que ahora viene mi pregunta... Por lo poco que yo sé hay multitud de librerías (y algunas muy buenas) disponibles por ahí para hacer las mismas cosas que puedes hacer con kde-libs. Es decir... que necesitas parser XML, pues hay librerías independientes para ello... y así con "casi" todo. La diferencia es que mientras en uno sólo necesitar meter la librería en cuestión, ya presente en la mayoría de distribuciones de por sí, con kde-libs te metes un pedazo paquete del cual a lo mejor no usas ni un 20%. Esto no sé si es así, pero de serlo, me parece mucho más eficiente y mejor lo otro. La mayoría de esas librerías están portadas a otros sistemas ó son más fácilmente portables que pasar todo kde-libs. Aparte del tamaño y utilización de las propias librerías.
No dudo que a la hora de programar sea mucho más rápido y más fácil (como tu ejemplo, gracias por el link, lo había visto hace tiempo cuando busqué info sobre Qt y GTK
) es de suponer que habrán puesto énfasis en que tenga una interfaz coherente y uniforme para acceder a todo lo que ofrece. Además tienen funcionalidad para aplicaciones de escritorio que ellos mismos han implementado (Kparts, KIO-Slaves...). Eso va a facilitar la vida del programador y le va a permitir que con sólo usar QT/kdelibs tenga prácticamente todo lo que necesita para construir su aplicación. Tienes que verlo desde el punto de vista del programador. El usuario, por pedir, pediría que todos los programas no tuvieran un sólo bug, que todo su código fuente ocupe menos de 300Kbs, que sean rapidísimos y que funcionen en un 386 con 4MB de RAM, pero está claro que eso no puede ser así. Por supuesto a ti como usuario puede que no te compense tener qt + kdelibs sólo para ejecutar K3B, pero eso ya es otro cantar. No creo que alguien que use un *Box y un puñado de terminales vaya a usar K3B para tostar un CD, pero eso ya va como digo en función del tipo de usuario. Simplemente un usuario así y un entorno de escritorio como KDE son cosas incompatibles
Jajaja! A mí es que, qué quieres que te diga, un simple botón Qt me parece ya bloated de por sí,episode96 escribió:Pues ya me dirás porqué van destinadas a ese diseño. Te aseguro que Qt no te crea de la nada mágicamente widgets con cien botones él solito, ni te pone automáticamente colores chillones ni tiene conciencia propia ni nada de eso
A mí 'bloated' me parece la última palabra de moda, y ya no me dice nada
. Y lo de bloated, es que esa mañana llevaba todo el rato leyendo en inglés y no me salía "sobrecargado" ó "hinchado" .Hombre, si no hay otra forma de hacerlo y es tan beneficioso ese sistema... la cosa puede cambiar mucho. Pero no entiendo que si como tú dices al final todo eso crea código C++ puro y duro, ¿cómo es que no se puede hacer de una manera estándar de por sí?episode96 escribió:1) Es sencillo y cómodo de usar.
2) Hasta donde yo sé, C++ no tiene ninguna manera "estándar" que defina de otro modo lo que Qt logra con Signals / Slots, así que de alguna manera tenían que hacerlo. No sé apenas nada de WxWidgets, no sé cómo lo habrán implementado ellos.
3) Como he dicho, en el fondo es una abstracción que al final crea código C++ puro y duro.
Sí, si yo te admito que para algo que no tiene el estándar, puedo ver justificable según qué cosa el hacerlo con "código alternativo" ó no.episode96 escribió:Respecto a herencia, contenedores, y demás críticas que hacen en la página de WxWidgets ... usar Qt no te obliga necesariamente a nada. Todas las características de C++ están disponibles, por supuesto (herencia, polimorfismo...). Tienes libertad para usar QString o std::string según te de la gana. Irónicamente, muchos de los contenedores propios de Qt son más portables que los contenedores estándar STL, porque los compiladores tienen sus pequeñas diferencias a la hora de implementar la STL. Ya que tu aplicación va a depender de Qt de todos modos, ¿por qué no usar contenedores Qt si son útiles? Si te fijas, incluso en el texto que me has citado la gente de WxWidgets admite usar también "extensiones" a C++:
Jajaja! Qué putón que eres...episode96 escribió:Y es que en la práctica, no vas a poder limitarte a usar STL. Por eso existen librerías muy completas que complementan al estándar C++ como
Boost, y algunas de las caracteristicas que ahora se implementan en ellas son tan útiles que serán incorporadas probablemente a la próxima revisión del estándar C++. ¿También se "saltan el estándar" por eso?
. Eso sería actualizar el estándar, y a partir de ahí esas cosas pasarían a utilizarse de forma estándar. Sería algo universal y sería algo que todo el mundo podría seguir. Pero es que estás poniendo Qt en el mismo saco que Boost. Aunque no sémucho de ésta última, creo que la diferencia reside en que mientras las qt hacen cosas a la "qt way" ya posibles de forma estándar, las boost se basan en el estándar para ampliar funcionalidad. No es lo mismo inventar algo nuevo que pueda ser incorporado al estándar, que pasar del estándar para hacerlo a tu forma... Al menos así es como he entendido yo la diferencia, aunque puedo estar perfectamente equivocado.No creo yo que haya que tomarse tan a la ligera las demandas de un usuario... Supongo que sí, que es mucho más faćil programar todo con Qt+kdelibs , y puede que sea muy útil en muchos casos. Lo que pasa es que cuando igual de todo eso que ofrece kdlibs vas a utilizar sólo un 5%... realmente compensa? Es que con esto no sé si digo una barbaridad (por falta de conocimientos), pero... cuando cualquier programa requiere cualquier componente de kdelibs... ha de cargarse el paquete completo? Es que lo que pienso es que muchas veces se pueda dar el caso de utilizar un paquete muy grande que haya que cargar y cargar todo el rato, para realmente utilizar poquísimo de él. Entonces vería mucho más lógico utilizar una librería más pequeña y más destinada a ese propósito que tiene uno.episode96 escribió: Ninguna librería se ve a ajustar nunca exactamente a lo que tú pides, salvo que la hagas tú mismo para un propósito específico. KDElibs se hizo pensando en un objetivo muy claro que era construir aplicaciones gráficas de escritorio, y aunque no he mirado el código (algún día ) es de suponer que habrán puesto énfasis en que tenga una interfaz coherente y uniforme para acceder a todo lo que ofrece. Además tienen funcionalidad para aplicaciones de escritorio que ellos mismos han implementado (Kparts, KIO-Slaves...). Eso va a facilitar la vida del programador y le va a permitir que con sólo usar QT/kdelibs tenga prácticamente todo lo que necesita para construir su aplicación. Tienes que verlo desde el punto de vista del programador. El usuario, por pedir, pediría que todos los programas no tuvieran un sólo bug, que todo su código fuente ocupe menos de 300Kbs, que sean rapidísimos y que funcionen en un 386 con 4MB de RAM, pero está claro que eso no puede ser así. Por supuesto a ti como usuario puede que no te compense tener qt + kdelibs sólo para ejecutar K3B, pero eso ya es otro cantar. No creo que alguien que use un *Box y un puñado de terminales vaya a usar K3B para tostar un CD, pero eso ya va como digo en función del tipo de usuario. Simplemente un usuario así y un entorno de escritorio como KDE son cosas incompatibles
.
FuckingFreaky escribió: Jajaja! A mí es que, qué quieres que te diga, un simple botón Qt me parece ya bloated de por sí,
FuckingFreaky escribió: Hombre, si no hay otra forma de hacerlo y es tan beneficioso ese sistema... la cosa puede cambiar mucho. Pero no entiendo que si como tú dices al final todo eso crea código C++ puro y duro, ¿cómo es que no se puede hacer de una manera estándar de por sí?
FuckingFreaky escribió: Sí, si yo te admito que para algo que no tiene el estándar, puedo ver justificable según qué cosa el hacerlo con "código alternativo" ó no.
El tema está en que hasta donde yo sé, tú no puedes derivar un widget de otro en Qt con la herencia estándar de C++, me equivoco?
FuckingFreaky escribió:Entre ese tipo de cosas que no se pueden hacer y las que se pueden hacer pero se hacen al estilo Qt... no acaba de convencerme. Es decir... vale, yo puedo usar el "qstring" ese ó "string" normal... ¿qué necesidad hay de hacerlo tal como dice Qt? No nos engañemos... la gente que programa para qt, acabará utilizando todas esas funciones que empiezan por "q", incluso a pesar de que las estándar hagan lo mismo. Y eso al final acaba en un código, en mi opinión, mucho menos claro. Me parece enredarlo todo sin necesidad.
FuckingFreaky escribió: Jajaja! Qué putón que eres...
FuckingFreaky escribió: No creo yo que haya que tomarse tan a la ligera las demandas de un usuario...
FuckingFreaky escribió: Supongo que sí, que es mucho más fácil programar todo con Qt+kdelibs , y puede que sea muy útil en muchos casos. Lo que pasa es que cuando igual de todo eso que ofrece kdlibs vas a utilizar sólo un 5%... realmente compensa? Es que con esto no sé si digo una barbaridad (por falta de conocimientos), pero... cuando cualquier programa requiere cualquier componente de kdelibs... ha de cargarse el paquete completo? Es que lo que pienso es que muchas veces se pueda dar el caso de utilizar un paquete muy grande que haya que cargar y cargar todo el rato, para realmente utilizar poquísimo de él. Entonces vería mucho más lógico utilizar una librería más pequeña y más destinada a ese propósito que tiene uno.
Como ya digo no sé si es una burrada, porque igual kdelibs puede cargar en memoria sólo las partes que necesita un programa... bueno, no sé, me estoy haciendo un lío con esto, ya lo explicaré mejor.
Briareos_H escribió:P.S.: el talibán Qtero ataca de nuevo
