[Buoh-dev] Roadmap

[Carlos Garcia Campos]

El jue, 14-07-2005 a las 16:53 +0200, Esteban Sánchez escribió:
> 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

Altísima!! Es la funcionalidad principal. Por muy bien que hagamos todo
lo demás, si la funcionalidad principal apesta, apestará la aplicación
entera. La carga del comic es la accion que mas se va a repetir en un
uso normal. Es vital que esto se haga de manera rápida y limpia. 

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

hmm quien ha hablado de hilos? de momento no veo una necesidad vital de
usar hilos. La primera vez que accedes a un comic y este falla, se marca
en la lista como no accesible, de manera que si se vuelve a seleccionar
no trate de bajar de nuevo el comic. Para eso no hacen falta hilos. 

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

Te contesto con lo mismo.

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

si, suena razonable. El problema entonces es que si el buoh se encarga
de forma privada, cada vez que el modelo cambie tiene que volver a
aplicar el filtro y después guardar en disco. Si se encarga la lista,
como su modelo ya está filtrado, tan solo hay que coger el modelo tal
cual de la lista y pasarselo al buoh para que genere el xml a partir de
se modelo directamente. Sería menos costoso. 

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

antes no lo hacia? pensaba que si, por eso lo hice así.

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

Media o alta. La barra de estado permite añadir una breve descripción a
cada opción del menu, entre otras cosas, Incluso añadir, si es
necesario, una barra de progreso para proporcionar feedback en
operaciones costosas. En general da feedback, que es muy importante.

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

Es bastante sencillo. 

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

Esto hay que verlo con calma. Hay que evitar features innecesarias. 

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

lo dudo, pero si, es baja.

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

Añado algo mas:

* El foco de los widgets

* Revisar el layout del menú y las opciones, hay que evitar tener menús
recargados, quitar todas las opciones no necesarias. Idem para la
toolbar

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/42fc5886/attachment.pgp