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