[pyar] Consejos sobre cual GUI utilizar en Windows

[Roberto Alsina]

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

Es que eso no es avanzado, eso es básico.

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

Ah, ok, yo hablé de una cosa parecida en una lightning en la PyCon pasada.


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

Me refiero a "para dos browsers" en el sentido de que el HTML/JS que uses
tiene que testearse en IE y Webkit.

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

No estoy hablando de efectos re-copados. Estoy hablando de atención al 
detalle. Ejemplo, alinear los widgets correctamente,
verificar aceleradores para ver si tienen colisiones en cada traducción, 
hacer un layout agradable a la vista, tener un loop
rápido con alguien a cargo de la UX. No de "efectos re-copados".

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

Pero tus formularios en Wx respetan el layout correcto de la plataforma? 
No. Entonces por favor podés
decir "che, está bueno"? ;-)

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

Ok, no entiendo bien qué son, no puedo opinar.

> Igual me refería más a código dinámico que crea controles desde el programa.

Obviamente, controles generados desde código no los ves en designer.
Sin embargo, en mi opinión, excepto para cosas que realmente sean 
dinámicas, tipo, estás haciendo un programa
que manipula estructuras de datos que el usuario mismo define, algo como 
el admin de Django, si me lo permitís,
ese método de hacer las cosas lleva a una peor UI que usar una 
herramienta de diseño de UI.


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

A veces quisiera que Designer me dejara decirle "mirá esta clase" y 
hiciera todo el laburo de integrar el widget
  automáticamente. Si estuviera en python tal vez podría.
>> 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.

Y esa es la diferencia fundamental entre Wx y Qt, la prioridad que se le 
da a ser uniforme
entre plataformas o no, lo que a su vez lleva a la diferencia de base en 
usar widgets
"nativos" o no,

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

Como ya hablamos por otro lado, no tengo ganas de pelearme en un panel.
Sí, seguro, no personalicemos, etc. Yo me conozco, soy leche hervida, y me
la pasaría interrumpiendo a los otros cada vez que dieran algo que me parece
no es cierto o exacto, entonces mejor corto por lo sano y no me meto.

O sea, creo que la idea de los paneles o charlas "X sucks" son que la 
gente que *
le gusta* y *usa* X diga que es lo malo que tiene. Entonces si vos 
hicieras un
panel "web2py y Wx suck" sería interesante. Y si en una de esas yo hablara
de porqué "Qt sucks" en una de esas, pero no sé si soy la persona adecuada
para eso. Entonces no lo hago.

Por ejemplo, lo del pancho y el bife de chorizo no era una crítica a Wx, 
sino a wxGalde/wxFormBuilder
y el tema de "libertad de elección" como feature.  Releyéndolo entiendo 
que se ve así, entonces ahora
me voy a tomar un ratito, disculparme,  y ver si lo puedo decir de mejor 
manera. En un panel no podría.

Así que primero: disculpas, wx es un muy buen toolkit, aunque no sea mi 
favorito, y no quiero
implicar que no está bueno. Hasta he recomendado wx en el pasado cuando 
me pareció
que era la herramienta adecuada (por ejemplo, por temas de licencia).

Explicación de lo del pancho, el paty y el bife de chorizo.

En general, si la persona A está hablando de que lo mejor es usar el 
producto X, y la persona
B le responde "pero podés usar Y y Z!", hay un problema básico cuando no 
se puede usar
Y y Z *al mismo tiempo*, porque desvirtúa la posibilidad de comparación 
para los que
puedan estar leyendo y tratando de llegar a una conclusión.

Si un feature está en WxGlade y Designer pero no en WxFormBuilder, 
entonces de qué me sirve si mi proyecto
usa WxFormBuilder? (a menos que se pueda pasar de uno a otro sin 
problemas. Se puede?)

Preferiría tener una herramienta con todos los features, por favor. No 
la libertad de elegir entre dos herramientas.
Quiero carne, a la parrilla, que me guste. No elegir entre carne a la 
parrilla o "carne" que me guste.

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

Que, estuve demasiado agreta? En serio que no me molesta nada que hablen 
de Wx, eh?
Creo que en este aclaré lo que me interesaba aclarar así que me tomo 
unas vacaciones del
thread :-)