Se termina de migrar lo que habia hecho al nuevo modelo cliente-servidor, pero
tengo problemas para compilar el ejemplo en el directorio Server/tests (la lib
aparentemente compila).
- Se elimina atributo orientacion en Conducto porque no tiene sentido
para el modelo teorico.
- Se elimina la clase Codo, ya que su comportamiento es identico al Conducto,
y no agrega nada nuevo al modelo. Si va a existir clases VistaConducto con
alguna propiedad que le indique si debe dibujar un codo o un conducto recto.
- Se cambia diagrama a formato Dia.
- Se lo hace más conceptual.
- Se elimina el .png (no es un "fuente", se puede generar).
- Se hacen algunos cambios en el modelo, aunque el concepto es el mismo.
- Se arreglan los nombres para estar todos acorde con el coding style
- Se ocultan (private) constructores por default, de copia y operador =
para evitar que se creen objetos sin utilizar new.
- Se agrega codigo para desconectar un objeto
- Se arregla un bug que hacia que cuando un objeto se conectaba se incrementaban las cantidades
de entradas o salidas.
- Se agregan 2 nuevas clases para parsear los request HTTP: String y Request.
String extiende std::string y agrega métodos útiles a la hora de parsear.
Request extiende a std::map<std::string, std::string> y guarda variables sobre
el request HTTP al estilo variables de entorno en CGI.
- Se mueven los includes a un directorio plaqui/server porque string.h me pisaba
el string.h de la libc.
- Se usan las nuevas clases para obtener información básica sobre el request
como para empezar a traducir las URI en comandos para la planta (o el
servidor).
- Hice una regla para construir la librería estática (server.a) con todos los
.o de las clases del servidor.
- Me copio de ricky y pongo los .h en un directorio 'include' :)
- Pongo un directorio 'tests' con las pruebas.
- Muchas pequeñas correcciones.
- Algunos grandes cambios:
- Se agrega soporte de threads a Runneable.
- Estan funcionando Server y ControlServer de forma básica. Server puede
atender peticiones y cuando se conecta alguien crea un nuevo ControlServer
que maneja la conexión (falta liberar memoria, porque por ahora solo se
puede salir con Ctr-C). ControlServer recibe línea por línea hasta que una
línea sea vacía (detección simple de cabeceras HTTP).
- Se agrega un test del servidor: server_test.cpp.
- El diagrama de clases queda un poco desactualizado (y tal vez deprecated,
debería pasarlo a Dia así queda todo con el mismo formato).
- Agrego el dialogo de conectar
- Agrego una clase Menu para encapsular todos los items
del menu en lugar de hacer una clase por item.
- Actualizo la interfaz
- Agrego documentacion sobre las herramientas utilizadas
- Modifico el encabezado a utilizar en los archivos
- Client: agrego el handler para entrar al dialogo "Acerca de"
- Client; Inicio los archivos de informacion (ChangeLog, AUTHORS)
Agrego callback para salir del programa de 2 formas distinta : desde el menu creando un objeto derivado y desde la barra de herramientas pasando directamente la funcion a ejecutar
Agregue un intento de dibujar la grilla sobre el fondo, creando una clase
heredada de Gtk::Fixed. sin saber por que las lineas comienzan desde el
borde izquierdo de la ventana en lugar desde el borde derecho del widget.
No documentacion no es clara y no encuentro el error.
Le puse el icono de lo que se esta drageando cuando se draguea... Va tomando forma :). Tuve que hacer un par de maniobras con el "hot spot" para que caiga donde tenia que caer porque no vi bien el algoritmo que acomoda en la grilla.
Agrego ejemplo que hace drag and drop de elementos como caños, bifurcaciones y
codos, que ajusta a la cuadricula los elementos. Falta agregar el dibujo de la
grilla sobre el Gtk::Fixed y la habilidad de mover los elementos.
Se agrega configure.in y se modifica Makefile.am a test/gtkmm/dnd para hacer mas
facil la compilacion. Ahora para compilar :
#> aclocal
#> autoconf
#> automake -a
Solo la primera vez. Luego :
#> ./configure
#> make
Agrego una imagen generada en GIMP sobre como podria ser el uso de una
cuadricula en la interfaz de creacion. La idea es que los objetos GUI (caños,
codos, etc) sean de un tamaño multiplo de 32 ... Con esto se busca hacer mas
comoda la ubicacion de los elementos y ademas seria mas facil detectar las
conexiones entre objetos antes de guardar.