Imaginar esta situación:

Tenéis un control en un formulario. Sabéis lo que el control hace y conocéis como funciona.
Ahora ampliemos ese formulario a dos controles y así hasta obtener lo que os he mostrado.

Tenéis una caja negra, que es el objeto formulario diseñado al que le tenéis que añadir un código.
En este caso "si" tengo diseñado más formularios por que sé los que necesito. ( Aproximadamente.    ).

Si con esos formularios que son las plantillas de un proyecto y dando por conocido "que no voy a necesitar más formularios".
Se los doy a distintos programadores, cada uno realizara un código puede que distinto, pero en el fondo, han usado los mismos
formularios.

Visualmente saben lo que quiero, pero no conocen aun su código interno.
De la otra manera puedo tener un código distinto y formularios distintos, que hagan lo mismo.

Sigo pensando que es otra forma de ver la creación de un proyecto "visual".  
Si es que incluso hasta para el diseño de un formulario se hace antes un dibujo a lápiz.

Una de tantas historias:

" Un día le llega un cliente a Shordi. Y le dice, oiga yo quiero que la aplicación se muestre de esta manera".
Y Shordi dice..."A ver, a ver, yo haré la aplicación como me guste y que le valga a usted para lo que quiere hacer".

CL - Pos no, yo quiero que salga un aeroplano en la portada.

SH - ¿ Y para que quieres usted un aeroplano ?

CL -  Pues vera es que a mi me gustan los aviones.

SH - ¿ Pero si es para la administración de cuentas de su empresa ?.

CL - Yaaa, pero a mi me gustan los aviones. Y quiero un avión.

¿ Avión si o no ?. El cliente $iempre tiene la razon.  

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

Tenéis una caja negra, que es el objeto formulario diseñado al que le tenéis que añadir un código.
En este caso "si" tengo diseñado más formularios por que sé los que necesito. ( Aproximadamente. ).

Si con esos formularios que son las plantillas de un proyecto y dando por conocido "que no voy a necesitar más formularios".
Se los doy a distintos programadores, cada uno realizara un código puede que distinto, pero en el fondo, han usado los mismos
formularios.

Pregunta:
¿Cuántos programadores de gambas hacen falta para diseñar un formulario?
Respuesta:
Ninguno: Eso es cosa del departamento de diseño.

En otras palabras: Estás mezclando churras con merinas, que se dice en mi pueblo.
El paradigma de la programación visual unifica, hasta cierto punto, el diseño y la programación con el concepto de "Control". Pero eso no es puramente así. Por un lado está el diseño y por otro la lógica del problema a resolver.

Si a un programador le pasas ya el diseño gráfico, es cuestión suya dentro de los parámetros del cuaderno de carga qué controles usar (¿hbox?¿panel?¿hSplit?, etc. etc.) y la codificación dependerá de eso.

El tema es que no se suele funcionar así. Uno no "vende pantallitas" uno "ofrece soluciones" y la solución la das tú. El cliente no se puede negar (si lo que le das es una solución, claro, que a veces el remedio es peor que la enfermedad    ).

Si a pesar de todo pide elefante, pues le das elefante y se lo cobras a precio de marfil, claro.
Si no existen controles con elefantes, pues los inventas. Si no sabes o no eres capaz, pues renuncias al proyecto... y a la pasta.

Saludos.

===================
No podemos regresar

Shordi:

Decir al principio que cuantos programadores de gambas hacen falta para diseñar un formulario...es casi,
como no darle la suficiente importancia que tienen. En este mundo de clic's aquí y allá.

Ojo, que yo no soy de formularios. Yo estaba muy contento con Python con aplicaciones "exclusivamente"
para consolas. Pero, la imagen vende. Y siempre ha sido así. Volveríamos a los 80, incluso más.

Mi caso,  no toco aplicaciones de formularios, tanto, que hasta se me olvida el manejo de controles.
Por eso de vez de en cuando vuelvo y practico un poco, como en este caso, con los organizadores o
contenedores.

Citar:

Por un lado está el diseño y por otro la lógica del problema a resolver.

Si, totalmente de acuerdo. Solo que el problema lo tenía a medio resolver.
Solo que no había creado el formulario que he mostrado con los contenedores.

Mi idea era "calcar" en gambas, lo mismo que estaba haciendo en una hoja de Calc.

Luego como es lógico me tendré que complicar un poco si quiero, con bases de datos. Ya que tampoco
voy a poner mil componentes. Solo contando los que me gustan para crear un pc. Que incluso con archivos
de texto se podría hacer.

Citar:

El tema es que no se suele funcionar así. Uno no "vende pantallitas" uno "ofrece soluciones" y la solución la das tú.
El cliente no se puede negar (si lo que le das es una solución, claro, que a veces el remedio es peor que la enfermedad

Supongo que el cliente opinara sobre la interfaz y te habrá hecho cambiarla mas de una vez. Por "pijerias".  

No podemos negar que la "tontería" manda, desde en las páginas webs, aplicaciones, etc...ah, y no olvidemos
los sistemas operativos. Claro que si a esa tontería le añades utilidad al 50% cada una, puede tener su utilidad.

Nunca he comenzado la aplicación por el formulario. Creo que entre tanto código, no le damos la suficiente
importancia a una buena interfaz. Luego no sabemos diseñarla y eso lleva su tiempo.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

Decir al principio que cuantos programadores de gambas hacen falta para diseñar un formulario...es casi,
como no darle la suficiente importancia que tienen. En este mundo de clic's aquí y allá.

Todo lo contrario, es elevarlo a la categoría de "arte", es decir que hace falta ser Diseñador -o sea, que entiende de armonía de colores, de usabilidad, de ergonomía de movimientos, etc. etc. y, por supuesto, lo suficiente del medio a utilizar como para que el diseño no sea un imposible dada la "herramienta", ya sea programación web, gambas o lo que sea.

¡Cuántos programas de principiantes hemos visto llenos de colorines de fondo, tipos de letras fantásticos y transiciones entre formularios estrambóticas! programas que te cansan, te aburren, te agotan, te despistan cada vez que los abres...

No estoy en contra de la personalización de los programas y las interfaces, pero sí soy ferviente partidario de la integración de nuestro software con el entorno del escritorio. Usa los colores del entorno y tendrás, de entrada un usuario semi-entrenado en el uso de tu aplicación. Cambia el orden natural en que el ojo se pasea por una ventana (izquierda-arriba -> derecha-abajo -> abajo-izquierda->derecha-arriba) y tendrás un usuario despistado sobre dónde mirar. Llena tu pantalla de decoraciones barrocas y tendrás un usuario cansado cuando lleve 4 horas mirando...

No es nada fácil diseñar y todo lo que he explicado antes se puede resumir en "Como yo no sé hacerlo, me voy a lo seguro, probado y que funciona".

El tema me recuerda éste viejo vídeo. Tiene subtítulos en Español, revisar las opciones de Youtube.

Link

===================
No podemos regresar

shordi escribió: [Ver mensaje]

¡Cuántos programas de principiantes hemos visto llenos de colorines de fondo, tipos de letras fantásticos y transiciones entre formularios estrambóticas! programas que te cansan, te aburren, te agotan, te despistan cada vez que los abres...

No estoy en contra de la personalización de los programas y las interfaces, pero sí soy ferviente partidario de la integración de nuestro software con el entorno del escritorio.

Totalmente de acuerdo. Es el típico error de principiante, cuando descubre que puede cambiar todos los colorines y letras... y no se centra en lo importante, que es el código, la funcionalidad y ergonomía de una aplicación.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Cuando hablamos de la creación de una aplicación. Hablamos de que no todo depende de una sola persona,
mas bien de un equipo de personas. Podemos tener un programador y un diseñador.

¿ Tiene que esperar el diseñador a que le diga el programador que ha acabado para comenzar el diseñador a crear la interfaz gráfica ?.
¿ Qué hace mientras el diseñador ?,¿ se rasca la nariz ?.  

¿ No creéis mas bien que en todo ese diagrama de diseño por bloques de la estructura de la aplicación cada uno trabaja por un lado con unas
especificaciones concretas ?. Entradas / Salidas

Suponer por ejemplo el caso también del diseño de una página web que ademas usa código.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Lo que hacen es ponerse de acuerdo con reuniones como las del vídeo.     

===================
No podemos regresar