Qt ahora se lanza bajo LGPL, ¿lo recomendaría sobre wxWidgets?

Soy un usuario bastante pesado de wxWidgets, en parte debido a razones de licencia.

  • ¿Cómo ve el futuro de wxWidgets en vista del reciente anuncio de Qt que ahora se lanzará bajo LGPL?
  • ¿Crees que wxwidget sigue siendo una buena opción técnica para nuevos proyectos? ¿O recomendarías adoptar Qt, ya que va a ser un estándar de facto?
  • También me interesan 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 está tan infrautilizado cuando tiene un diseñador de nivel profesional y wxPython no?

Relacionado:

https://stackoverflow.com/questions/443546/qt-goes-lgpl-on-windows-is-it-good-enough-to-use-instead-of-mfc

Para aquellos de nosotros que nos sentimos atraídos por wxWidgets porque es la biblioteca multiplataforma que usa controles nativos para una apariencia adecuada y sentir que el cambio de licencia de Qt tiene pocas o ninguna consecuencia.

Editar:

Respecto a

Qt no tiene controles nativos sino funciones de dibujo nativas.

Permítanme citar la página wiki de wxWidgets comparando los kits de herramientas :

Qt no tiene verdaderos puertos nativos como 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. Sin embargo, vale la pena mencionar que Qt viene con estilos especiales para Mac OS X, Windows XP y Vista que usan API nativas (Appearance Manager en Mac OS X, UxTheme en Windows XP) para dibujar primitivos de widgets estándar (por ejemplo, barras de desplazamiento o botones) exactamente como aplicación nativa. El manejo de eventos, la retroalimentación visual resultante y el diseño del widget siempre son implementados por Qt.

Actualmente estoy usando pyqt en el trabajo y me encuentro totalmente satisfecho. Tiene mejor documentación (IMHO), mejor gestión de eventos (el patrón de ranura de señal es de alguna manera más poderoso que el antiguo estilo de callback 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 las cadenas de progtwigs en diferentes idiomas (es mejor el 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 hobbísticos, pero todavía soy un novato allí. Creo que su mayor ventaja sobre pyqt es que tiene una apariencia nativa en diferentes plataformas. Este es un punto enorme si está desarrollando aplicaciones de Windows / Linux, por ejemplo. En realidad, podría usar “máscaras” para obtener un aspecto y comportamiento nativos con las aplicaciones de Windows-qt, pero no tengo idea de cómo lograrlo (lo siento, nunca he usado qt en Windows: D).

Tenga en cuenta que, a partir de enero de 2009, mientras que Qt 4.5 estaba disponible bajo licencia LGPL, Riverbank Computing no había hecho ningún anuncio sobre licencias para futuras versiones de PyQt . PyQt sigue siendo solo comercial / GPLv2 / GPLv3 .

Como se señaló en los comentarios para esta respuesta, Nokia anunció el proyecto PySide con licencia LGPL en agosto de 2009.

Honestamente, no creo que la gente cambie masivamente de WxWidgets.

Para python, hay enlaces PyQt y enlaces WxPython. A pesar de que Qt es mucho más práctico que WxWidgets, la mayoría de los progtwigs de fuente abierta de GUI python están escritos con WxWidgets. Dado que esos progtwigs son de código abierto, la GPL vs LGPL no importó mucho en su elección del kit de herramientas.

Lo mismo ocurre con Gtk. Muchas aplicaciones de código abierto están escritas en Gtk, en Windows, a pesar de que es muy difícil trabajar con Gtk en Windows. Con Qt, esas aplicaciones serían mucho más fáciles de mantener en una plataforma multiplataforma, pero no ha sucedido.

Por lo tanto, la elección del kit 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 kit de herramientas GUI más fácil y práctico que se haya escrito.

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 en su lugar. Pero los proyectos que ya están usando wxWidgets sin duda continuarán usando wxWidgets en lugar de hacer una reescritura masiva.

Elegí wxPython por 2 razones principales:

  1. Boa Constructor, que aún 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 “comstackr UICs”, sin cambiar de editor, sin entrar en la línea de comandos. Mientras que para aplicaciones a gran escala importa poco, mi dominio actual es rápido y progtwigs a pequeña escala.

  1. Licenciar … no importa ahora, pero una vez que comience a vender mis cosas en pequeña escala.

  2. la autocompletación dentro del código funcional del evento no parece funcionar en QTDesigner, para el código del evento. Puede que me esté faltando algo, pero el proceso “roto” descrito anteriormente evita que sea una RAD.

Nunca pude configurar Qt para comstackción cruzada. Recuerdo haber visto algo de Trolltech diciendo que no admiten oficialmente la comstackción cruzada, aunque ahora no puedo encontrarlo.

Hay muchas guías y detalles sobre cómo hacer que Qt se compile de forma cruzada, por lo que es posible (probable) que estuviera haciendo algo mal.

Al elegir un marco, recomiendo considerar y probar sus habilidades de comstackción cruzada.