image viewers: a different approach

[Benjamin Meyer]

On Wednesday 26 October 2005 8:50 am, Lubos Lunak wrote:
> 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.

I don't see the point of having both 2 and 3. 2 is just a subset of 3 and
so 3 can provide everything for 2 too.

> > 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

-- 
aka icefox
Public Key: http://www.icefox.net/public_key.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051026/01c820a7/attachment.sig>