[Buoh-dev] Roadmap

[carlosgc at gnome.org (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 yahoo es
   carlosgc 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