[Buoh-dev] Roadmap

[carlosgc at gnome.org (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 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/42fc5886/attachment.pgp