Re: Image preloading

[Felix Riemann <friemann gnome org>]

Am Sonntag, den 20.11.2011, 12:12 +0100 schrieb Deskblue Software -
Javier Sánchez:
> Hi guys!
> 
Hey Javier!

> This weekend, I'm studing how to solve the next bug in my list:
> 
> Bug 321603 - preload prev and next files.
> 
> After reading the code of EogThumbNav, EogThumbView, and EogListStore I
> think that is good time to refact this "component" of our image viewer.
> This classes models what looks like a MVC pattern. EogListStore acts as
> model, EogThumbNav and EogThumbView act as view and finally EogWindow
> acts as controller. But you can see that the business logic for image
> navigation (first, next, previous, last, ...) which I think it would be
> in model (remember EogListStore) it being in view (remember
> EogThumbView).
> 
> For reasons like that, my proposal is to refact the navigator component
> of the viewer. We can implement it as a "real" MCV pattern where model
> contains the business logic, where view is the graphical representation
> of the model and finally where controller maps view inputs as calls of
> model API.
> 
> This way the model API can contain public methods for image navigation
> (first, next, previous, last, ...) private methods for image preloading
> (which is the target of this bug) signals to notify that the active
> image has been changed and everything we want to add.
> 
> I started to make a simply prototype of that, but as you can imaging
> it's a big deal and I will not lose my time. For this reason I would
> like to know what do you think about my idea. Continuing for this path?
> Have you other any ideas to implement this enhancement? 

Well, the image switching/liststore part has always been a bit strange
IMHO. So, I'm open for anything that improves this part. :)

It's going to be interesting if that pre-loading stuff is going to work
with the job system that eog currently has. It might be a little to
inflexible for this stuff (the relation to the affected images is not
that obvious as one would like it to be for example). If that becomes
true we might need to do the refactoring work there that I wanted to do
since ages now.

Felix