Programacion de interfaces graficas

[Mauricio]

Hola gente, mi consulta es básica pero quizás no tan fácil de responder.

Es necesario si o si saber POO para programar en algún lenguaje para hacer interfaces gráficas en entorno Windows?

Recuerdo que en Borland C o en Turbo C, programaba interfaces gráficas bajo DOS, con comandos como por ejemplo:

Para inicializar el modo grafico era simplemente escribir estas lineas:

int gdriver = DETECT, gmode, errorcode;

   initgraph(&gdriver, &gmode, "C:\\TC\\BGI");

   errorcode = graphresult();

   if (errorcode != grOk)  /* an error occurred */

   {

      printf("Graphics error: %s\n", grapherrormsg(errorcode));

      printf("Press any key to halt:");

      getch();

      exit(1); /* terminate with error code */

   }

Y luego era muy facil, usabas funciones como:

setcolor(WHITE);

circle(135,100,5);

line(140,100,160,100);

rectangle(160,105,200,95);

settextstyle(DEFAULT_FONT, HORIZ_DIR, 1);

outtextxy(110,100,"+E");

Una captura del programa es por ejemplo esta (corriendo bajo Android con DOSBox):

Ahora mi pregunta es: es posible hacer esto mismo pero sin la complejidad de POO, y con la simpleza que se hacian las interfaces en Borland o Turbo C ?

He visto ejemplos de programación de interfaces y son un dolor... con tiras de instrucciones larguísimas para hacer una simple ventana, y todavía aparte nunca encontré de forma clara un tutorial completo para hacer algo como el programa que les muestro en el screenshot.

Si existe algo en C, mejor porque es el unico lenguaje que se medianamente bien. Se que en Python algo se puede hacer, pero tendria que cambiar de lenguaje y empezar con otro nuevo desde cero.

Gracias y saludos,

Mauricio.

[Mirko Leonardo Serra Labán]

Es posible crear interfaces gráficas en cualquier lenguaje: assembler, C, etc.

Pero lo normal es recurrir a POO porque simplifica la tarea enormemente.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Mauricio]

Y si, puede ser que para el que sepa POO sea muy simple, pero para mi que no se, me parece un dolor... comparado con la simpleza de las lineas de código que les copie.

Por eso mi pregunta es si existe otra forma de hacer interaces graficas sin POO.

[Juan Cecconi]

Fijate las APIs de windows en MSDN. Eso es lo que buscas. Mira las GDI en particular, aunque van quedando obsoletas de a poco (googlea x ejemplo DrawRect).
El IDE te permite hacer la GUI con botones y demás y con la apis dibujas como lo hacías en DOS.
Saludos

[Mirko Leonardo Serra Labán]

​Un hello world de ejemplo en GTK (http://kevinboone.net/gtkwindows.html):

#include <stdio.h>;
#include <gtk/gtk.h>;

int main (int argc, char **argv)
{
  printf ("hello world\n");


  gtk_init (&argc, &argv);


  GtkDialog *dialog = GTK_DIALOG (gtk_message_dialog_new
    (NULL,
     GTK_DIALOG_DESTROY_WITH_PARENT,
     GTK_MESSAGE_ERROR,
     GTK_BUTTONS_CLOSE,
     "Hello, world"));

  gtk_dialog_run (dialog);

  gtk_widget_destroy (GTK_WIDGET (dialog));
}

​No es complicado. Y ese código de arriba en teoría es válido para más de un sistema operativo. GTK es libre y multiplataforma. Es un buen lugar para empezar si querés multiplataforma.

Sino, mi recomendación para un arranque rápido es que te bajes un Borland C++. Aunque ya no se produce más, a mí me ha resultado personalmente cómodo. Sino, una alternativa más moderna es Visual Studio, que tiene una versión gratuita para usos no comerciales, si no me equivoco. Estos últimos dos son más orientados a objetos y solo funcionan en Windows creo. En estos el dibujo de las ventanas y la interfaz gráfica se hace con el mouse y la cantidad de código es mínima.

[Mauricio]

Gracias Mirko, no parece tan complicado como Visual C.

Tenes alguna pagina con ejemplos desde sencillo a intermedio? 

Muchas veces lo que me mata es que encuentro un tutorial, y lo unico que te enseñan es a hacer una ventanita con un boton que diga: Hello World.

Lo que quiero es por ejemplo hacer un graficador de funciones, para luego hacer un visualizador de onda para la placa de sonido, solo por poner un ejemplo de aplicacion.

O leer datos por USB (o por RS-232) y graficar.

Saludos.

[Mauricio]

Gracias Juan, voy a ver esas APIs y lo que me paso Mirko.

Sabes de algun manual practico con ejemplos paso a paso?

[Mirko Leonardo Serra Labán]

No lo he usado al GTK más que para jugar. Aparentemente hay una librería (cairo) que permite hacer dibujos (multiplataforma y puede usar aceleración si está disponible):

http://cairographics.org/samples/

Parece bastante c-like.

Pienso que el costo de aprender nuevas cosas a veces se ve compensado con tener librerías que ya hacen las funciones que querés.

[martin ribelotta]

Respondo entre lineas:

El 25 de agosto de 2014, 12:49, Mauricio <mnmel...@gmail.com> escribió:

Hola gente, mi consulta es básica pero quizás no tan fácil de responder.

Es necesario si o si saber POO para programar en algún lenguaje para hacer interfaces gráficas en entorno Windows?

Si, todos los paradigmas de desarrollo de GUI's fueron creados por y para la POO.

Esto no quiere decir que tengas que aprender un lenguaje nuevo, sino nuevas "mañas".

Me explico, POO es un concepto abstracto, no depende PARA NADA del lenguaje. Yo puedo programar orientado a objetos en smalltalk, C++, ruby, python, perl, C, assembler, codigo de maquina, maquina de babage, o piedras en el suelo.

De hecho, cuando programamos de forma estructurada, estamos programando implicitamente con el objeto "entorno" como herramienta. Las variables tambien son "objetos" por asi llamarlo. O sea, no es ningun misterio la POO, es simplemente formalizar conceptos que surgen solos del desarrollo de sistemas complejos (y una GUI es un sistema complejo)

 

Recuerdo que en Borland C o en Turbo C, programaba interfaces gráficas bajo DOS, con comandos como por ejemplo:

Para inicializar el modo grafico era simplemente escribir estas lineas:

int gdriver = DETECT, gmode, errorcode;

   initgraph(&gdriver, &gmode, "C:\\TC\\BGI");

Constructor del objeto gdriver

 

   errorcode = graphresult();

   if (errorcode != grOk)  /* an error occurred */

   {

      printf("Graphics error: %s\n", grapherrormsg(errorcode));

      printf("Press any key to halt:");

      getch();

      exit(1); /* terminate with error code */

¿A esto no le falta cleanup???? ;-) Ok, es simplificar el codigo no lo tomes a mal jeje 

 

   }

Y luego era muy facil, usabas funciones como:

setcolor(WHITE);

Seteo de la propiedad color del objeto "graphics context" del subsistema grafico.

 

circle(135,100,5);

Ejecución del metodo circle sobre el objeto screen

 

line(140,100,160,100);

idem 

rectangle(160,105,200,95);

idem 

settextstyle(DEFAULT_FONT, HORIZ_DIR, 1);

outtextxy(110,100,"+E");

Bueno, supongo que se entiende.

 

Una captura del programa es por ejemplo esta (corriendo bajo Android con DOSBox):

Ahora mi pregunta es: es posible hacer esto mismo pero sin la complejidad de POO, y con la simpleza que se hacian las interfaces en Borland o Turbo C ?

He visto ejemplos de programación de interfaces y son un dolor... con tiras de instrucciones larguísimas para hacer una simple ventana, y todavía aparte nunca encontré de forma clara un tutorial completo para hacer algo como el programa que les muestro en el screenshot.

Si existe algo en C, mejor porque es el unico lenguaje que se medianamente bien. Se que en Python algo se puede hacer, pero tendria que cambiar de lenguaje y empezar con otro nuevo desde cero.

Gracias y saludos,

Mauricio.

--

[Fernando Cacciola]

Hola Mauricio,

2014-08-25 12:49 GMT-03:00 Mauricio <mnmel...@gmail.com>:

Hola gente, mi consulta es básica pero quizás no tan fácil de responder.

Es necesario si o si saber POO para programar en algún lenguaje para hacer interfaces gráficas

Siguiendo con la línea de respuesta de Martín, diría que:

La Programación Orientada a Objetos formaliza la idea de considerar a una aplicación como una colección de objetos interactuando entre sí. De ese modo, uno crea y destruye objetos, y los hace interactuar haciendo que se comuniquen entre ellos, por ejemplo, enviándose mensajes unos a otros.

Si para una determinada aplicación, esta descomposición en objetos resulta natural, entonces la POO resulta una enorme simplificación y nos permite expresar nuestro programa de un modo muy natural y sencillo de entender.

Pongamos por ejemplo una Interfaz de Usario Gráfica (GUI)

Aquí uno necesita  *crear* ventanas, botones, cuadros de texto e imagen, etc.. o sea objetos. Necesita asociar esas objetos, es decir, poner este botón en aquella ventana y este cuadro en aquella otra. Luego necesita que se comuniquén entre sí, por ejemplo, un objeto debe mirar lo que ocurre con el mouse y/o teclado y  cuando este detecta un *evento* debe pasárselo a todas las ventanas, o al menos a aquella que tenga actualmente el *foco*. Luego cada ventana tiene que ver si ese evento le corresponde (por ejemplo, el usuario hizo click dentro de la ventana o no), y si es así, pasarlo a su vez a todos sus *objetos hijos* como botones, cuadros, etc.. Es decir, uno necesita que se envien mensajes entre estos distintos objetos que naturalmente componen nuestra GUI.

Entonces, lógicamente, los lenguajes OO son muy naturales e ideales para trabajar con UI.

Y, como dice Martín, una GUI *es un sistema de objetos* ya sea que lo programes en Smallalk o en LISP, por lo que realmente, si eso es lo que quieres, no usar OOP va a ser una complicación y no una ayuda.
 

en entorno Windows?

Hoy en día es extremandamente dificil encontar algo para GUI que sea específico de una u otra plataforma. Así que podemos ignorar que sea Windows.

 

Recuerdo que en Borland C o en Turbo C, programaba interfaces gráficas bajo DOS, con comandos como por ejemplo:

Para inicializar el modo grafico era simplemente escribir estas lineas:

int gdriver = DETECT, gmode, errorcode;

   initgraph(&gdriver, &gmode, "C:\\TC\\BGI");

   errorcode = graphresult();

   if (errorcode != grOk)  /* an error occurred */

   {

      printf("Graphics error: %s\n", grapherrormsg(errorcode));

      printf("Press any key to halt:");

      getch();

      exit(1); /* terminate with error code */

   }

Y luego era muy facil, usabas funciones como:

setcolor(WHITE);

circle(135,100,5);

line(140,100,160,100);

rectangle(160,105,200,95);

settextstyle(DEFAULT_FONT, HORIZ_DIR, 1);

outtextxy(110,100,"+E");

Aquí debo decir algo importante.

En tu ejemplo, no estás usando una libreria de GUI sino una libreria de Gráficos 2D.

Algo que es de mucho más bajo nivel.

Entonces, es muy posible que cuando dices que las otras cosas que has visto te parecen muy complejas es porque comparas manzanas con naranjas.. o más bien, bicicletas con aluminio, caucho y plástico.

 

Ahora mi pregunta es: es posible hacer esto mismo pero sin la complejidad de POO, y con la simpleza que se hacian las interfaces en Borland o Turbo C ?

Hay una gigantesca diferencia entre que algo sea simple o complejo y que nos resulte fácil o difícil.

Lo único simple en tu ejemplo es que a tí te resulta familar *sumado* a los requerimientos muy específicas de eso en particular que quieres hacer.

Si *todo* lo que quiero es poner un par de textos en pantalla y dibujar un par de líneas (que es tu ejemplo), pues puede bien ser cierto que una librería de gráficos en 2D sea adecuada y tenga la sencillés necesaria.

Pero, ni bien quiero tener un botón, o un cuadro de opciones (combo box), o más de una ventana, entonces esa libreria básica 2D va a resultar completamente insuficiente.

Una librería GUI (naturalmente orientada a objetos) puede tener una cierta curva de apredizaje, y por eso, presentarse como díficil para el que recién comienza. PERO, una vez aprendida, la tarea de programar GUI con ella se vuelve sumamente más sencilla que sin ella (u otra libreria OO para GUI).

HTH

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

[Fernando Cacciola]

2014-08-25 14:24 GMT-03:00 Mauricio <mnmel...@gmail.com>:

Gracias Mirko, no parece tan complicado como Visual C.

Tenes alguna pagina con ejemplos desde sencillo a intermedio? 

Muchas veces lo que me mata es que encuentro un tutorial, y lo unico que te enseñan es a hacer una ventanita con un boton que diga: Hello World.

Lo que quiero es por ejemplo hacer un graficador de funciones, para luego hacer un visualizador de onda para la placa de sonido, solo por poner un ejemplo de aplicacion.

O leer datos por USB (o por RS-232) y graficar.

OK

Para ser entonces que tu no necesitas una "interfaz gráfica" en el sentido moderno. Es decir, ventanas, dialogos, botones, cuadros, etc  con una cola de eventos, con señales y slots, etc...

Si lo que quieres es una libreria 2D, como la que tenía Turbo en la época del DOS, entonces te recomiendo esto:

http://cairographics.org/

es enteramente en C, y al no tratarse de una librería para GUI sino tan solo para "dibujar", maneja solo unos pocos "objetos" (que pueden no parecerlo pero son objetos en definitiva)

Vas a econtrarla sumamente parecida al BGI (Borland Graphics Interface) que es lo que usabas (y yo también) en aquelal época.

[martin ribelotta]

Agrego:

http://qt-project.org/doc/qt-5/qtserialport-terminal-example.html

Eso es la parte del serial (fijate que no fue mucho mas allá de los ejemplos de la propia digia)

Y este es un tipo que hizo lo mismo a lo que te referís en qt:

http://robottini.altervista.org/charting-data-sent-via-serial-port-in-real-time

Tercer resultado en google al poner "Qt graphics serial data"

--

[Guillermo Enrique VIDES]

Para ese tipo de aplicacion existen librerias para qt

QCustomplot

QWT

que resuelven el display de una señal en un widget (window gadget) con un alto nivel de abstraccion

tambien hay librerias para python y QT

PYQT4

Pyqtgraph

saludos

---

From: martinr...@gmail.com
Date: Mon, 25 Aug 2014 16:41:18 -0300
Subject: Re: [embeb32] Programacion de interfaces graficas
To: embeb...@googlegroups.com

[Gustavo Murias]

Yo hice varias interfaces el Delphi (object Pascal), que es orientado a objetos. Ahora estoy utilizando Lazarus (free pascal).

Lo real es que si bien son lenguajes orientados a objetos, yo nunca tuve necesidad de saber exactamente de que se trata, es decir, nunca utilicé los conceptos de herencia ni de polimorfismo, que creo que son las principales características de POO. Solo me limité/o a modificar las propiedades de los componentes, gestionar los eventos que interesan, y simplemente escribir el código necesario, en mi caso en Pascal.

No me considero programador, ya hay muchas cosas que ignoro, pero en respuesta a tu pregunta, yo creo que si se pueden hacer interfaces gráficas bien completitas, incluso con lenguajes orientados a objetos, sin saber POO.

saludos.

[Mauricio]

Muy buena analogia Ruso, eso me vendria bien, una comparativa entre lenguaje estructurado y POO, para ir entendiendo mejor algo tan abstracto.

Igualmente, los programas de POO que he visto para hacer ventanas de hello world, no me parecen para nada "cleanup".

Ejemplo: en Visual Studio, creas un File --> New --> Project --> Windows Form Application.

Te crea una ventana, le das click, y te aparece este horripilante non-cleanup codigo:

#pragma once

namespace ventana {

using namespace System;

using namespace System::ComponentModel;

using namespace System::Collections;

using namespace System::Windows::Forms;

using namespace System::Data;

using namespace System::Drawing;

/// <summary>

/// Summary for Form1

///

/// WARNING: If you change the name of this class, you will need to change the

///          'Resource File Name' property for the managed resource compiler tool

///          associated with all .resx files this class depends on.  Otherwise,

///          the designers will not be able to interact properly with localized

///          resources associated with this form.

/// </summary>

public ref class Form1 : public System::Windows::Forms::Form

{

public:

Form1(void)

{

InitializeComponent();

//

//TODO: Add the constructor code here

//

}

protected:

/// <summary>

/// Clean up any resources being used.

/// </summary>

~Form1()

{

if (components)

{

delete components;

}

}

private:

/// <summary>

/// Required designer variable.

/// </summary>

System::ComponentModel::Container ^components;

#pragma region Windows Form Designer generated code

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

void InitializeComponent(void)

{

this->SuspendLayout();

// 

// Form1

// 

this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);

this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;

this->ClientSize = System::Drawing::Size(284, 262);

this->Name = L"Form1";

this->Text = L"Form1";

this->Load += gcnew System::EventHandler(this, &Form1::Form1_Load);

this->ResumeLayout(false);

}

#pragma endregion

private: System::Void Form1_Load(System::Object^  sender, System::EventArgs^  e) {

}

};

}

O sea, a mi no me interesa tener que hacer una carrera para hacer una aplicacion grafica simple de captura de datos en una PC... 

Imaginate si eso es el codigo por defecto para la ventana vacia... no quiero imaginar que sera el codigo final de una aplicacion...

Por eso mas arriba dije que Visual Studio lo descarte de entrada.

[Mauricio]

Me quedo muy claro todo Fernando.

Entonces claro, para hacer algo sencillo como lo que hice, con una libreria 2D andaria bien...

Y con los comentarios voy entendiendo mas el por que de la POO.

Gracias!

[Mauricio]

Genial... podria empezar por esa libreria grafica, y luego de a poco ir estudiando POO.

[Mirko Leonardo Serra Labán]

En Visual Studio, como en Borland, como en cualquiera de esos, te va a generar un montón de código automático... pero vos no tenés que tocarlo (de hecho, en algunos IDE el código automático se regenera, lo que metas ahí se pierde). El código automático crea la aplicación, un bucle que responde los mensajes del sistema operativo, crea las ventanas, etc. Es decir, el "trabajo sucio" está hecho.

Lo que hacés es arrastrar un botón a la ventana, le das dobleclick y te abre una función que se va a ejecutar solo para el click de ese botón. Más limpio imposible.

void fastcall button1click (TObject *sender)

{

  <-- Aquí el cursor

}

De hecho, el texto de ese botón se setea en una ventanita que te permite cambiar las propiedades (ancho, alto, texto, color, etc.) sin una línea de código. Separa lo que es la parte "funcional" del programa con lo que es la parte presentación.

Asimismo, si se quisiera ejecutar una función al seleccionar el botón, uno elige el botón busca en la GUI donde están los eventos, puede ser en ese caso por ejemplo OnFocus, y al hacer doble click abrirá una función vacía, igual a la anterior, solo que se llamará button1focus o algo así, y ahí uno pone lo que quiere.

Ahí dentro, cambiar el color del boton es tan sencillo como hacer:

Button1->Color = clRed;

Cambiar el texto de un label (no me acuerdo si Text o Caption es la propiedad, pero para eso están el autocompletar, la ayuda y la GUI):

Label1->Text = "Hola mundo";

El resto del código, en un principio, no interesa. No hay que mirarlo, no hay que tocarlo. Al menos no en un programa estilo "Hola mundo".

Te recomiendo que le des una segunda mirada al Visual Studio teniéndole un poco más de paciencia.

Y por supuesto, una vez que uno se va poniendo ambicioso, no queda otra que meterse a ver esos detalles, pero una vez que tenés la satisfacción de un par de programas sencillos andando, eso no resulta tan penoso.

Suerte.

[Ricardo Medel]

En mi tesis de grado (hace 22 años!) hicimos con una colega una librería en Turbo C++ (y que luego traduje a Turbo Pascal, aquel de Borland) que permitía al programador crear GUIs definiendo estructuras de datos. Por debajo había POO, pero el programador no tenía que saber eso, con saber sobre cómo asignarle valores a una variable tipo "registro" y llamar "procedimientos" ya podía tener su GUI (basada en texto, pero con menúes y botones) funcionando al compilar.

Habría que ver cuál era el "footprint", nunca chequeamos eso... lo único que queríamos era hacerla funcionar y recibirnos!

Debe ser casi imposible recuperarla hoy, ya que está en un diskette 5.25"! Pero el enfoque quizás sea válido y a alguno le interese replicarlo. Recuerdo haber bochado un paper de algún CASE que tenía un enfoque similar, por considerarlo poco innovador. Pero capaz que hay que buscar por ese lado nuevamente.

Ricardo Medel

 

--

[Alejandro Sincich]

He subido un video a http://youtu.be/ajlCvAV3gEU donde muestro resultados de programación gráfica con el lenguaje Processing, basado en Java, para W y Lx.

Espero les resulte de interés.

Alejandro