16 October, 2007

picture viewers & widgets

While writing stuff about KDE, you have to make screenshots. And often modify them basically (resizing, converting, stuff like that). So I get to play with some image viewers like Gwenview and showFoto and with image editors like KolourPaint & Krita. Kolourpaint and Krita are rather complementary. Kolourpaint, after all, is basic, quick and easy to use while Krita can do the heavy lifting. Gwenview and showFoto, do have more overlap, but Gwenview is faster, smaller and does the basics, showFoto is more featureful. Now I know there are more imageviewers in KDE (kview, kuickshow, and some third party things like squirelsomething) but I'm glad I don't have them installed - I'd rather see showfoto as fast as Gwenview, and I'd ditch Gwennie (or the other way around). Now Gwenview gets some love for KDE 4, and as far as I can tell, it's going to be the default imageviewer. Maybe. Why maybe? Well, I'm unsure - it seems Okular also wants to be an image viewer, right? On one hand - cool - annotation. But I'd rather then see the annotation stuff shared between KDE apps with Nepomuk or Strigi or something...

Now on to something more positive. Someone started a discussion on the kde usability mailinglist. It's rather long, but I became interested when the pretty pictures came. Someone pointed to this problem:

I found a solution which is already used in KOffice:

It looks pretty good, but there where some comments - discoverability isn't great. A right mouseclick is needed to be able to enter text, and it isn't obvious that it is possible at all. Plus, the guys wanted a drop-down. So Hans Chen made a mockup:

I'd say, with a editable combobox instead of a 'hidden' one on hovering (see top right mockup), it's great and should be the default zoom thing in KDE 4... ;-)


  1. It DEFINITELY should be the standard. It's great and just how it should be.


  2. it seems Okular also wants to be an image viewer, right?

    okular does *not* aim to be an image viewer - there's gwenview for that, not need to reinvent the wheel.
    Actually, the image backend might be even disappear for KDE 4.0. Don't count on it.

    But I'd rather then see the annotation stuff shared between KDE apps with Nepomuk or Strigi or something...

    I'd rather then see the annotation stuff really working in okular as it should, first.

  3. Well, Piontree, that's great to hear - as I think it'd be cool to have properly working annotation and imho an image backend would only be useful as long as there is no annotation support in Gwenview...

  4. Keep in mind that an annotation you create in okular is like not existing out of it - okular can *not* save annotations to the documents, yet.
    Futhermore, we don't (and don't plan to) support editing of images metadata.
    The image backend is just a *toy* - I repeat, don't count on it (and I won't stop repeating that ;) ).

  5. In my experience Gwenview is really slow to start and that's why I have Kuickshow as the default image viewer:

    Test Result:
    Gwenview 3.5 seconds cold start (not too bad after all).

    Kuickshow 0.5 second cold start

    I admit that 3.5 seconds isn't that long but compared to Kuickshow its feels clunky.

  6. About the start time of gwenview and kuickshow: Sure, gwenview is a lot slower, but the KDE 4 version got faster. And cold start doesn't happen often, esp if you also use it embedded in konqi...

    But improvements to startupspeed would be nice, sure.


Say something smart and be polite please!