python - gui - Qt ahora se lanzó bajo LGPL, ¿lo recomendarías en wxWidgets?
pyside (7)
Soy bastante usuario de wxWidgets, en parte por razones de licencia.
- ¿Cómo ve el futuro de wxWidgets en perspectiva del reciente anuncio de Qt que ahora se lanza bajo LGPL?
- ¿Crees que wxwidget sigue siendo una buena opción técnica para nuevos proyectos? O recomendaría adoptar Qt, porque va a ser un estándar de facto.
- También estoy interesado en las posibles implicaciones que esto tendrá en sus enlaces con los lenguajes de scripting más comunes (por ejemplo, PyQt, wxPython, wxRuby). ¿Por qué PyQt es tan poco utilizado cuando tiene un diseñador de grado profesional y wxPython no?
Relacionado:
Actualmente estoy usando pyqt en el trabajo y me encuentro totalmente satisfecho. Tiene mejor documentación (en mi humilde opinión), mejor administración de eventos (el patrón de ranura de señal es de alguna manera más poderoso que el antiguo estilo de devolución de llamada simple) e importar su widget personalizado en un diseñador gráfico como qt-designer es mucho más fácil. Por lo que puedo decir qt-designer es más poderoso que cualquier contraparte de wxpython, como Boa Constructor y pyGlade). También tiene un gran soporte para traducir cadenas de programas en diferentes idiomas (mejor soporte que wxLocale al menos, y puede usar una herramienta como Qt-Linguist que está completamente integrada en el sistema qt).
Estoy usando wxpython en algunos trabajos hobbistic, pero todavía soy un novato allí. Creo que su mayor ventaja sobre pyqt es tener un aspecto nativo en diferentes plataformas. Este es un gran punto si está desarrollando aplicaciones de Windows / Linux, por ejemplo. En realidad, podría usar "máscaras" para obtener un aspecto nativo con las aplicaciones de Windows-qt, pero no tengo idea de cómo lograrlo (lo siento, nunca he usado qt en Windows: D).
Elegí wxPython por dos razones principales:
- Boa Constructor, que todavía es un producto beta, me da un control unificado sobre el 100% del proceso, mientras que PyQt tiene un mejor diseñador, pero no hay conexión entre la edición de "controladores de eventos".
Mi IDE ideal diseña, crea eventos, me permite editar solo el código funcional necesario y ejecutar; sin "compilar UIC", sin cambiar de editor, sin entrar en la línea de comando. Mientras que para las aplicaciones a gran escala importa muy poco, mi dominio actual son los programas de escala rápida y pequeña.
Licencias ... no importa ahora, pero lo hará una vez que comience a vender mis cosas en pequeña escala.
El autocompletado dentro del código funcional del evento no parece funcionar en QTDesigner, para el código del evento. Puede que me esté perdiendo algo, pero el proceso "roto" descrito anteriormente impide que sea un RAD.
Honestamente, no creo que la gente cambie masivamente de WxWidgets.
Para python, existen enlaces PyQt y enlaces WxPython. A pesar de que Qt es mucho más práctico que WxWidgets, la mayoría de los programas de código abierto python GUI están escritos con WxWidgets. Como esos programas son de código abierto, la GPL y la LGPL no tuvieron tanta importancia en su elección de herramientas.
Lo mismo ocurre con Gtk. Muchas aplicaciones de código abierto están escritas en Gtk, en Windows, a pesar de que Gtk es muy difícil de trabajar en Windows. Con Qt, esas aplicaciones serían mucho más fáciles de mantener en una plataforma cruzada, pero no ha sucedido.
Por lo tanto, la elección del juego de herramientas está influenciada por muchos parámetros, y la licencia es solo uno de ellos.
Todavía no entiendo por qué Qt no es más convencional, porque en mi opinión es el conjunto de herramientas GUI más fácil y práctico que se haya escrito.
Nunca pude configurar Qt para realizar una compilación cruzada. Recuerdo haber visto algo de Trolltech diciendo que oficialmente no admiten la compilación cruzada, aunque ahora no puedo encontrarlo.
Hay muchas guías que detallan cómo hacer que Qt realice la compilación cruzada, por lo que es posible (probable) que estuviera haciendo algo mal.
Al elegir un marco, recomiendo considerar y probar sus capacidades de compilación cruzada.
Para aquellos de nosotros que se sienten atraídos por wxWidgets porque es la biblioteca multiplataforma que usa controles nativos para una apariencia adecuada, el cambio de licencia de Qt tiene pocas o ninguna consecuencia.
Editar:
Respecto a
Qt no tiene controles nativos sino funciones nativas de dibujo
permítanme citar la página wiki de wxWidgets comparando kits de herramientas :
Qt no tiene puertos nativos verdaderos, como lo hace wxWidgets. Lo que queremos decir con esto es que, aunque Qt los dibuja de manera bastante realista, Qt dibuja sus propios widgets en cada plataforma. Vale la pena mencionar que Qt viene con estilos especiales para Mac OS X y Windows XP y Vista que usan API nativas (Apariencia Manager en Mac OS X, UxTheme en Windows XP) para dibujar primitivas de widget estándar (por ejemplo, barras de desplazamiento o botones) exactamente como cualquier aplicación nativa. El manejo de eventos, la retroalimentación visual resultante y el diseño del widget siempre son implementados por Qt.
Qt es un marco muy completo y de alta calidad. Estoy seguro de que muchos proyectos nuevos que habrían usado wxWidgets ahora usarán LGPL Qt. Pero los proyectos que ya están usando wxWidgets continuarán usando wxWidgets en lugar de realizar una reescritura masiva.
Tenga en cuenta que, a partir de enero de 2009, mientras Qt 4.5 iba a estar disponible bajo LGPL, Riverbank Computing no había hecho ningún anuncio sobre la concesión de licencias para versiones futuras de PyQt . PyQt sigue siendo solo commercial/GPLv2/GPLv3 .
Como se señaló en los comentarios para esta respuesta, Nokia anunció el proyecto PySide licencia LGPL en agosto de 2009.