Re: Image preloading

[Deskblue Software - Javier Sánchez <jsanchez deskblue com>]

El lun, 21-11-2011 a las 19:50 +0100, Felix Riemann escribió:
> 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).

I have in mind reuse job system.

>  If that becomes
> true we might need to do the refactoring work there that I wanted to do
> since ages now.

Maybe, we would define those components that will be refactored and
which are our targets and milestones, because if we don't do it EOG's
code will always be an older code.

In the last months only bug fixes or language translations patches are
included in EOG, but not new enhancements. I think that if we don't
refactor the EOG's code it will be very difficult to add any enhancement
(like image preloading).

For this reason we must define what EOG would be in the next years: EOG
architecture, new API of the EOG components and all that you want. I'm
working in my own idea of this work. If you want I share it with you in
this list.

> Felix
> 
> 

Javier