image viewers: a different approach

Luciano Montanaro mikelima at cirulla.net
Wed Oct 26 14:53:45 BST 2005


El Miércoles, 26 de Octubre de 2005 15:18, Lubos Lunak escribió:
> On Wednesday 26 of October 2005 15:11, Luciano Montanaro wrote:
> > El Miércoles, 26 de Octubre de 2005 14:50, Lubos Lunak escribió:
> > >  I don't see the point of having both 1 and 2. 1 is just a subset of
> > > 2 and so 2 can provide everything for 1 too. Featureless doesn't
> > > automatically also mean fast, just compare Kuickshow and KView. Also
> > > note that e.g. fast and incremental loading actually contradict each
> > > other,
> >
> > If you consider total loading time, sure. But Incremental loading gives
> > a faster feedback to the user, which I think, is the important thing.
>
>  Not if the non-incremental way can make it in 0,2s. But I don't think
> that's the matter of this discussion.

Ok, but how do you know in advance how much time will be needed to show the 
image? Remember the KPart can get input from a large number of different 
IOSlaves, and also the image size can be much different.

If the speed impression is important the viewer could wait until the image 
has loaded, or, say, half a second has passed, and then update the view 
every second or such. This way you could go pretty fast for fast ioslaves 
or small images, and still show progress to the user.

To return to the topic, I would go for a simple one-image part, and another 
separate image list management part. These could be combined in a two pane 
part in konqueror, for simple tasks, or in a more specialized application 
for organizing tasks and maybe simple editing.   

GwenView interface seems ok from my point of view (I normally use it as a 
Konqueror view, however, so maybe I am a bit off the mark).

Luciano

-- 
Luciano Montanaro //
              \\ //
               \x/ www.cirulla.net




More information about the kde-core-devel mailing list