Criteria for an imageviewer

Torsten Rahn torsten.rahn at credativ.de
Fri Jun 3 12:06:04 BST 2005


During CeBIT 2005 certainly one of the biggest complaints was the lack of a 
decent imageviewer. From the user's point of view we don't have any good one. 
(By user I don't mean programmer's which only have _very_ basic needs in 
terms of image-viewing but realworld users).

An ideal imageviewer should:
 
SPEED:
Load images blazingly fast -- no matter how large they are. If they are very 
large the imageviewer shouldn't load the whole image but only the amount of 
data which is necessary to display the actual view of the image if possible.
 
If you want a rather extreme testcase use this as a reference:
http://photojournal.jpl.nasa.gov/tiff/PIA03377.tif
- If loading takes more time (it shouldn't) the desktop should never become 
unresponsive and it should be possible to cancel the loading immediately.
- The same that was said for loading should also be true for navigation (zoom 
e.g.).

PRINT:
If the user wants to print the image just printing it 1:1 by taking into 
account the display and printer resolution doesn't cut it at all.
Many users want to be able to:
- either enlarge it so the image covers the whole paper.
- position and scale the image on the printout. This does _not_ mean that he 
wants to actually scale the image to gain the proper size but he wants to be 
able to interactively decide which size the image should have on the paper. 

The best way to do this is to have an appropriate print-dialog which shows a 
small preview of the paper as well as the image itself. On this preview the 
user should be able to adjust the position by doing drag and drop of the 
image-thumbnail on the paper preview. Scaling should work by drag and drop of 
the corners of the image-thumbnail. If you don't know what I'm talking about 
have a look at the print-dialog of most (semi-)professional Windows Viewers 
or Imagemanipulation-tools (I think Corel Photopaint has something like this 
e.g.).

Such a print-dialog should be shared between Krita, the Imageviewer and 
Digikam (Actually there is much more stuff which should be shared between 
these).

USABILITY:
An Imageviewer is a central piece of the desktop so good usability is 
mandatory. The imageviewer itself shouldn't be cluttered with lots of 
menuentries, options and the user shouldn't have to deal with multiple 
windows which exist next to each other and which have to be managed by the 
user himself (Pixie which is one of the better apps has some weakness here).

Switching between "fullimage view" and the View which shows the image with 
actual pixels or the  current "zoom level" should always be possible in an 
_obvious_ manner.

It should be possible to do basic navigation (up, down, .. rotate, zoom) using 
the mouse as well as the keyboard.

INTEGRATION:
Various users have voiced some irritation with regard to how the imageviewer 
in konqueror (the imageviewer component) is related to the "external" 
imageviewers. (is it the same application? And why does it act so rudimentary 
then?).  Having larger images loaded into khtmlimage is an annoying 
experience to say the least btw. ...

FURTHER TASKS:
Some people think that imageviewers should also be able to do
 
- basic imageconversion/transformation/manipulation (e.g. pixie, digiKam)
- dia shows
- image management/search/metadata (e.g. kimdaba)

The whole menu options for these tasks shouldn't appear in the interface by 
default. In fact it might make sense to have two or three prominent buttons 
in the interface which say "imagemanipulation" and "dia show" which enable a 
different mode of the imageviewer which enables the user to do what he wants 
to accomplish. Consult your favourite usability expert to refine this 
strategy.

NAME:
The Imageviewer should have a nice name. Ideally it should be somehow 
self-descriptive or at least meaningful. And it shouldn't sound like a 
pr0n-viewer or a viewer that was just created to view images of the 
girl-friend of the respective programmer ;-) On the other hand it shouldn't 
sound too technical (kview isn't something that would be easy to market as it 
sounds boring :)
This is a marketing aspect. Contact kde-promo e.g. for further assistance.

ARCHITECTURE:
To the user this topic is by large absolutely not relevant. But I'm confident 
you'll come up with brilliant ideas with regard to the architecture 
nevertheless ;-)

Am Freitag, 3. Juni 2005 10:47 schrieb Lubos Lunak:
> On Wednesday 01 of June 2005 16:45, Matthias Kretz wrote:
> > Carsten Pfeiffer is/was the maintainer for Kuickshow. And I haven't seen
> > him mainting his app lately.
> >
> > I'd like to see an application moved from extragear to kdegraphics that
> > has a KPart for showing the image embedded in Konqueror. Gwenview and
> > ShowImg are both good candidates.
>
>  Yeah, let's have a my-app-is-the-best flamewar :). Currently, if I'm not
> mistaken, we have:
>
> - khtmlimage, in kdelibs, very simple, only KPart
> - kview, in kdegraphics, unmaintained according to this thread, both app
> and KPart, no thumbnails
> - kuickshow, in kdegraphics, unmaintained as well, only app, no KPart
> - gwenview, in extragear, both app and KPart
> - showimg, in extragear, both app and KPart
> - pixieplus, in nonbeta, seems to be dead again, only app
>
>  There are also digikam and kimdaba in extragear, but they probably don't
> qualify, since they're image databases rather than viewers (at least I have
> no idea how to browse e.g. /opt/kde3/share/icons with them).
>
>  So I guess it would make sense to dump the kdegraphics ones and move one
> of the extragear apps there (some people don't even consider extragear apps
> to be "real" KDE, e.g. #93611 got reopened only because the person didn't
> feel like installing something more than just KDE).
>
>  The question will be, of course, which one to choose. I pointed out this
> discussion to the Gwenview maintainer and he said he would love to see
> Gwenview becoming the default KDE viewer, but I guess the other candidates
> would say the same. What should be the criteria for choosing? Even if we
> don't choose now, it would be at least good to have such a list, so that
> the app developers can improve the parts where they currently lack.
>
> > On Wednesday 01 June 2005 16:11, Renchi Raju wrote:
> > > just curious, is kuickshow still being maintained? Additionally it has
> > > some usability issues, for eg, actions being available only from
> > > context menu/keyboard-shortcuts and some additional problems like
> > > swapping out the system at large zooms.
> > >
> > > imho, it might be worthwhile to ask the author of one of extragear
> > > apps, gwenview or showimg, to consider moving into kdegraphics (only
> > > relevant if kuickshow has no current maintainer).

-- 
Mit freundlichen Grüßen / Kind regards,

        Torsten Rahn

--
Dipl.-Phys. Torsten Rahn, credativ GmbH
Karl-Heinz-Beckurts-Str. 13, 52428 Jülich, Germany
Tel.:  +49 (2461) 6907-91
Fax:   +49 (2461) 6907-11
Mobil: +49  (160) 7452624
Email: Torsten.Rahn at credativ.de




More information about the kde-core-devel mailing list