[Buoh-dev] Varios asuntos

[carlosgc at gnome.org (Carlos Garcia Campos)]

El primero de todo, acabo de hacer commit, y os cuento:

El tema del hilo estaba muy bien y daba mayor fluidez al gui, pero su
objetivo principal era proporcionar una manera de poder parar la carga
del comic lo mas r?pido posible para que el usuario pueda seleccionar
los distintos comics de la lista y obtener respuesta inmediata por parte
del gui. Bien, pues esto antes no era cierto en el 100% de los casos.
Hay un momento critico, desde que seleccionas un comic hasta que empieza
a verse la imagen en que si seleccionas otro comic el gui no responde de
forma inmediata. Este momento cr?tico, del que ya hemos hablado mas
veces por motivos de feedback, se produce porque la llamada open de
gnome_vfs se queda bloqueando el hilo hasta que resuelve la url y
devuelve un manejador. Lo peor que nos puede pasar es que el hilo se
bloquee. Y esto sucede de forma esc?ndalosa si, por ejemplo, se caen los
servidores de dns, o tienes el interfaz de red levantado con un gw que
no existe. 
La soluci?n ha sido usar llamadas async en gnome_vfs. De esta manera,
mientras el open hace su trabajo el hilo no est? bloqueado, y puedes
detener al open con un gnome_vfs_async_cancel y terminar el hilo
despu?s. 
Como ya os habr?is dado cuenta, esto trae un problema a?adido. Si un
hilo no es mas que una funci?n y termina con el return de la funci?n, si
tras ejecutar el opne asincrono la funci?n sigue ejecutando sin
bloquearse a la espera del resultado de open continuar?a hasta el return
y el hilo morir?a inmediatamente. La soluci?n cutre es poner un bucle
infinito en espera activa, pero ni se me ha pasado por la cabeza. En su
lugar he creado un nuevo bucle de ejecuci?n de glib donde ejecutar? el
hilo. De esta manera, la forma de parar el hilo es tan simple como hacer
un g_main_loop_quit ()
Pues esta es la explicaci?n de los cambios realizados. La conclusi?n es
que ahora el hilo nunca est? bloqueado de forma que podemos hacerle lo
que sea cuando sea. Por otro lado ahora queda mas definida ese momento
cr?tico en que el hilo est? resolviendo, de manera que podemos a?adir un
nuevo estado al cargador en el futuro que nos indique que en ese momento
se est? resolviendo y proporcionar feedback para ello. Est? claro que
ese tiempo no lo podemos reducir, as? que lo mas que podemos hacer es
tratar de que hasta que empieza a aparecer la imagen no de la sensaci?n
de no estar haciendo nada.

Por otro lado, ya he reportado el bug de gnome-vfs sobre el error
generico siempre despu?s de un 404

Sobre el comic manager he estado pensando algunas ideas:

* El comic manager crea un nuevo problema: como saber cual es el primer
comic? si queremos proporcionar la funcionalidad de ir al primero, y
controlar en la de ir hac?a atras, que no se pase del primero,
necesitamos saberlo. Para ello es necesario realizar trabajo de becario
como dice esteban y proporcionar la fecha incial de cada tira al xml. Es
la manera que se me ocurre de hacerlo. Esto nos da otra ventaja, y es la
posibilidad de implementar las tiras de tipo nombre[0-9]+ ya que si
sabemos cuando fue la primera y cada cuanto tiempo sale, podemos
calcular los nombres en funci?n de la fecha actual.

* Como distinguir en el gui los distintos comics de una misma tira. Hay
que proporcionar al usuario la posibilidad de saber en que comic de toda
la tira est?, es decir, si est? en el primero, en el ?ltimo o por
fechas, si est? en el del dia tal del tal, o en el de la semana tal,
etc. No se si una barra de tiempos tipo f-spot podr?a encajar, es un
tema que no he pensado en profundidad.

Se que se me olvida algo que iba a contar, pero como este correo ya es
lo suficientemente largo lo dejo para otro momento cuando me acuerde. 

Animo que poco a poco estamos avanzando en el roadmap hacia la primera
release.

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/20050905/97dfb5f5/attachment.pgp