Many of you have been waiting for this one. Carsten Pfeiffer wrote in to tell us about the first release of KuickShow since KDE 1.1.2 in July 1999. KuickShow is a nice image viewer based on Rasterman's Imlib, and in case you don't remember, the killer feature of KuickShow was its blazing speed. You won't be disappointed by the latest release for KDE 2.1 -- I was blown away. It's even noticeably faster than the venerable XV (hint: command line geeks should use KDE Init for that extra speed boost, others benefit automatically). You can get KuickShow here, view a couple screenshots (1, 2, 3), or view the ChangeLog. Depending on your feedback, binary RPMs may soon be made available. Read on for the details from Carsten.

Some of you might remember an ancient program called KuickShow, a nice and very fast imageviewer for KDE1, last released in July '99. Due to other projects, the significant changes from KDE 1.x to 2.x, and a rewrite of KuickShow internals, the new version has been delayed until now.

At least Imlib didn't change. :) Yes, KuickShow uses Imlib to load and display images, and that's one of the reasons for KuickShow being so fast. It also supports a lot of image formats, even some Photoshop *.psd files work.

The new KuickShow 0.8 works pretty much the same as the last version. You have a filebrowser to select the images to display. But IMHO, the best way to browse image galleries is to open an image, hit Return to toggle into fullscreen mode and then press PageUp/Down/Home/End to navigate between images. This is all amazingly fast, of course, have I mention that, yet? :) You say you won't download anything before you've seen a screenshot? I wouldn't either, so here they are.

Now if you want to view images kuickly, here's what you need:

Requirements:

kdelibs 2.1 (2.0 won't work)

Qt >= 2.2.3

Imlib (together with libjpeg, libpng, libgif/libungif, libtiff)

Oh and don't forget KuickShow!
Currently there is only a tarball and source-rpm (use --prefix=/where/your/kde/is/installed unless your KDE lives in /opt/kde2) available.
I'd like to get some feedback about this version and will try to get some binary RPMs ready if nothing serious needs to be fixed.

If you used the old KuickShow for KDE1, you might stumble over a couple of things:

the ".." entry in the filebrowser that took you into the parent directory is no longer available. Just as in the filedialog or in Konqueror, use Alt+Up (or the toolbar button) to change into the parent dir.

the change-directory shortcut & menu entry was removed. Simply start typing a filename or a directory name in the fileview. A small editfield will pop up to assist you.

Of course this is all mentioned in the documentation, but I'm betting that nobody's going to read that ;)

You give a partial answer with your next question : because even Gnome has thrown it away. A more complete answer is that the API really really sucks, and trying to make a reasonable wrapper for C++ is a huge PITA.

hmmm, that is an interesting suggestion. I would like to turn on "preview mode" for graphic files, but that would be too slow in large directories. I think if the kde folks could integrate imlib or kuickshow into the preview function, that would be great. I like the preview function now as it is... however, if there is something better then why not?

Concerning speed of Imlib2... for Enlightenment it might make a difference, due to all the effects, animations etc., but in an imageviewer it does not make a big difference. I did a quick port of KuickShow to Imlib2 and it's not obviously faster.

Don't get me started on the new API :-/

Regarding Imlib1: I've been using many versions and the only requirement ever was to use a version >= 1.5. The Xlib version hardly got any changes at all. That said, I do have problems with 1.9.8 under Openwin (Solaris7) currently :}

I think a tool like KuickShow is really a must-have for KDE, and honestly, I don't really care what lib it is build on, as long as it works nice & quickly.

I do think that unfortunately, the UI of kuickshow is a little flawed. Under windows, I've gotten to know & love ACDSee, IMHO the best image viewer available. Carsten, if you read this, please take a look at the attached screenshot, and if you'd like, let it inspire you ;)

That's the netscape one (aka the ugly one), right? ;) This one is used to show that you are able to "click" on something, e.g. a link, while in KuickShow, I need one showing that you can "move" something. Photoshop uses an open hand, and I'd like to use something similar.

I downloaded the other imageviewer as pointed out somewhere above and I'll probably use that one.

yes, ACDSee has evolved quite a bit since I stopped using it (and Windows) in '98.

The directory tree from your screenshot might eventually be available automatically with KDE 2.2 (KuickShow uses the kfile library which will probably get a directory tree, soon). I do plan to add thumbnail support as well.

I don't really see the need for the preview tho. The thumbnails do provide a small preview already. If you select a thumbnail, you get a medium-sized preview? Why that? Why not show the full image?

Thanks for your reply! Since I see you're interested in suggestions, I would like to tell you some more features and things I'd love in KuickShow.

I work at a photographer, and there's a huge archive of pics, so a viewer like this is really a must. First, I think its wrong to have the app split up into several windows at the same time, one of them always resizing when you select a different picture. I think i'd be great when you either had to double click or selecte&ENTER a pic to change from thumbnail preview (with dirTree & preview) to fullscreen single-pic mode with zoom feature.

Also, another must-have feature is the creation of contact sheets. These are basically thumbnailpages, just for printing. It would be nice to be able to select how many rows & columns of pictures should be on a page, and determining the thumbnail size from that. Also, one should be able to optionally title the pics with their attributes (filename, size, format etc.)

The preview pane: It does make sense. Besides being configurable (you can kill it), this preview panes obviously allows you to view some more details of the pictures. This is very helpful, since (at least where I work), pictures only differ by a few small details, and this is the place you can find that out, before you have to load the full picture. This really isn't fun when you're working on a 200MB tiff.

Ermm, also: Wouldn't this be a great place to integrate thekompany's gphoto io-slave? I dunno how, but it kinda fits in there from the user's perspective...
Of course, all of KuickShow could also be a KPart, integrated into Konq, but I think this is going a bit too far.

For the contact sheets, I see your need for it and agree it's a nice thing, but it is somewhat specialized (in another thread, it would be called bloat ;) I could add a plugin architecture so those sort of things could be added without affecting others. Actually, there is a kimgalleryplugin for Konqueror, which could be extended to do such things. Currently, it generates an html-page with all the images in one directory.

For the gphoto-ioslave, I will add support for that and remote files before 1.0

For me, a main focus of any image management program imust be the ability to manage (do things to) large numbers of pictures at once. I almost never use thumbnails because they consume too much space in the file list widget without providing enough detail to tell me whether I want to include a photo in a selection (to move, delete, whatever.)

A preview isn't necessarily just a "medium-sized preview"; it's the real picture, shrunk if necessary to fit into the preview pane (which in my case is usually about 640x480.) The benefit, though, is that you can see the pictures, often at full resolution, while extending a selection.

So rather than having to go down-enter-look-^W a bunch of times and then remember where I wanted the selection to start, I can just go shift-down until I find a picture I don't want to include in the selection, then press shift-up and then the hot key for delete, move or whatever. It makes management of large image collections MUCH easier.

Mind you, no X11 image browser that I'm aware of will do this currently. I had high hopes for both Konqueror/pixie and Nautilus to provide this sort of functionality, but neither to date has done so.

I wrote a simple patch for GQView, a C/gtk image browser (http://gqview.sourceforge.net) to provide this sort of functionality -- it has a "preview pane" which makes up the bulk of the interface, but selecting via the keyboard in the official version doesn't update the preview pane -- but my two patch submissions were never acknowledged. If anyone has used gqview and would like my patch, I'll gladly email it. I'd be happy to help out with KuickShow in this regard, but (so far) I am allergic to C++.

I've also written a program in perl/ImageMagick to find images that look like duplicates, and wanted to port it to C/Imlib some time ago but the documentation for Imlib seemed to be nonexistent. I think that's another important part of image management and something that (last I knew) ACDSee doesn't even provide. If you're ever interested in adding that kind of thing to Kuickshow and have trouble figuring out my lame algorithm, drop me a line.

But anyway, that's why I think a preview pane is more important than even thumbnails in an image management app.

You start a slide show. Then, somewhen, you decide you don't want that slideshow anymore, so you move the mousewheel. ACDSee reacts and shows the next picture when you move the wheel down, and the previous if you move it up. But the slideshow is stopped once you moved the wheel and won't start again until you explicitly tell ACDSee to do so.

Actually, this wheel-navigation-feature is quite independent of the slideshow. When you are in single-pic mode (as opposed to thumbnail&dirtree&preview - mode), you can view the next/previous pics with the wheel. Nothing more to it ;)

Of course, the best thing would be to let the user choose whether using the wheel should stop a slideshow...

>It advances to the next/previous image without stopping the slideshow?

Yes, open a folder with pictures, click on any one of them and scroll through the whole collection with the wheel, extra double-quick!
Or, left-click on the folder, choose "Browse with ACDSee", double-click on any thumbnail, and scroll the collection.
It works automatically with Logitech MouseMan Wheel, the only mouse worth buying.
I strongly advice that you check out this great programmme, free evaluation version.

By the way, mouse support in KDE 2.1 is just as bad as it was in KDE 1.0 beta, so I don't expect much. After all, *nixers are real men and real men don't use mice ;-) (Yes I know this is an XFree86 thing rather than KDE thing)

Definitely. I think everyone wants an ACDSee style program. I actually wanted to start a project like this, but it looks like I don't need to now. =)

My only real quibble is that the UI is a bit strange. If I use the file dialog, then it doesn't go away when I load an image. If I launch an image directly, then I don't get the file dialog (is there a way to bring it up?)

Both Kview and Pixie have similar issues with UI. Maybe I'm just used to ACDSee. IMO, the best part about ACDSee was that it was quick and was associated with every image type. No more loading huge image programs just to view one file. I just click on one, and navigate with pageUp/pageDown. ACDSee is actually quite more than that, but I believe most of it is probably unnecessary. The program has since doubled in size since I last downloaded it. Bloat anyone?

I wonder if there should be some organization between Kuickshow, Kview, and Pixie. Kview and Pixie seem to be confused, as they share some features, and not others. I think we should have just two programs: Kuickshow (which is what Kview probably should be) and Krayon (for editing).

> Definitely. I think everyone wants an ACDSee style program. I actually wanted to start a project like this, but it looks like I don't need to now. =)

Well, contributors are always welcome :)

> If I use the file dialog, then it doesn't go away when I load an image. If I launch an image directly, then I don't get the file dialog (is there a way to bring it up?)

You can press Space to toggle showing the filebrowser. When launching kuickshow with an image as parameter I don't want to see the browser (I give it an image on the commandline to... well, see the image). If you give it a directory on the commandline, it will open the browser in that directory.

> ACDSee is actually quite more than that, but I believe most of it is probably unnecessary. The program has since doubled in size since I last downloaded it. Bloat anyone?

That's my impression, too. The early versions had all the functionality I needed and it was very fast and loaded quickly. Maybe others need all the new functionality, but for me it was just slowing it down.

> I wonder if there should be some organization between Kuickshow, Kview, and Pixie. Kview and Pixie seem to be confused, as they share some features, and not others. I think we should have just two programs: Kuickshow (which is what Kview probably should be) and Krayon (for editing).

This differences between these programs are:

KView as a standalone program has about the same functionality as KuickShow. I think it has a few things KuickShow doesn't, like Wallpaper generation for example, but this can be added to KuickShow easily. But, KView also offers an embeddable KPart, used in Konqueror for example. I won't make a KPart of KuickShow, because it just doesn't make sense. Embedded into another app, you lose all the advantages of KuickShow (fullscreen, the filebrowser, switching between the files via PageUp/Down, resizing the image window).

The author of KView had the idea that we might use KuickShow as the standalone imageviewer and KView as the embeddable part in KDE.

With Pixie, the main advantages IMHO are the plugins/effects/image editing capabilities. I don't personally need such stuff (when I do, I use Gimp at the moment, and later probably Krayon).

True. PMView remarkably won best image viewer one year over all windows offerings when everyone thought OS/2 was dead. They also produced a windoze version too. It was one of the best things on OS/2. Well worth looking at for anyone designing an image viewer.

Sometimes when I move from a very large picture (larger than my desktop) to a smaller picture, the smaller picture has a frame the size of the large picture. If I reclick the smaller picture, the frame is the correct size. The opposite happens sometimes when I move from a smaller picture to a very large picture. The window frame for the large picture is too small and the image is truncated. If I reclick the large picture the frame is the correct size. This doesn't always happen.

I use KuickShow in window mode and I use KWin. Maybe I need to update my KWin.

Hmm, this is KDE 2.1? I have noticed some problem where the frame could not be made smaller than a certain size, due to the WM dictating a minimum size for the decoration. But those problems you mentioned, I haven't experienced yet. Which decoration do you use and what size is your desktop and the image where this is happening?