[Buoh-dev] Resucitando el buoh

[Esteban Sánchez]

El mié, 13-07-2005 a las 16:36 +0200, Carlos Garcia Campos escribió:
> Buenas, 
> 
> el otro dia medio aburrido me dió por bajar el buoh del CVS. Lo cierto
> es que, no lo tomeis a mal, pero no me gustó nada. Estuve hablando con
> esteban que me comentó que tenía pensado quitar cosas del fichero buoh.c
> y ponerlas en otros. 
> 
> En mi opinión el problema es mucho mas grave que eso, se trata de un
> problema de base, es decir, de diseño. Cuando empezamos con el proyecto
> se comentó que seguiríamos un modelo orientado a objetos y lo cierto es
> que el buoh a dia de hoy sigue un modelo orientado al kaos.

Bueno, en cierto modo es nuestra culpa porque al ser novatos en la
programación con GObject lo normal es que fuese caótico. Realmente
ibamos probando cosas y al final lo metíamos todo dentro del mismo
fichero. La verdad es que lo veo ahora y flipo, por eso no le he metido
mucha mano en todo el verano.

> Visto que el proyecto andaba bastante parado, empecé a pensar en nuevo
> diseño y a tirar algunas líneas de código. El resultado ha sido
> monstruoso, porque el buoh ha quedado casi reescrito. Paso a comentaros
> el modelo que yo propongo:

Jejeje, se necesitaba un cambio gordo de la mano de alguien con
experiencia, así que gracias :)

> Buoh
> -------
> 
> Este objeto representa la aplicación en si y contiene los datos
> "globales" (no os asusteis que no hay variables globales).
> 
> Padre: GObject
> 
> Atributos:
> 
> 	- BuohWindow   *window; Es la ventana de la aplicación
> 	- GtkTreeModel *comic_list; Modelo que contiene la lista de los comics
> 	
> Métodos públicos:
> 
> 	void          buoh_exit_app           (Buoh *buoh);
> 	void          buoh_create_main_window (Buoh *buoh);
> 	GtkTreeModel *buoh_get_comics_model   (Buoh *buoh);
> 
> Creo que no necesitan mucha explicación.
> 
> Este objeto sigue un patrón de diseño singleton por dos motivos:
> 
> 	* Tan solo puedo haber una instancia del objeto. Solo hay una
> aplicación
> 	* Es un truco que nos permite mantener una variable global sin usar una
> variable 			global. Mirad el código y vereis de que hablo.
> 
> El programa principal básicamente crea un objeto buoh e invoca el método
> create_main_window ()
> 
> BuohWindow
> ----------------
> 
> Este objeto representa la ventana de la aplicación. Lleva la gestión de
> todo lo que tiene que ver con la ventana (menus, toolbar, etc.)
> 
> Padre: GtkWindow
> 
> Atributos:
> 	- BuohView      *view; Es la vista de los comics, o mensajes como el de
> bienvenida o error
> 	- BuohComicList *comic_list; Es la lista de los comics disponibles del
> usuario
> 	- GtkWidget     *properties; Dialogo de propiedades de una comic
> 	- GtkWidget     *add_dialog; Dialogo de añadir comic
> 
> La vista y la lista de comics son widgets hijos del objeto.
> 
> BuohView
> -------------
> 
> Es el objeto encargado de cargar y mostrar los comics.
> 
> Padre: GtkNotebook
> 
> Atributos:
> 	- Comic           *comic; El comic que tiene que mostrar

¿No tendría un pixbuf loader y un GtkImage?

> BuohComicList
> -------------------
> 
> Es la lista de los comics seleccionables por el usuario
> 
> Padre: GtkFrame
> 
> Atributos:
> 	- GtkTreeModel *model; es un filtro del modelo global de la aplicación
> 	- BuohView     *view; un puntero a la vista
> 
> En este objeto no he trabajo el frame en cuanto a diseño de HIG, porque
> no estoy seguro de el. Es elago que quería comentaros. En mi opinión el
> fram aqui sobra. Se puede usar la cabecera del tree_view para poner
> "Comic List", o bien dejar el frame, pero quitar la cabecera del
> tree_view. Si quitamos el frame este objeto heredaria de GtkContainer o
> GtkBin sin mayores complicaciones

Vaya, tienes razón, ahora que me fijo queda feo de cojones. Bueno, creo
que la idea de poner la cabecera del tree view era para poder poner
también el autor del comic. Puede ser algo irrelevante, así que se
podría quitar directamente y dejar el frame. Personalmente creo que
queda más bonito con frame y sin cabeceras, pero si no se tiene que
hacer así...

> BuohPropertiesDialog
> ----------------------------
> 
> Es el dialogo de propiedades de un comic. No tiene mucho misterio,
> hereda de GtkDialog y contiene un puntero al comic del que tiene que
> mostrar sus propiedades. Este todavía no está hecho. Está hecho el
> esqueleto, solo falta mostrar el contenido del dialogo
> 
> BuohAddComicDialog
> ----------------------------
> 
> Muy similar al anterior, pero contiene la lista de los comics, usando el
> modelo global de la aplicación
> 
> El resto son los objetos comic. Todavía que dan muchas cosas por hacer:
> 
> El objeto comic:
> 
> No se porque hay un objeto comic-simple, no se lo que es.

El objeto comic es una interfaz a los distintos tipos de comics. El
comic-simple es el que tiene como características que las URIs de los
comics tienen las fechas del día, por lo que es bastante sencillo
conseguirlas.

Lo llamé así pues porque no encontré un adjetivo mejor, pero la verdad
es que no me gustaba.

> El objeto comic debe llamarse BuohComic por consistencia con el resto de
> objetos, por lo que hay que cambiarlo en todo el archivo.

Ahora con todos los cambios quizás tenga más sentido, pero la idea
inicial era separar las clases de los comics de la del buoh. Quizás con
la esperanza de hacer un "libcomic"...

> Hay mas cosas que no he hecho, a propósito:
> 
> La gestión de next y forward de los comics. Tal y como está ahora es el
> propio comic el que se encarga de eso. En mi opnión un comic no es mas
> que una uri y unas cuantas características, no existe ahí el concepto de
> anterior ni siguiente. 

La eterna lucha :P

> La solución sería usar un objeto en medio, por ejemplo BuohcomicManager,
> que se encargue de esas gestiones. Tendrá los métodos de siguiente,
> anterior, primero, último o buscar comic. 

Pues sí, me parece algo mejor porque de este modo se ve toda una serie
de comics como un libro (tebeo) y se evita todo el tema de que el
trabajo sucio lo haga el comic.

> El tema de la carga de los comics sigue siendo muy lento, es algo que
> hay que solucionar, pero vamos, que es un problema ya antiguo.

¿Te refieres a la descarga de un comic o a la carga de la lista de
comics (leer el XML)?

> He quitado a posta lo de redimensionar la ventana en función del tamaño
> del comic. No funcionaba del todo bien y se hace muy raro ver que la
> ventana cambia de tamaño. 

Sí, pero lo hice otra vez para probar y conocer un poco las funciones de
un GtkWindows

> Hay cosas de diseño que hay que mirar (HIG).

Algunas :P

> Bueno, pues abajo va un snapshot [1] de lo que he hecho. He preferido
> hacerlo así en vez de un parche porque son demasiados cambios y así es
> mas facil de ver y probar. 

Gracias, voy a echarle un vistazo

> Si queréis seguir adelante con este diseño, me registro en la forja y
> hago commit para que sigamos currando todos a partir de el. 

Ahora te comento

> Seguro que se me olvidan cosas que comentar. Echad un vistazo al código
> que ahí si que está todo
> 
> [1] http://carlosgc.linups.org/files/buoh-kal.tar.bz2
> 
> Salu2
> _______________________________________________
> Buoh-dev mailing list
> Buoh-dev at forge.novell.com
> http://forge.novell.com/mailman/listinfo/buoh-dev
-- 
Esteban Sánchez
 esteban at steve-0.com
 http://steve-o.org
 http://subanales.com/
 ------------------------------------------------
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB6E0F8AF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://forge.novell.com/pipermail/buoh-dev/attachments/20050713/43143dab/attachment.pgp