image viewers: a different approach

Lubos Lunak l.lunak at suse.cz
Wed Oct 26 13:50:27 BST 2005


On Wednesday 26 of October 2005 13:41, Michael Olbrich wrote:
> Hi,
>
> I have been following the discussion on KView and I think we need to
> take a step back. Focusing on individual applications will only result
> in chaos.
> The first step would be to look at the different tasks we want to
> accomplish. For me there are 4:
>
> 1. basic viewer. For links on webpages, emails and individual local
> images.
> Features: fast, incremental loading, zoom. Maybe scrolling by dragging.
> This is probably somewhere between khtmlimage and KView.
>
> 2. Enhanced viewer. For image folders (photos). Basic manipulation.
> Features: previews, step through images, rotate (and save), exif
> manipulation.
> Most of the current viewers fit more or less in this category.

 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, Gwenview's incremental 
loading and painting allow it to have things like a usable KPart but on the 
other hand probably cost it a couple percent of performance. That has nothing 
to do with how many features it has though.

>
> 3. Image organization. Not so much a viewer but closely related from the
> users perspective. From a simple folder layout to a database, depending
> on what the user wants.
> Kimdaba belongs in this category. Afaik digikam has such features as
> well.
>
> 4. Image manipulation. That's the other direction from 2.
> We have krita here.

 I don't think anybody really argues about this. It might be nice to have 
basic things like rotating or cropping in the viewer, but I doubt anybody 
expects pixel manipulations from a viewer. The same way last time I checked 
Krita, Kimdaba and Digikam were pretty useless for finding out a specific 
icon under /opt/kde3/share/icons.

> I'm sure other people can come up with different feature combinations.
> That's ok as long as we keep the whole hirarchy in mind. And even more
> important: make sure that the different applications interact properly.
> Can't rotate in the basic viewer? No problem, the enhanced viewer is
> just one click (or shortcut) away.
> You find an photo with red eyes while browsing an image folder? One
> click to open it in krita.
>
> And don't forget that some people want standalone applications while
> others prefer everything embeded in konqueror.

 2 can of course also provide a KPart. Just because we haven't managed so far 
to have a better solution for 1,2 and KPart than including both KView and 
Kuickshow that doesn't mean it has to stay that way.

 Anyway, I expect this problem of the general image viewer will sort out 
itself sooner or later. You may think that Kuickshow should stay because it's 
magnitudes faster than Gwenview (which is nonsense BTW unless our definitions 
of magnitudes greatly differ) but the real difference that will matter in the 
end is that Gwenview a year ago was a worse image viewer than it is now and 
Kuickshow wasn't.

> There is no one right way 
> to do it.
>
> michael

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/




More information about the kde-core-devel mailing list