[Buoh-dev] Roadmap

[Carlos Garcia Campos]

Holas de nuevo, 

creo que es importante, que una vez tengamos el nuevo diseño en marcha
empecemos a trabajar sobre el en busca de una "first public release".
Para ello lo mejor es marcarnos unas metas, y una vez conseguidas se
hace la release y se anuncia en todas partes. 

A grandes rasgos queda:

* El objeto comic manager para la gestión de anterior, siguiente y demas

* Dialogo de propiedades de un comic. Rellenar el dialogo. Si los
disntitos tipos de comics originan distintas propiedades, el contenido
del dialogo sería un widget que dependerá del tipo de comic

* Mejorar la carga del comic. Se ve lento y feo. Una posible solución
podría ser no usar gnome-vfs para ver si la uri es válida y tratar de
usar o bien un sistema propio (con sockets a pelo y totalmente
especifico para el buoh) o algo como libsoap o lo que sea. Pero esta
parte hay que tratar de optimizarla como sea.

* Mejoras del GUI: el frame de la lista de comics, la separación entre
widgets, etc. 

* Las vistas de mensajes: pueden ser widgets independientes en lugar de
formar parte directa de vista. A mi la vista de los mensajes (bienvenida
y error) no me termina de convencer. Igual con un mejor diselo cuelan,
pero no se si es mejor, inciar el buoh con la vista vacía y mostrar el
error de alguna otra manera (marcandolo en el treeview como no accesible
o algo así)

* Hablando de errores: Habría que añadir un campo mas al modelo de los
comics, que indique si el comic es accesible o no, con un timeout. Así,
si detectamos que un comic falla al cargarlo no seguimos intentándolo
(al menos hasta un tiempo determinado o durante la session actual). Como
he dicho antes se podría marcar en el treeview como no accesible
temporalmente. Creo que liferea hace algo así.

* La lista de los comics se ponía disabled cuando se estaba cargando un
comic. Eso se puede hacer usando los estados loaging y loaded del status
de la vista. 

* Guardar a disco la lista de comics del usuario. Tenemos varias
posibilidades aquí:

	Lo que es seguro es que debe ser una tarea del buoh, pero puede ser
pública y hacer que otros objetos la llamen explicitamente o privada y
que el buoh se encargue de todo. 
	
	+ Si el pública, sería un error, que los objetos la llamen cada vez que
se hace una operación sobre los comics. Lo suyo sería atar un callback
al cambio del modelo de la lista de comics desde el propio objeto comic,
que llame a la función del buoh que guarda en disco el modelo actual de
la lista de comics.
	+ Si es privada, puede ser el propio objeto buoh el que ate un callback
a cambios en su modelo, con lo que cada vez que algo cambie tiene que
rehacer el filtro y salvar en el archivo el resultado de dicho filtro
	+ Si es privada, también puede gestionarlo todo el propio buoh, per
guardando el resultado solo al final de la sesión, es decir, en su
destructor. De esta forma evitamos accesos innecesarios a disco. Al fin
y al cabo no es lo mas normal estar todo el rato cambiando la lista de
comics. Solo "fallaría" en caso de que la app pete de forma abrupta, ya
que no se guardarían los comics del usuario en disco.

* Sistema de caches: podrían guardarse a disco los comics, pero es
quizás demasiado espacio, por lo que habría que limitar el espacio
disponible para la caché. No se si merece la pena o no cachear los
comics. en cualquier caso, si se hace, añadiríamos una opción de trabajr
conectado/desconectado.

* Hace falta una barra de estado.

* Sistema de debug. Añadir una opción de compilación que active o
desactive el modo de debug. Añadir, sin pasarse, mensajes de debug.
Reemplazariamos los actuales g_debug por buoh_debug que comprueba si
estamos o no en modo debug para mostrar o no el mensaje. Habría que
añadir mas mensajes de los que actualmente hay.

* Bookmarks: no se muy bien que utilidad puede tener

* Tiene sentido tener dos instancias abiertas del buoh? Yo creo que no.
En ese caso es posible hacer que solo pueda haber una (con dbus, es
sencillo). De manera que si el buoh está lanzado y lo ejecutas de nuevo
se lanza una RPC a la instancia abierta que simplemente trae al frente
la instancia ya abierta. Podéis ver esta comportamiento, por ejemplo en
devhelp, aunque creo que ellos lo hacen con bonobo. Luego si vemos que
puede resultar util se pueden meter mas RPCs, pero creo que no.

Seguro que hay mas cosas que se me pasan y otras que surgirán, pero creo
que con lo dicho hay curro para todo el verano. 

Yo me voy mañana una semana de vacaciones, como zioma también esta de
vacaciones, en cuanto vuelva me creo la cuenta en la forja de novell
(que por cierto no me gusta nada de nada) y hago commit del nuevo
código. 

Salu2
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Carlos Garcia Campos a.k.a. KaL
   elkalmail at yahoo.es
   carlosgc at gnome.org
   http://carlosgc.linups.org
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=             
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
-------------- 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/20050714/891968d4/attachment.pgp