[pyar] Consejos sobre cual GUI utilizar en Windows

[Mariano Reingart]

2011/9/17 Roberto Alsina <ralsina en netmanagers.com.ar>:
> 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.

Seguramente

>> 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.

No te entiendo pero bueno, para mi eso sirve, si a vos no, esta bien.

>>> 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?

Decia que haria eso en los casos extremos.
Mi idea va por este lado:
http://ar.pycon.org/2011/activity/accepted/22

Aunque preferiria no usar un browser y usar el control wx.HTML (si, el
html que soporta es bastante limitado, pero creo que puede facilitar
un poco las cosas y llegado el caso, mejorarlo un poco):
http://code.google.com/p/gui2py/
(tengo un ejemplito que ya anda con web2py, me falta subirlo)

>> 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.

Si, lo puse abajo como lo que no me gusta, igual no tenes que codear
para dos browser, con una clase que te abstraiga ya esta en general,
fijate en:
http://code.google.com/p/rad2py/source/browse/ide2py/browser.py

>>> 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.

Totalmente, pero yo prefiero centrarme en la funcionalidad, y después
veo si tiene efectos re-copados (bah, si me alcanza el tiempo y
presupuesto).

>>> 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.

Por eso puse que no es lo mismo, pero la base esta ;-)  ;-)

>>> 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.

Eso tambien anda hasta en wxGlade, si no me equivoco, se dibuja el
control y se le pone la clase que uno desee.

Controles virtuales son los que se completan en tiempo de ejecución
(como algunas listas y las grillas) que no ves hasta que la app esta
andando.
Igual me refería más a código dinámico que crea controles desde el programa.

> 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

wxGlade esta hecho en python, se puede cambiar todo (no, no es
practico, por lo menos para mi, pero se puede).

>>>> 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.

Mientras coma algo y me dé el presupuesto..., no soy tan pretencioso :)

>>>
>>> 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).

Creo que hay cosas que no se pueden evitar por como funciona cada plataforma.
Si la manera de corregirlo es reinventar la rueda, yo paso,
seguramente es mas fácil hacer un workaround.

>> 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++.

Ah, que piola, de wx tambien hay doc y ejemplos en c++, aunque
sinceramente no se si es tan buena como la de qt (la verdad que me
pierdo con qt).
Lo que si se es que wx trae ejemplos en python para todos los
controles, mas de 200, que son muy útiles, y hay un libro muy bueno.

>> * 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".

asserts y otras yerbas, y si, es bastante rudo que se cierre porque me
olvide alguna referencia o similar, en teoria debería avisar con un
error un poco más amigable.

Hasta donde se se esta planeando una nueva versión para mejorar esto y
otras cuestiones, a.k.a. wx3

>> 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.

Ok, sos el tercero que me contesta asi, empiezo a pensar que soy yo el
problema ... :-)
Quizas debería pedirle a  los organizadores de cancelarlo, me hubiera
gustado debatir pero veo que es medio imposible, qt es el bife de
chorizo y wx es un pacho (o paty, no me quedo claro).
Ni hablar de debatir con gente de django, ni me contestaron.
A esta altura, voy a pedir cambiar el panel a "django y qt rules!" asi
el resto nos podemos ir tranquilos.

Hablando más en serio, creo que no da para mas, voy a ver de reflotar
la lista de wxpython en español que teníamos (si es que todavía no se
creo) así no molestamos mas.

Sds

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com