KuickShow for KDE 2.1

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.

Carsten Pfeiffer writes:

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

Thanks,
Carsten

Dot Categories: 

Comments

by sarang (not verified)

Cool.. but if Imlib is faster than Qt image loading, then why dosn't KDE use it everywhere? Even Qt can look at their code and make their code faster!

Also, wouldn't it be great if konqueror had an option "View the current directory using KuickShow" option! konqueror is pretty slow for directories with 100s of images IMHO.

good work!

by Kirby (not verified)

Yeah, why doesn't KDE use Imlib?

BTW, Gnome has developed Gdk-Pixbuf, which is even faster and superiour to Imlib.
Why doesn't KDE use Gdk-Pixbuf?

by Guillaume Laurent (not verified)

> Yeah, why doesn't KDE use Imlib?

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.

> Why doesn't KDE use Gdk-Pixbuf?

Integration, code consistency, stability, documentation, etc...

by Kirby (not verified)

"because even Gnome has thrown it away."

"Even"? Anyway, why does KuickShow use it if Imlib is too bad?

"the API really really sucks"

Then write a C++ wrapper with a good API.

"Integration, code consistency, stability, documentation, etc.."

What's wrong with the integration, code consistency and stability?
Just because it's 0.x doesn't mean it's unstable.
And what's wrong with the documentation?

by Guillaume Laurent (not verified)

> Anyway, why does KuickShow use it if Imlib is too bad?

If I recall correctly it was ok if all you want to do is load and display images. Trying to manage pixmaps was quite more painful.

> Then write a C++ wrapper with a good API.

Be my guest.

> What's wrong with the integration, code consistency and stability?

What's wrong with using a library which depends ona whole slew of others, and has a completely different API than the rest of the KDE ?

> And what's wrong with the documentation?

Last time I looked (a long time ago), the little that existed sucked big time.

by Kirby (not verified)

"What's wrong with using a library which depends ona whole slew of others,"

GDK and Glib are the only dependencies.
If you call 2 dependencies "a whole slew", then what do you call KDEBase's dependencies?

"Last time I looked (a long time ago), the little that existed sucked big time."

And just when was the last time you checked?

by Guillaume (not verified)

You're correct, there aren't that many dependencies. However does including GDK and GLib in KDE really makes sense to you ?

> And just when was the last time you checked?

More than a year ago. But you're right, Raster probably found the time to write a great doc for it while writing imlib2. :-)

by Carsten Pfeiffer (not verified)

Actually you don't need gdk or glib AFAIK. Imlib1 actually consisted of two libraries, one with GDK, one plain Xlib. I used the plain Xlib one.

With Imlib2, I don't even see any GDK at all.

by Bernd Gehrmann (not verified)

Apparently you lost track of the thread :-)
The previous comments were about gdk-pixbuf,
not imlib.

by Guillaume Laurent (not verified)

Well, no, I actually thought Kirby was still talking about imlib1 :-).

Oh well. That doesn't change much. While I agree that any of imlib[12] or gdk-pixbuf might make sense for an image viewer, using any of them in KDE would be a huge blunder.

There. :-).

by oliv (not verified)

BTW, Raster has developed Imlib2, which is even faster and superior to both imlib and gdk-pixbuf.
Why doesn't KDE and Gnome use Gdk-Pixbuf? ;)

by oliv (not verified)

BTW, Raster has developed Imlib2, which is even faster and superior to both imlib and gdk-pixbuf.
Why don't KDE and Gnome use Gdk-Pixbuf? ;)

by erotus (not verified)

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?

by Jean-Christophe... (not verified)

I tried Imlib2 (final) for enlightenment-0.17 (alpha version) and I can tell you that it's a lot faster than gdk-pixbuf and imlib1.

Imlib2 is appreciate on my slow computer ;-)

by Carsten Pfeiffer (not verified)

> I tried Imlib2 (final) for enlightenment-0.17 (alpha version) and I can tell you that it's a lot faster than gdk-pixbuf and imlib1.
>
> Imlib2 is appreciate on my slow computer ;-)

Ohh, Imlib2 is already released? Not a beta? I will certainly use that in the next versions, then.

Cheers,
Carsten

by oliv (not verified)

Imlib2 1.0.0 was realeased on October 16, 2000.
the latest one, Imlib2 1.0.2 was released on March 2, 2001
More details here:
http://sourceforge.net/projects/enlightenment/
and there
http://sourceforge.net/project/showfiles.php?group_id=2

Also, avoiding Imlib (1) is good because it's not really maintained, and there has been a fork between Gnomers' version and Raster's version, so getting help for might not be easy in the future.

by Carsten Pfeiffer (not verified)

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

by John (not verified)

Because if you where selling an API you wouldn't want to use LGPL code in it, that's the same reason that Qt dosen't use OpenOffice's Open2D printing API.

by Hajdi (not verified)

Damn right!!!
QT is GPL not LGPL.
You must pay for using it for commercial purposes.

by me (not verified)

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

Thank you very much for your work, it is highly appreciated!

by reihal (not verified)

I agree, ACDSee rules.
It doesn't use any stinking scrollbars either, it uses the hand cursor to shove the image around.
I wish Konqueror did that!

by Jelmer Feenstra (not verified)

Hmm, never smelled a thing when using konqueror to view images !

Well, whatever.

by Carsten Pfeiffer (not verified)

> I agree, ACDSee rules.
> It doesn't use any stinking scrollbars either, it uses the hand cursor to shove the image around.

As does KuickShow btw :) The only problem: I don't have a nice handcursor to show, so you have to scroll with the normal arrow cursor :-/
Anyone who can provide a nice handcursor?

Cheers,
Carsten

by reihal (not verified)

He, that was fast.
The hand should be Konqi's green, three-fingered hand, ofcourse.

(I don't like various bars stealing precious screen space)

by Carsten Pfeiffer (not verified)

> The hand should be Konqi's green, three-fingered hand, ofcourse.

Excellent idea :) Cursors in X can only have two colors tho :} Anyone feel like creating a bitmap of konqi's hand?

by anonymous (not verified)
by reihal (not verified)

Thats a Mickey Mouse glove, Konqi have two fingers and thumb, http://www.kde.org/img/logos/kdetshirt_release_small.jpg

by aleXXX (not verified)

how about Qt::pointingHandCursor ?

by Carsten Pfeiffer (not verified)

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.

by Carsten Pfeiffer (not verified)

Hi,

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?

Cheers,
Carsten

by me (not verified)

Hi Carsten!

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.

Thank you!

by Carsten Pfeiffer (not verified)

hmm, ok, I'm sort of convinced about the preview thing :)

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

by raindog (not verified)

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.

Rob

by reihal (not verified)

Another very cool thing with ACDSee: you can operate the slide-show with the scroll-wheel!

by Carsten Pfeiffer (not verified)

> Another very cool thing with ACDSee: you can operate the slide-show with the scroll-wheel!

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

by anonymous (not verified)

no, using the wheel does stop the slideshow. but in general, using the wheel to navigate in the pics is quite cool.

by Carsten Pfeiffer (not verified)

Ah, I see. And moving it again makes it continue. Is the direction significant, or is it just an on/off thing?

by me (not verified)

Huh? nonono, wait. The way it works in ACDSee is this:

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

by reihal (not verified)

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

by reihal (not verified)

Seems to be a misunderstanding, the rolling of the wheel IS the slide-show.

by Carsten Pfeiffer (not verified)

> Seems to be a misunderstanding, the rolling of the wheel IS the slide-show.

Oh, I see. That's just a one-liner, will add that :)

by Chris Bordeman (not verified)

Looks like the My Documents\My Pictures folder display on Windows 2000 uses the same layout as well.

by Justin (not verified)

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

Just something to throw out there! ;)

-Justin

by Carsten Pfeiffer (not verified)

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

by Marco94 (not verified)

Yep, the Freshmeat entry shows Imlib2 to be at version 1.0.1. BTW when it comes to image viewing, I still find nothing better then PMView. An "old" OS/2 favorite.

Marco.

by Eric Laffoon (not verified)

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.

http://www.pmview.com/

by jd (not verified)

Oh, man! This rules! :)

Seriously, I think my quest is over. Finally a good imageviewer.

Thank you, Carsten!

by KDE User (not verified)

KuickShow is great and very fast!

I've just noticed a small resizing bug.

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.

by Carsten Pfeiffer (not verified)

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?

by anonymous (not verified)

So, wouldn't it be a good idea for the trolls to look at the imlib-source and see what makes it so fast? I mean, they don't need to copy the API, do they?

I think it would be of great benefit to KDE, seeing how many pixmaps & png's KDE has to load for icons, web browsing etc.

Why?