[pyar] Consejos sobre cual GUI utilizar en Windows

[Roberto Alsina]

On 9/17/2011 10:18 PM, Mariano Reingart wrote:
> 2011/9/17 Roberto Alsina<ralsina en netmanagers.com.ar>:
>> On 9/17/2011 6:42 PM, Mariano Reingart wrote:
>>> Puede ser, pero ahora con FormBuilder es mas ameno ese tema.
>> Como vengo escuchando esto ultimamente, me pasé un par de horas con
>> FormBuilder.
>> O no lo entendí, o no, no es ameno.
> Dije mas ameno (respecto a wxGlade)
> Y si, qtdesigner parece un poco mas automagico, igual prefiero saber
> que estoy haciendo al estilo wx :-)

Designer no es muy automágico, por lo menos no en el sentido de "magia" 
que veo habitualmente :-)
Designer se puede usar de muchas maneras. Por ejemplo, he visto gente 
decir "designer
es malísimo" y no habían ni encontrado como poner un layout. No, lo 
malísimo es como se lo
estaba usando.

>>> Igualmente yo no eligiría una herramienta solo por su parte "Visual",
>>> por experiencia, el diseñador de formularios pasa a ser algo
>>> secundario, no es obligatorio (al menos con wx) y en ciertos casos hay
>>> otras formas más rápidas y mantenibles de diseñar las pantallas.
>> Con ningún toolkit es obligatorio. Y sí, si estás haciendo un ABM, en una de
>> esas no es la manera, sino que querés pantallas mediocres genéricas, que es
>> lo que en mi experiencia producen todas las herramientas de generación
>> automática de CRUD, y lo que produce el 99% de los desarrolladores en
>> general.
> Estoy adentro del 99% de los mediocres y de hecho me encanta que las
> pantallas se generen automagicamente, me pagan por hora y en general
> esos detalles mucho no le importan a mis clientes, sobre todo para
> sistemas de gestión centrados en datos, que cero era lo que se
> discutía.

Hay aplicaciones y aplicaciones. Y sí, en muchísimos casos una UI "así 
nomás" zafa.
Y hay casos en los que no. Depende del mercado al que apuntás.

> Lo que no quita que wx traiga cosas como la interfaz de usuario
> avanzada (AUI), una ribbon, cairo, etc. que se pueden usar
> tranquilamente y son bastante configurables el look&feel, lo que
> ahorra bastantes recursos para hacer aplicaciones genéricas y no
> tanto.

Decir que paneles dockeables, toolbars con drag y widgets MVC son AUI es
parte del problema, no de la solución.
>
>> Ahora, cuando empezás a querer tener una pantalla bien hecha, con diseño (y
>> con eso quiero decir: con un diseñador humano atrás), ahí designer o alguna
>> otra herramienta similar es buenísima, si no indispensable.
> En ese extremo prefiero pasarselo a un diseñador gráfico y que lo haga
> en HTML/CSS, creo que se debe usar la herramienta adecuada para cada
> cosa IMHO.

Estoy hablando de hacer una UI con diseño en una app desktop. Vos me 
estás diciendo que eso no
tiene sentido y hay que hacerlas web? Entonces para qué recomendás Wx? 
Solo para ABMs?

> Y he visto browser embebidos en wx que aprovechan lo mejor de ambos mundos.

Claro que si usás el browser embebido en Wx y querés usarlo en dos 
plataformas tenés que codear para dos browsers.

>> Por otro lado, la gran mayoría de las UI no tienen, ni se les pone el nivel
>> de atención al detalle como para que te haga diferencia no digamos la
>> herramienta gráfica, no te hace diferencia
>> el toolkit mismo.
> Justamente por eso dije que no importa tanto la parte "visual", sino
> que sea lo mas simple y flexible para programar y mantener.

Son prioridades distintas. La experiencia del usuario, para algunos, es 
más importante que ahorrar tiempo
de código. Y no son cosas contradictorias, en general. Diría que tienen 
una correlación, pero no son
opuestas.

>> Por ejemplo, layout de formulario típico, filas "etiqueta / campo". Cuál es
>> el alineamiento correcto de los campos? Depende de la plataforma. En Qt, los
>> pones en un "FormLayout" y te va a usar automáticamente el layout correcto
>> para la plataforma y estilo en que corre el programa. El 99% de los
>> programadores les importa un rabanito y/o ni se enteraron de como hay que
>> hacerlo.
> wx.StdDialogButtonSizer, no es lo mismo pero bueno.

No, nada que ver. Ese es para los botones en diálogos (tipo, Ok/Cancel o 
viceversa). En Qt eso sería un QButtonBox.
Yo estoy hablando de esto:

http://doc.qt.nokia.com/4.7/qformlayout.html  (mirá los screenshots). No 
se me ocurren muchas aplicaciones que
no se beneficiarían de tener una cosa así, especialmente cosas de tipo ABM.

>> Y después hay miles de detalles que no es que te hacen la vida más fácil
>> solamente, si no que hacen que el producto final pueda ser mejor. Tomemos
>> traducciones, por ejemplo.
>> En Wx tenés una herramienta que al traducir te muestra como queda la UI al
>> mismo tiempo que lo estás traduciendo para que puedas elegir traducciones
>> que queden bien de tamaño, que no rompan el flujo de la UI, etc? Bueno, Qt
>> sí. Y sólo funciona si usás designer. Entonces al no usar designer, empeorás
>> las cosas para los traductores.
> Sep, pero si tengo codigo autogenerado, controles virtuales o clases
> redefinidas, me sirve poco un diseñador.

No sé que es un control virtual. Una clase redefinida? Si lo que haces 
es por ejemplo, agarrar un
control standard y cambiarle el comportamiento pero no el aspecto 
visual, entonces lo que
querés en Designer es un "promoted widget". En designer funciona como la 
clase standard,
en el código generado es tu clase.

Si hacés un widget desde cero, y realmente querés usarlo desde designer 
con el mismo nivel de soporte
que cualquier otro widget: 
http://diotavelli.net/PyQtWiki/Using_Python_Custom_Widgets_in_Qt_Designer

>>> Lo que tiene wx es que me parece la mas "pythonica" (espacio de
>>> nombres, simplicidad, extensibilidad, etc.), y de hecho esta empezando
>>> a tener cosas puramente escritas en python, y eso creo es un buen
>>> camino a seguir, ya que te simplifica el desarrollo, podes corregir
>>> bugs facilmente, ver y entender el codigo fuente, etc.
>> Qt por otro lado te ofrece simplicidad, completitud, abstracción de casi
>> todas las partes horribles de la plataforma, un set de herramientas
>> consistentes y "oficiales", o sea que no te pueden decir "ah, no, esa parte
>> en la herramienta pepe no va, usá la herramienta pancho".
> Libertad, libertad, libertad :-)
> Con wx no hay nadie que diga que herramienta es oficial y que no,
> puede ser ventaja o desventaja, depende de como se lo mire.
>
> La verdad que con MS me cure de espanto, y no quiero pasar de
> guatemala a guatepeor (salvando las distancias, obvio)
>

La libertad de elegir entre un pancho y un paty no sirve si querés un 
bife de chorizo.
>> Y sobre todo: cross platform en serio (si hay algo que no es igual y no está
>> en la documentación, es un bug). Eso quiere decir que mientras te mantengas
>> en Qt y las barrios buenos de la stdlib[1], la plataforma no te importa.
> ¿Abstracción de *casi todas* las partes horribles de la plataforma y
> cross platform en serio?
> ¿Si hay diferencias?

> Medio contradictorio, aunque este en la documentación, creo que a la
> larga estamos en la misma.
Sí, hay diferencias, y están en la documentación. Dije "casi todas" 
porque hay partes
que no están abstraídas. Por ejemplo, si querés usar el registry en 
windows, no está abstraído.
Querés usar un keyring? No está abstraído. Queres usar QtDBus? Solo en 
linux.
Querés usar filesystem notifications? Sí (QFileSystemWatcher). Querés usar
IPC? Sí ()
Espero haber aclarado la supuesta contradicción.

Lo que no vas a ver en Qt es cosas como esto: 
http://trac.wxwidgets.org/ticket/4711
en que un click te da un evento u otro dependiendo de la plataforma. (No 
sé si es actual, pero figura como
"confirmed defect" hace 4 años).

> Cosas que no me gustan de wx:
> * La documentacion esta bastante dispersa (parece un karma de los
> toolkits graficos de python en gral)

No, por ejemplo, con PySide. O con PyQt.

http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/index.html

Es completita completita. Lo que sí tiene es defectos: los fragmentos de 
código no están todos traducidos de C++.


> * Eventualmente tira segmentations faults si uno se descuida y no esta
> bien compilado (blame c++)
Extrañamente, Qt está hecho en C++ y nunca oí de alguien que le diera 
segfault por "estar mal compilado".

> Saludos
>
> [1] Hay unas cuantas partes de la stdlib que son villa, favela y/o ghetto.
> ¿No queres discutirlo en el panel de python apesta?

No.