[Buoh-dev] Roadmap

[Esteban Sánchez]

El jue, 14-07-2005 a las 14:24 +0200, Carlos Garcia Campos escribió:
> 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. 

Pues sí, y la verdad es que ahora lo veo más factible :)

> A grandes rasgos queda:

Bien, a grandes rasgos la lista está bien y quizás sea buena idea el
organizarlos por prioridades. Voy a comentar lo que me parece a mi, algo
totalmente discutible, claro :)

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

Alta

> * 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

Media

A grandes rasgos todos los tipos de comics tienen las mismas propiedades
interesante (Autor, titulo y URI), quizás con alguna diferencia como la
fecha de publicación o algo así. De momento para curarnos en salud por
posibles ampliaciones lo mejor sería con un widget para cada 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.

Media o alta

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

Media, bastante sencilla

> * 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í)

Media o baja

La idea era hacer algo parecido al liferea, que si no hay ninguna fuente
seleccionada muestra un mensaje de bienvenida. Con respecto al error, la
aproximación que hice tenia la finalidad de no ser intrusiva, es decir,
evitar un dialogo de error al que hubiese que darle a aceptar. La idea
que propones es interesante pero la diferencia principal que tenemos es
que (de momento) no tenemos hilos y no podemos saber si un comic está
accesible hasta que no se selecciona. Cuando creemos hilos que lo
comprueben los comics, la aproximación que ofreces tendrá toda la razón
del mundo. Por eso lo pongo en media o baja.

> * 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í.

Media o baja

Pasa lo mismo que con la anterior.

> * 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.

Alta

Principalmente creo que es mejor que sea el buoh quien se encargue y con
respecto a cuando hacerlo, creo que sería mejor hacerlo siempre que haya
cambios, por una sencilla razón. Las veces que se va a cambiar la lista
de comics van a ser pocas, por lo que los accesos de escritura serán
también pocos. Con la otra opción, siempre que se salga se va a acceder
a disco para comprobar el fichero.

> * 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.

Baja

Realmente no sé si cachear es necesario porque ahora la vista del comic
se comporta mejor y guarda los comics ya vistos. De todos modos, es
importante permitir guardar un comic como una imagen.

> * Hace falta una barra de estado.

Baja

Lo pensé en su momento, pero realmente no le vi mucho uso, pero por
momentos se lo voy viendo :P

> * 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.

Medio

> * Bookmarks: no se muy bien que utilidad puede tener

La idea no es hacer un simple visor de comics, si no que si algún comic
te hace especial gracia puedas almacenarlo en una lista de marcadores.
No sé, era una idea loca más :P

> * 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.

Baja

No sé, quizás hay mucho paranoico que lee comics compulsivamente y a la
vez. Está bien lo que propones, pero tampoco es vital.

> 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.

Pues a pasarlo bien :)

Bueno, lo de novell está más que hablado, Intenté meterlo en sourceforge
y ni siquiera me contestaron. Kiwnix me comentó la forja de novell y no
tuve ningún problema. La opción de mantenerlo en mi servidor requería
más seguridad y realmente no me apetecía. Dentro de lo que cabe es lo
menos malo.

> Salu2

Saludos
-- 
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/20050714/24797d9f/attachment.pgp