[Python-es] Orientación para el desarrollo de aplicaciones GUI.

Jue Ene 14 15:14:16 EST 2016

De verdad muchas, pero muchas gracias a todos por la paciencia que han
mostrado, aún no me rindo, he invertido mucho tiempo estudiando, incluso en
cosas que no debía pero fue por falta de orientación, ahora ya casi tengo
todo listo, me dedicare a estudiar en profundidad las herramientas que debo
usar y de seguro que más adelante volveré a colaborar a personas como Yo que
no tuvimos un inicio apropiado, bueno y porque no solicitando su valiosa
ayuda.

Un abrazo para todos, Jesús

De: Python-es [mailto:python-es-bounces+jesusquin=msn.com en python.org] En
nombre de Leonel Gomez
Enviado el: jueves, 14 de enero de 2016 12:38 p. m.
Para: La lista de python en castellano <python-es en python.org>
Asunto: Re: [Python-es] Orientación para el desarrollo de aplicaciones GUI.

Hola amigos, se que este es un foro de Python al cual estoy inscrito y
recibo cada mensaje porque aun me llama la atención para algunos propósitos.

Específicamente para el amigo que viene de VFP le informo que  yo pase por
el mismo dilema, le di tantas vueltas a Python para poder pasar mis
aplicaciones de VFP a Python

en mi opinión muy personal le comento lo siguiente al amigo.

Venir de VFP donde uno tiene todas las utilidades en un mismo ambiente(id),
100% probado por miles de usuarios a nivel mundial, generar aplicaciones en
un dos por tres en VFP ha sido una 

maravilla de todos los tiempos, ver una tabla de datos en VFP basta con un
simple BROWSE y ya ves la info sin necesidad de tanta cosa,muchos lo
critican por sus tablas nativas, pero sus tablas nativas son el comienzo
nada mas, ya que para una aplicación gigante lo conectas a SQL Server,
MYSQL, etc etc.. Python comparado con VFP para Escritorio, deja mucho que
desear

debido a que todo habrá que instalarlo por separado, librerías, id, y casi
todo habrá que hacerlo a mano, el lenguaje es muy simple, pero para hacer
aplicaciones rápidamente, VFP lo deja a 

kilómetros de distancia ya que desde su nacimiento fue pensado en Bases de
Datos relacionales, tanto nativas como SQL.

Lamentablemente necesitamos migrar por el abandono de MS hacia VFP, en mi
caso te comento que probé los siguientes lenguajes: Python, C#, Lazarus,
Java y Dbase.

De todos estos, tuve que tomar una decisión, debido a que no puedo estar
probando de todo un poco sin aterrizar en algo para desarrollo mas serio, y
Opte por JAVA Swing.

Un lenguaje criticado por todo mundo por la dificultad de aprendizaje, y
algunos por su lentitud. 

Que fue lo que encontré en este lenguaje:

1) No varia mucho de VFP: recuerdas esto (this.form.text1.vaule= “Nombre”)
en Java (String loNombre = this.jText.getText();)

claro que hay cosas complicadas com por ejemplo llenara un Grid en Java, es
un delirio pero después de tanto estudiar, le tomas hilo y casi lo mismo es
en Python.

Java tiene su propio ID nativo exclusivo elaborado por Sun Oracle, 

Extrañas la ventana de comandos de datos en VFP, pues en Java tiene su
propia ventana de comandos SQL para cualquier base de datos grande.

hice mi primer crud en Java y a la primera fue multiplataforma, sin
necesidad de tanta instalación.

Al principio cuesta entenderlo, pero créeme, cuando le agarras el hilo, es
impresionante y todo lo tienes en el mismo id, no hay que instalar nada por
separado, 

los componentes de ventana, sin son de Arrastrar y soltar, dando la ventaja
de pensar solo en la programación orientada a objetos y por eventos.

Lentitiud, solo es al principio, igual que Windows, al principio cuesta que
arranque, una vez en memoria, corre rápidamente.

y el fuerte de Java es WEB, así que una vez agarras el hilo, no te costar
tanto aprender para WEB.

Actualmente estoy desarrollando un proyectito en Java sin prisa, con
conexión a MySql en la nube y todo tranquilo.

Como consejo sigue con VFP dandole mantenimiento a tus aplicaciones, que VFP
hay todavía para rato, mientras has tus propias pruebas despacio y sin
prisa.

Saludos.

LG

El Jan 14, 2016, a las 10:46, Jesús Quintero Suárez <jesusquin en msn.com
<mailto:jesusquin en msn.com> > escribió:

Hola Mario, en una respuesta anterior me recomendaste wxPython y
wxFormBuilder, encontré que para MS Windows wxPython no está disponible para
la versión 3.x de Python, me imagino que wxFormBuilder es por el estilo.

De: Python-es [ <mailto:python-es-bounces+jesusquin=msn.com en python.org>
mailto:python-es-bounces+jesusquin=msn.com en python.org] En nombre de Mario
Lacunza
Enviado el: jueves, 14 de enero de 2016 10:25 a. m.
Para: La lista de python en castellano < <mailto:python-es en python.org>
python-es en python.org>
Asunto: Re: [Python-es] Orientación para el desarrollo de aplicaciones GUI.

Uhmmm me parece q demasiado x encima los has visto.

Yo uso wxformbuilder (sin problemas en Windows) en Ubuntu Linux, al igual q
el diseñador de guis de visual studio agregas controles y los pones donde
quieres, te crea el código Python para manejarlo luego heredas en tus clases
de lógica y controlas todo.

No veo q tanto problema te estas haciendo cuando es de lo más fácil, qt
tiene una lógica similar.

Enviado desde mi LG G3

El 14/01/2016 09:53, "Jesús Quintero Suárez" < <mailto:jesusquin en msn.com>
jesusquin en msn.com> escribió:

Hola todos, he visto por encimita varios diseñadores gráficos que facilitan
crear las GUIs para Python, lo que ofrecen es un subproducto que Python
puede consumir, el diseñador en sí, que es la parte compleja, no intervendrá
en la aplicación.

¿Qué es el subproducto?, pues bien, no es más que código Python haciendo uso
de utilidades pre-construidas por un tercero, el cual nosotros podemos
recrear en Python sin la ayuda de ningún diseñador, solo requerimos de las
utilidades, hacerlo de esta manera es fácil pero dispendioso, prácticamente
toca cambiar y probar para poder visualizar como está quedando nuestro
diseño.

De los diseñadores que visto por encimita, algunos tienen problemas de
compatibilidad con MS Windows, no son tan amigables con el usuario, no es
solo arrastrar y soltar, el subproducto solo se limita a la parte del
diseño, no hay forma de agregar código que controle la lógica del diseño, es
decir, requiere de bastante código adicional para dejarlo totalmente
funcional.

Viéndolo de este modo, podemos utilizar el mejor diseñados que tengamos
disposición  y del cual podamos extraer la información del diseño y código
adicionado, (probablemente trampeando al diseñador con string para incluir
nuestro código python de control), y generar código Python que hará uso de
esas utilidades y totalmente funcinal.

_______________________________________________
Python-es mailing list
 <mailto:Python-es en python.org> Python-es en python.org
 <https://mail.python.org/mailman/listinfo/python-es>
https://mail.python.org/mailman/listinfo/python-es
FAQ:  <http://python-es-faq.wikidot.com/> http://python-es-faq.wikidot.com/

_______________________________________________
Python-es mailing list
 <mailto:Python-es en python.org> Python-es en python.org
 <https://mail.python.org/mailman/listinfo/python-es>
https://mail.python.org/mailman/listinfo/python-es
FAQ:  <http://python-es-faq.wikidot.com/> http://python-es-faq.wikidot.com/

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20160114/b242adf2/attachment.html>