@Eslopes, yo siempre me he interesado por las GUI, pero sobre todo en Editores GUI en modo WYSIWYG. Tuve un intento de ampliar PowerCOBOL 3 en su momento, pero con código C decompilado de un exe era superior a mis fuerzas.

Hasta donde recuerdo, la idea de un WYSIWYG es:

1. Uso de componentes GUI con subclassing para que actúen en modo Diseño como bloques gráficos en pantalla (sin funcionalidades)
2. Un "algo" que al poner un componente en tu Form o modificar alguna de sus opciones, te genera código en un lenguaje de programación y lo inserta donde debe, para cuando se compile tu proyecto, el componente GUI se crée po el código generado de manera transparente para el programador

Básicamente creo que es lo que pasa en PowerCOBOL y otros. Esto se veía bien también en Delphi y C++ Builder (al menos antes, llevo más de 10 años sin tocarlo).


Estuve dándole vueltas a la siguiente idea: puesto hoy existen muchas librerías GUI con sus APIs, por código no hay problema salvo la complejidad del mismo. Pero qué pasa con el dichoso WYSIWYG? Yo quería encontrar un Framework GUI con su editor GUI en modo WYSIWYG que permitiese asignar código e indicar el compilador... Es decir, que se pudiese "configurar" el editor GUI diciéndole qué código tiene que generar.
Si hubiera algo así, se necesitaría bastante tiempo, pero se podría crear/traducir código (por ejemplo) C en Cobol y obtener algo similar a PowerCOBOL pero con GnuCOBOL y GUI multiplataforma.

Pero no encontré nada que permitiese reemplazar/parametrizar código generado para componentes GUI.

Hola,

La idea inicial era usar la integración con TCL/TK. TK (ToolKit) es una biblioteca/framework que permite crear interfaces gráficas. Un poco verboso, es cierto, pero bastante fácil de usar. El guiCOBOL parecía una opción para GUI, pero el propio creador, con quien hablé por correo electrónico ayer, me desaconsejó su uso. Abandonó el código hace mucho tiempo. Me sugirió otro proyecto que genera interfaces web (Makeform). Aún no he tenido tiempo de revisarlo, pero las opciones están volviéndose cada vez más limitadas. Todavía no he desistido del gnuCOBOL, pero me preocupa que esta parte de la interfaz gráfica termine consumiendo buena parte del tiempo que planeaba dedicar a este proyecto.

Saludos

Hola,

después de una cuidadosa investigación y, para mi gran decepción, decidí usar FastCGI con gnuCOBOL. La sensación es como volver a 1996 (CGI), pero ¿qué se le va a hacer? Todas las demás integraciones con GUI son experimentales, sin una posibilidad real de ser utilizadas en un entorno productivo. Bueno, es lo que tenemos por ahora.

Saludos

@Eslopes, tú lo que quieres es que sea GUI con la sintaxis OO obligatoriamente?

Conozco un poco Python y creo recordar que también tiene biblioteca GUI, descartas esta opción?

De lo que todos hablan bien es de Qt, pero nunca llegué a verlo la verdad.

Hola,

FastCGI es suficiente para lo que necesitamos.

Saludos

Hurgando un poco me he encontrado esto: https://nappgui.com/en/home/web/home.html

Más info: https://nappgui.com/res/nappgui_es.pdf

Tiene pinta interesante :piensa:

Hola,

Después de verificar varias alternativas, realmente me quedaré con FastCGI. No es lo ideal, pero al menos permitirá una interfaz decente con Javascript (JQuery y otros componentes web).

Sobre el proyecto, en este momento estoy produciendo los elementos gráficos. No son muchos, pero le darán un aspecto más interesante a la aplicación, que básicamente es un chatbot. También estoy evaluando el uso de componentes que soporten Markdown para la generación de tablas, gráficos y otros elementos a partir del texto. Sugiero que echen un vistazo al siguiente sitio para entender cómo funciona Markdown (es fácil y rápido de aprender).

https://mermaid.js.org/syntax/flowchart.html

Un componente esencial del proyecto es el LLM (Modelo de Lenguaje Grande). Un LLM es un modelo de Inteligencia Artificial preentrenado que comprenderá las preguntas del usuario, las transformará en SQL y hará consultas a la base de datos (SQLITE). Voy a probar algunos modelos (LLama3 de Facebook, Gemma2 de Google o PHI3 de Microsoft) para evaluar cuál de ellos da el mejor resultado. El primer paso es instalar el modelo en tu máquina (usaremos OLLama):

https://towardsdatascience.com/runni...k-f735631272ad

Para aquellos que quieran comenzar a estudiar lo que vamos a hacer, sugiero el siguiente artículo:

https://medium.com/@OmkarSadekar/tex...s-8a2ae4f171ee

Esto se está poniendo interesante. ¿Quién sabe si en el futuro no hacemos una versión para PowerCobol? Probablemente necesitará ser una versión más reciente, pero por ahora sigamos con gnuCOBOL.

Saludos.

[ATTACH=CONFIG]1000[/ATTACH]

Algún progreso, por fin.
 

Encontré diversos problemas con los componentes en C/C++ usados para hacer el puente entre gnuCOBOL y Python (versiones muy antiguas y ya no soportadas, código que fallaba en la compilación, etc.). Hace algunos días, Kuk mencionó en una publicación el gCobol, una versión GCC ("open source") de Cobol que podría ser una alternativa a gnuCOBOL. Me puse en contacto con la empresa que lo está implementando. A pesar de la cordialidad al responder mis preguntas, la verdad es que no hicieron ningún esfuerzo por ayudar a integrar su compilador con Python. Alegaron estar ocupados con eventos y presentaciones de lo que tenían entre manos y que el ejemplo del FAQ del propio gnuCOBOL debería funcionar.

Terminé encontrando, en su falta de visión, la motivación que necesitaba para sumergirme de lleno en el problema. Después de cierto esfuerzo, logré que GNU Cobol finalmente se comunicara con Python. No es perfecto, pero cumple con lo que necesitaba. Debo finalizar algunos detalles, pero grabaré un vídeo y pondré el enlace aquí para mostrar cosas que pueden hacerse con esta integración.

Es una pena que no se hayan interesado. Probablemente acabarán beneficiándose de las ideas una vez que las vean funcionando, pero no tendrán una gran ventaja competitiva para impulsar su solución. No es de extrañar que Cobol sea un artículo de museo: solo hay momias haciendo compiladores.

Por cierto, dado que la integración se da entre la capacidad de gnuCOBOL de llamar a una rutina en C que a su vez llama a Python, creo que no debería haber problema en hacer lo mismo con PowerCOBOL. Tal vez mi memoria me engañe, pero creo haber leído en algún manual de Fujitsu algo sobre cómo llamar LIBs o DLLs en C, o algo parecido. Si esta integración fuera posible, se podría abrir un nuevo mundo para quienes usan Power (creo que incluso la versión 3 podría utilizarse en este caso).

Emerson

Hola:

Yo en estos dias voy a empezar a hacer pruebas con esto Cobol + Python - Cobol Foro

Veremos qué tan práctico es.

Saludos.

Fito...