Most people agree that the K3b CD burner is an application done right -- it looks good, is not overly complicated, and most of all "just works" -- the fact that Novell adopted it for Novell Linux Desktop is icing on the cake. Well, the Katalog CD Organizer, a possible cousin to K3b, is KDE integration done right. People may know of gtktalog and cdcat, both are fine applications; Katalog, however, is more of a plug-in for KDE. It works by right-clicking and cataloguing a directory or external media to a XML data file. There is a katalog ioslave for viewing katalog files as if they were native file structures. Delete, rename, and even the find dialog works on the files. This program is, in my opinion, a fine example of how a program can be integrated into, and built upon, KDE's strengths.

Actually I am thinking about a way to organize my photo-cd/dvd:
My photos are organized in folders or to speak in digikam terms, in albums.
Katalog seems to make it easy to have a local database that shows what DVD I must put in my drive to load a certain jpeg file.

Ok, but what happens if I edit my image or delete a file and I want to make a catalog of the same folder again?
Does Katalog use hash file information and knows 90% of my folder content is already on a disk? Does it support k3b and generate project files for differential backups?

Katalog looks great. As far as integrating with KDE the developer did superbly. I would like to say though that in my [humble] opinion this is the wrong place to implement the nuts and bolts of a project like this. The metadata belongs integrated with the file system. With integrated metadata and something like views in databases this could be done in a much more efficient way. The same goes for ioslaves, they don't belong in the desktop environment they belong in the OS (i.e. userspace filesystems like FUSE).

I'm not flaming here. It's just my opinion from an overll system engineering point of view.

I believe that kde ioslaves can be mounted in FUSE, so in a sense they're already at the OS level.

However, I agree that better userspace filesystem support is needed. Unfortunately, all the projects like PerlFS seems to have died -- there doesn't seem to be a good way to write a filesystem in Perl that works with a 2.6 kernel as far as I can tell.

Its always been a goal of KDE project as a whole to work on a variety of platforms.

But I guess I basically agree, ioslaves should really be part of some OS standard like POSIX, it would make things so much easier if there was that level of network transparency system wide. Fuse is the right idea at least.

When having found a file/dir in a catalog, I'd like to click at
it and have my OS show a requestor to insert the appropriate
media (by name). And then access the file/dir from the point in
the directory tree where I hooked the media in.
Dreaming of old Amiga days... here it would fit 101 percent.

Not more difficult using checkinstall, but it does not produce particularly good results. The RPMS you create sometimes get really weird dependencies and usually they don't install as cleanly as a correctly built RPM. Personally I stay away from RPM's created by checkinstall as nearly always create problems then they are worth. Checkinstall is a good tool to use when installing from source on a machine, allowing easy uninstall with RPM. But not as a tool for creating RMPS for distribution.

Weird in the way it seems to depend rather heavy on what the creator of the RPM has installed. Sometimes you get dependency of some packages I find quite obscure, as in no real reason to depend on it for this program.

The most common case I have encountered are GUI programs ending up depending on files from the NVidia package, witch are bad news when you try installing on a machine with a different card.

Since it got that info via ldd, that binary *does* depend on NVidia libraries.

Since the NVidia libs should be binary-compatible with Mesa(1), it should work without them, though, but checkinstall can't guess when that happens and when it doesn't.

If you want to try your luck, just use --nodeps. If it doesn't work, remove it.

The reason why the slackware package works is simply that it doesn even try to check if the system has all requirements installed. It should fail 9 out of every 10 times on random computers, unless they are configured similar (or the app is very simple).

> The reason why the slackware package works is simply that it doesn even try
> to check if the system has all requirements installed. It should fail 9 out
> of every 10 times on random computers, unless they are configured similar (or
> the app is very simple).

I haven't read up on the full blown autopackage format. I'm just using their gcc wrapper, apbuild, which:

1. removes false dependencies libtool leaves in (e.g. if my program depends on Qt which depends on pthreads, that doesn't mean my program depends on pthreads - it doesn't care how Qt is implemented)

2. compiles against glibc 2.2 (so it'll run even on a very old system as long as the C++ ABI is the same as mine)

3. statically links in a handful of libraries that you can't depend on people having in dynamic form e.g. Xrender (< 100K total)

And then assuming you check your remaining dependencies (and they'll be few of them), you have a fairly portable binary. IMO, this is the future of how 3rd party software will be distributed under GNU/Linux.

The experimental binary package I have up there is basically an apbuild job with a wrapper script (for setting KDEDIRS). There are still a few gltiches I will iron out - disable RPATH, fix khelpcenter documentation (KDEDIRS isn't being picked up by kio_help unless you set it before KDE startup) and a BIC with KMainWindow::setCaption()).

Many thanks to Phoenix for the review of my software and to the KDE Team for the best software I ever seen. Using the KDE technologies I was able to reproduce almost all the feature of other similar programs using one tenth of their lines of code.

About the questions:

>Ok, but what happens if I edit my image or delete a file and I want to make a >catalog of the same folder again?

You have to recreate the katalog.

>Does Katalog use hash file information and knows 90% of my folder content is >already on a disk?

No :-(

>Does it support k3b and generate project files for differential backups?

No, Now Catalog creation integrates nicely only in Konqueror (and in Konsole, thanks to DCOP interface). Anyway you can browse katalog from any ioslave-aware application.

>The metadata belongs integrated with the file system

I agree, but the current technology does not permit such an integration easily. Think to katalog as a more integrated solution than the stand alone applications such gtktalog and a less integrated solution than the FS support of meta-data.
Furthermore I think that applications like Katalog are the only solution for removable media.

>tellico

This is a great application which I use, but is for a different use. When you would to store the contents of the CD of your favourite Linux Magazine, Nothing is better that Katalog (or gtktalog, or cdcat, or ...)

the "create katalog" action asks for a name for the katalog, then correctly mounts the device and ...hangs. my cpu is at 100% and nothing happens untill i kill the katalog dcop call.

it works flawlessly when operating on mounted /media/cdrom, same CD, same configuration.

wishlist:

* you could create a standard *.katalog repository, something like ~/.kde/share/apps(?)/katalog/ - so that just the name for the katalog is asked in the dialog (+ options of course) - it could be a katalog file itself, when renaming/removing items from catalogs is imlemented!

* typing just "katalog:/" in konqui's location bar could show you all of the catalogs (or the default katalog file - read above) in the standard katalog repository for *easy* browsing