Version: (using KDE KDE 3.2.3)
Installed from: Compiled From Sources
Compiler: gcc-3.4 -g
Description : CDArchivingPlugin is broken for an application where ImageCollection!=Folder. The HTML generation doesn't work, and the original pictures which doesn't belong to the same directory as the first picture in the image collection are not burned.
How to reproduce it:
Go to http://ktown.kde.org/kimdaba/snapshots/ and follow the installation procedure (doing export CFLAGS="-g " before is useful)
Copy the pictures attached right in your home directory and start Kimdaba
File>Archive to CD>Select all keywords, burn an iso in k3b and mount it with :
$ mount -o loop -t iso9660 <temporary folder>/CD\ Albums.iso <empty directory>
Patch attached : some preliminary work, basically remplacing each QDir dir = ImageCollection::path() with the equivalent ImageCollection. This also change the directory structure of <cdrom>/<folder>/image.jpg to <cdrom>/<keyword>/image.jpg
 : the name of the imagecollection in KimDaBa
Current problems :
* Maybe existing in the original plugin: pictures with latin1 characters doesn't show in HTML generation.
(/mnt/removable/HTMLInterface/inclassables/pages/28 - Mais oui elle est l%3F%3F, ma montre.JPG.html
/mnt/removable/HTMLInterface/inclassables/pages/28 - Mais oui elle est là, ma montre.JPG.html )
* Maybe existing in the original plugin : slow memory leak. KimDaBa used 95MB after generating a 600MO CD.
* For now, it doesn't try to copy recursively directories. I find it totally broken, because I have one picture in the top directory, it will copy all the top diretory, and then the others subdirectories again for the others keywords.
* Pictures can have many keywords in KimDaBa, so by design, one picture will be copied many times. Does K3B use symlink on a iso when it is possible (with Joliet or Rockridge, I don't know...) ?
* Note that because it now copies the images in a collection and not anymore all files in a folder, it cannot copy other files (comment.xml or whatever) in the directory. If this is a problem, we can use the new ImageCollection::isDirectory() and switch back to the old behaviour.
* Need to try it, and perhaps to make it work again with Digikam
That's all for now ;-)
Created attachment 7502 [details]
My test case for KimDaBa. This attachment is too big for bugzilla (1.7 MO), so I put it there.
Copy thoses files right in your KimDaBa base directory, so that you override the index.xml file.
Oh I forget something, but it should be clear by looking at the test case :
We need to handle the case when two pictures in two diretories have the same filename and the one common keyword.
Currently, k3b renames thoses pictures in
Either we prevent that ourselves, or we correct the HTML files.
Created attachment 7753 [details]
Patch against current CVS
Sorry for the last time, I did the change against an old version of the plugin.
Here is the version compiled against current CVS.
I know everybody seems to be moving home ;-), but please take a look, because
good news : the CDArchivingDialog now basically works with KimDaBa.
See the CD made by k3b with my testcase : (1.5 MO)
like I said before, this doesn´t work, but at least, that´s not my fault ;-)
The rare case where two pictures have the same filename is not handled for now,
but it´s so rare that we can give up for now.
And now the CD generated by k3b when your virtual albums are not folders (like by default) but Keyword (breaking the assumption album == directory)
You can change this so :
Menu Settings > Configure KimDaBa > General > Category vor virtual albums (choose Keywords)
The CD generated by k3b is here :
Additional note : As discovered by Jesper, newer versions of k3b require the "--nofork" to work, while older versions of k3b will return with an error if you pass this option. You need to auto-detect this, I hardcoded it for me.
See also bug 91651
This is that if the first image is in the top directory, all the files in that directory get put on the CD
I selected a set of images in kimdaba
I then ran the CD Archiving plugin.
It said that there was about 470MB of images. I clicked to continue
It took a long time to generate the thumbnails ...
When it got into k3b, it said there was 4 GB of images ... it had included all of the images (the whole directory)
It should have only had those items I had selected.
All of my images are in the same folder.
I tried the "Patch against current CVS" but it seems to break things - when I run the plugin K3b never appears, it just goes to "removing thumbnail images from temporary folder..."
An important other bug is that old versions of k3b requires no cmdline arguments while newer versions requires --nofork
and the plugin relie on this to work.
As I said somewhere, I hardcoded this for my version (--nofork), please try without that
*** Bug 98496 has been marked as a duplicate of this bug. ***
SVN commit 450825 by cgilles:
CDArchiving kipi plugin : patch from Owen Hirst
CCBUGS: 98269 89394 91651 100877 106568
M +490 -612 cdarchiving.cpp
M +16 -48 cdarchiving.h
M +6 -2 plugin_cdarchiving.cpp