CAAD

Quitar las descripciones de una localidad en el ide, y llevarlas al código tiene consecuencias bastante desastrosas. Todas las respuestas que se generan automáticamente desaparecen, hay que tener cuidado con los posibles ends(), hay que vigilar que los argumentos no existan, etc.

Veo lógico que todo eso sea así, pero lo que sí que pido (no recuerdo si está en "issues", es que la ventana de la descripciones en el IDE se pueda ampliar.
Cuando una localidad tiene una descripción dinámica, que cambia constantemente, y que está aderezada de múltiples "ifs" que comprueban lo que se ha de imprimir en pantalla; tener un campo tan diminuto es un quebradero de cabeza total.
No ves la descripción entera, no ves el código de los ifs, se cuelan erratas a montón, cuando no fallos en el código.

Tengo una localidad en la que las descripciones dependen de un total de 7 ifs, más algunos agentes externos a la localidad, que también se podrían haber comprobado desde la misma pero que los puse en otros códigos por no añadir nada más ahí. Cada if tiene que comprobar hasta 5 propiedades, y todo eso lo tengo que escribir y leer en un campo en el que solo se ve una línea y un total de 28 caracteres.
Al final saqué todo eso de ahí, y lo implementé directamente en el código. Consecuencias indeseables, más de una pero es que del otro modo cada vez que metía el cursor en el campo, arreglaba una cosa y estropeaba otra.

Una aventura funciona principalmente a base de descripciones, creo que le tienes que dar la importancia que se merecen. Es solo poner un botón con un cuadrito dibujado y que al pulsarlo, se abra una ventana de mayor tamaño.

Mucha de la información que se introduce en el IDE, debería permitir abrir esa ventana alternativa, del mismo modo que lo hace la de código. Ahora mismo tengo una entidad abstracta que tiene la friolera de 68 propiedades ¿Te puedes imaginar lo que significa visualizarlas en un cuadradito en el que solo caben 19 líneas? Y lo peor es que ni siquiera puedo ordenarlas.

Creo que al IDE le queda mucho de mejorar, ten en cuenta que es lo primero que ve el usuario, y con esa primera impresión se puede quedar si no le convence.

_________________
Si la mentira tuviera color, todos seríamos daltónicos...

Por supuesto, quien dice "ventanas", dice y prefiere "pestañas".

_________________
Si la mentira tuviera color, todos seríamos daltónicos...

Al IDE siempre le quedará mucho que mejorar simplemente porque no cuento en el proyecto con nadie que sepa de diseño y programación de interfaces gráficas. Tengo que guisarlo todo yo solo, y en desarrollo de software hay cosas que sé hacer, y cosas de las que no tengo ni idea y me apaño como puedo para intentar conseguir, trabajosamente, algo mínimamente digno. Las interfaces gráficas, igual que la multimedia, están en el segundo grupo. Puedo hacerlas, pero despacio y mal... para entendernos, como alguien que habla un idioma que no conoce a base de buscar palabras en un diccionario (porque eso hago, ir buscando cosas por ahí en la documentación, sin tener mucha idea de cómo interactúan entre sí, y hacer mucha prueba y error). Así que sí, soy consciente de que son cosas importantes y tal, pero de donde no hay no se puede sacar y yo voy al ritmo que puedo.

La verdad es que cuando medio CAAD andaba insistiéndome en que liberara el AGE porque así otra gente podría colaborar y modificar el código y añadirle cosas y blablablá, pensaba que alguien realmente haría algo. Fui bastante iluso, pero la verdad es que no entiendo por qué la gente pide enérgicamente que los fuentes sean libres si no los van a usar (bueno, al menos parece que ahora están sirviendo de inspiración a los autores de pyphiverses así que por lo menos la liberación ha valido para algo).

A ver si me apunto lo de sacar una ventana para las descripciones como la del código; aunque aviso que puedo tardar en hacerlo. Lo de la pestaña, no veo cómo se podría hacer porque ahora mismo una pestaña ya es lo que tienen y no llega el sitio. A no ser que fuese poniendo una pestaña distinta por cada tipo de descripción (normales, de componentes, etc.) pero esto me parece más lioso que otra cosa, ¿no?

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

No me corre prisa, como bien sabes la aventura está prácticamente terminada y en fase de "preview". Pero creo que sería interesante de cara a futuros proyectos y sobre todo a futuros usuarios.

Cuando digo pestaña me refería a algo que ocupara por completo el IDE, o a una mala, que ocupara entero ese lado del IDE. Pero si es complejo, el sistema de ventanas es más que suficiente.

Si, que es una pena que nadie se haya animado a cooperar en la mejora del proyecto, sobre todo en aquello que tú te vez incapaz de llevar a cabo. A ver si al leer esto, alguien se anima y nos crea un IDE chulo para AGE.

_________________
Si la mentira tuviera color, todos seríamos daltónicos...

Otra cosa que también ayudaría mucho sería aprovechar el espacio que ahora hay en la sección de pestañas. A pesar de haberlo ampliado, los campos siguen siendo del mismo tamaño que antes.

_________________
Si la mentira tuviera color, todos seríamos daltónicos...

Volvemos al tema de mis limitaciones... el problema de esto es tan simple como que no sé mucho de hacer "layouts" dinámicos donde las cosas se redimensionen automáticamente al cambiar el tamaño de la ventana. Sé un poco, suficiente para interfaces sencillos (por ejemplo en una ventana SDI de AGE, si amplías la ventana se amplía el área de texto, cogiendo todo el espacio disponible... eso es fácil de hacer, una vez que uno mira cómo). Pero en interfaces más complejos como estas pestañas del PUCK, que tienen pestañas con subpaneles que contienen otros subpaneles y donde habría que hacer algo para controlar cuánto espacio le das a cada cosa (por ejemplo si amplías cada una de las áreas para descripciones se debería ampliar, sin embargo los campos de texto no, etc.) la cosa ya supera muy ampliamente mis escasos conocimientos. Hacía algún tiempo lo había intentado; estuve bastante tiempo peleándome con el tema pero no conseguí hacer que el comportamiento fuera decente así que al final me limité a poner un "layout" estático en esa parte de PUCK, que no escala con la ventana. Y para que este "layout" se pueda ver bien en monitores de baja resolución, pues lo puse de un tamaño bastante pequeño.

Igual un día me vuelvo a pelear con esto a ver si esta vez consigo averiguar cómo hacer el layout adecuado, pero no prometo nada. Tal vez lo que sí podría hacer como término medio es que el layout siga siendo estático pero que puedas elegir varios tamaños en función de la resolución de tu pantalla (por ejemplo con un parámetro en el fichero de configuración)... no sería la situación ideal pero al menos permitiría aprovechar mejor el espacio aunque fuese a base de configurar a mano.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Aunque es un poco offtopic con el hilo...


Entiendo que normalmente no es tanto que los vayan a usar, sino que cabe la posibilidad de usarlos. En un proyecto como AGE, bucear en el código requiere familiarizarse con la arquitectura y el funcionamiento interno. A falta de documentación para el desarrollador solo queda ver los comentarios en el código (muy aceptables para la media) e ir haciendose una composición mental de lugar. Afortunadamente la documentación para el autor da muchas pistas y todas las conversaciones que se han ido manteniendo a lo largo del tiempo de desarrollo de la obra de jenesis son una muy valiosa referencia.



Y no podré llegar a agradecertelo lo suficiente... Algún documento sobre pyphiverses tratará sobre AGE... y puede que cierta información que está desperdigada tome forma de alguna manera... aunque no puedo comprometerme sobre plazos.

Volviendo al tema...

PUCK apenas lo he ejecutado un par de veces, y su código no lo he visto aún, pero lo tengo en cola para un momento de procrastinación. En mi caso la rampa se inclina debido a java/swing y también es un poco como dices, con el "diccionario" al lado.

Yo en su día ya te hice sugerencias sobre qué librerías/herramientas usaría para hacer un IDE como PUCK. Herramientas que yo he usado en proyectos mios con éxito.

Pero, como te gusta decir a tí, no sé ni para que me molesté ya que fueron ignoradas. Así que ahora no entiendo porqué te quejas si nadie te echa una mano cuando, en su día, a mi me dió la impresión de que querías comértelo y guisártelo todo tú mismo.

El desarrollo de IDEs e interfaces de usuario no es tan fácil como parece. Eso yo lo sé muy bien que llevo casi media vida pegándome con el tema, en distintos lenguajes, entornos y tecnologías. Los problemas que presenta PUCK ahora son problemas conocidos y que tienen soluciones, también conocidas.

En otra época y condiciones me habría ofrecido gustoso para estos temas. Pero ahora mismo entre mi falta de ganas para estos temas, y el mencionado rechazo que hubo en su día, pues me temo que tendrás que guisártelo y comértelo tú.

_________________

"Tengo tres perros peligrosos: la ingratitud, la soberbia y la envidia. Cuando muerden dejan una herida profunda. (Martín Lutero)"

Efectivamente, y solo el paso del tiempo ha ido haciendo que ciertas prácticas que no contemplan distintos dispositivos de salida o la accesibilidad (medidas absolutas,p.ej) han ido perdiendo peso (cuanto mal hizo VisualBasic!) para pasar a utilizarse modelos más flexibles (que si no estoy mal informado swing permite).

En el desarrollo web ha habido una evolución similar.. y como bien dices, son problemas con soluciones conocidas a estas alturas. Lo que no implica que todo el mundo las conozca, menos aún si no es su campo habitual.

Bah, la verdad es que el comentario de "no sé para qué la gente pide que se liberen las cosas si no va a colaborar" fue un poco hecho con las tripas más que con la cabeza. Yo me había hecho la ilusión de que al liberarlo alguien colaboraría, y no sucedió y eso frustra. Pero desde luego es culpa mía por hacerme esas expectativas poco realistas, y no culpa de la gente que pidió la liberación. No está mal pedir que un proyecto se libere aunque uno no vaya a hacer nada con el código, porque aunque no lo vaya a hacer uno siempre lo puede hacer otro en el futuro. Así que pido disculpas a cualquiera que en su momento pidiera la liberación, lea eso y se sienta aludido. Estas cosas de las interfaces gráficas me desmotivan mucho, a veces me ponen un poco de mal humor y me hacen decir alguna cosa que no debería decir.

Sobre lo de las sugerencias que me habías hecho en su día, bueno, ya reconocí en su momento que habría estado mejor seguirlas. Aunque creo que para lo que se discute en este post particular, daría igual, porque la librería que tú decías era para dibujar los grafos y aquí estamos hablando de un formulario, y de que al ampliar la ventana donde está el formulario, algunas áreas de texto cambien su tamaño dinámicamente.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Sí, Swing permite perfectamente usar esos modelos flexibles. Tiene un sistema de "layouts" dinámicos. Lo que pasa es que estos layouts van desde lo más simple (GridLayout, BorderLayout) hasta lo más complejo (GridBagLayout, y otros cuyo nombre ni conozco). Yo sé más o menos usar los simples; pero no los complejos. Y además me falta mucho conocimiento general (de cómo unas cosas interactúan con otras, de formas de combinar unos componentes con otros, estándares de facto, accesibilidad, etc.) porque nunca me he leído ningún libro ni he estudiado ningún curso sobre la materia, el poco conocimiento que tengo del tema es de hurgar en la API y los tutoriales de Java y probar cosas hasta que van funcionando. A lo mejor si me pillara un libro gordote sobre interfaces e invirtiera tiempo en leerlo podría subsanar un poco eso; pero teniendo en cuenta que ni tengo apenas tiempo, ni me motiva nada el tema (yo me puse a hacer AGE porque me gusta programar la componente textual de los juegos, el modelo de mundo, el parsing, etc... pero los interfaces los hago porque no hay más remedio, no porque me guste eso), pues... así estamos

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Bueno, como he dicho hace dos posts, no os toméis en serio el comentario que hice sobre "para qué pedir que se libere si no se va a colaborar", no fue un comentario muy razonable.

Si alguien quiere colaborar en algún aspecto de AGE, sólo tiene que preguntarme y yo le explicaré lo que haga falta del código. Hurgar en el núcleo efectivamente requiere bucear mucho, y bucear por código desagradable (como has visto). Pero en realidad, por ejemplo, para hacer cosas como un cliente (interfaz gráfico para jugar la aventura) no hace falta hurgar casi nada, simplemente se trataría de programar una clase que implemente los métodos que se supone que tiene que implementar un cliente, y ya está. Hay muchas colaboraciones que se pueden hacer sin hurgar tanto si alguna vez alguien se apunta a ello, y si no, pues qué le vamos a hacer.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Doy fé de que Al-Khwarizmi es muy amable y receptivo a las preguntas que se le plantean al respecto :-)


Buena puntualización. El nivel de buceo que mencionaba era para las tripas de AGE, no para un cliente, que solo es implementar la clase necesaria.

Para el caso de PUCK supongo que con conocer la estructura del XML y poco más se pueden hacer mejoras. Para ciertas cosas ni eso, porque simplemente es trabajar sobre lo existente.

Si quieres diseñar elementos de interface, sin tener que leer gordos libros sobre el tema, prueba esto: NetBeans GUI Builder, el diseñador de formularios de Netbeans.

Puedes experimentar con layouts, de forma visual, y luego copiar y pegar el código generado y adaptarlo a tus necesidades.

Otro bastante bueno es el JFormDesigner, pero es de pago.

_________________

"Tengo tres perros peligrosos: la ingratitud, la soberbia y la envidia. Cuando muerden dejan una herida profunda. (Martín Lutero)"

El JFormDesigner es una maravilla. Lo usé para mi proyecto de fin de semestre pasado. Eclipse + JFormDesigner hacen una excelente combinación, aunque se puede usar en NetBeans también, o de manera standalone. A mi juicio, es muchísimo mejor que el Matisse de NetBeans (el GUI Builder). Y de hecho, el JFormDesigner usando el layout de Matisse te da incluso más control que el propio Matisse, lo cual no deja de ser divertido.

Saludos!

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/