[Buoh-dev] Varios asuntos

[esteban at steve-0.com (Esteban Sánchez)]

El lun, 05-09-2005 a las 19:33 +0200, Carlos Garcia Campos escribi?:
> 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.

Eso fue algo que mir? en la versi?n antigua, pero no tenia suficiente
idea como para hacerlo.

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

Interesante :)

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

Feedback powah!! :D

Como soluci?n se me ocurri? hace tiempo el de poner un spinner (un icono
que se mueve) como en los web-browsers. Si no recuerdo mal te lo coment?
y la idea qued? aparcada a la espera de reducir el tiempo de espera.
Visto que has dado un gran paso en este sentido lo retomo. ?Qu? os
parece un spinner?

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

Cosa rara...

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

Supongo que el trabajo de becario no le mola a nadie, y en cierto modo
como yo soy el encargado de los comics, s? cual es su web y dem?s, pues
me tocar? hacerlo a mi :P

Otra curro de becario ser?a el de poner un enlace a la web original para
todos los comics.

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

Aqu? entra el concepto de "p?gina", entrecomillado porque quiz?s no es
un buen nombre. Si hacemos la analog?a de que al usar el programa
estamos leyendo un libro de tiras de comics, cada imagen ser?a una
p?gina del libro. Si se os ocurre otro nombre m?s explicativo u otra
met?fora pues decidlo :) 

El comic manager proporcionar? un m?todo para saber en qu? p?gina est?,
as? que s?lo hay que ver cual es la mejor manera de mostr?rselo al
usuario. La pega de la barra de F-spot (cogida tal cual) es que es m?s
para rangos de fechas, mientras que a nosotros s?lo nos interesa una
fecha concreta. Quiz?s nos toque innovar en este aspecto...

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

Oeoeoeoe :D

> Salu2

Saludos!

-- 
Esteban S?nchez
 esteban steve-0 com
 http://steve-o.org
 http://subanales.com/
 ------------------------------------------------
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB6E0F8AF