Summary: | Make CDArchiving tool work when ImageCollection!=Folder | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Jean-Michel Fayard <jmfayard> |
Component: | Plugin-Generic-Archive | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | caulier.gilles, davidf |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 0.1.0 | |
Attachments: |
Preliminary patch
Patch against current CVS |
Description
Jean-Michel Fayard
2004-09-13 10:33:27 UTC
Created attachment 7502 [details]
Preliminary patch
http://www.stud.uni-karlsruhe.de/~upaxe/Images.tar.gz 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 : test_image.jpg_1 test_image.jpg_1/image.jpg test_image.jpg_2 test_image.jpg_2/image.jpg 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 <cdrom>/<keyword>/image1.jpg <cdrom>/<keyword>/image2.jpg 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) http://www.stud.uni-karlsruhe.de/~upaxe/temp/a.dir.tar HTMLInterface/(base folder)/pages/test_latin1_àéèù.jpg.html 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 : http://www.stud.uni-karlsruhe.de/~upaxe/temp/b.dir.tar 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 Description: 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..." comment 7 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 |