[KPhotoAlbum] Two patches: max megapixels in search dialog, speed up remove from database

[Robert Krawitz]

I've attached two patches that both came out of some work I'm doing on
a script (currently two separate scripts, one for index.xml and one
for exif-info.db) to merge data from two databases (especially since
my experiments with import were less than rousingly successful).

The scripts themselves (which I'll send in prototype form, and which
I've been discussing with Johannes) are reasonably fast.  Merging two
index.xml files of 220K images takes a little over a minute on my
laptop, with a sluggish (by contemporary standards) i7-920XM CPU;
merging the exif-info.db files is considerably faster, although I
haven't measured it.  Either way, it's plenty fast enough for me to
use on a routine basis after a shoot.

1) Add a maximum megapixels spinner to the search dialog in addition
   to minimum megapixels.

   The maximum megapixels came up because I noticed a lot of files had
   width and height of -1.  That looks like it happens if the
   index.xml file is saved without having viewed the images in
   question.  The easiest way I came up with to solve this on the fly
   was to search for images of size less than 1 megapixel, and view
   them.  That's not a very elegant use case for this, but as a
   general matter, being able to search for images smaller than a
   certain size might be useful more generally, and besides, there's
   the issue of orthogonality.

2) Greatly speed up removal of images from database by using a
   transaction for the EXIF data and effectively the same thing for
   the thumbnail cache.

   Both of these operations are currently performed one file at a time
   rather than as a transaction.  The case of re-creating the EXIF
   database was resolved with commit 62b2060 in January of last year;
   this resolves the same issue for deleting files.

   There should be some kind of error handling for removal from the
   EXIF database, but I'm not sure exactly what's best.  Failure to
   delete a record because the record isn't already present should not
   be an error.

   I suspect the same issue is present with adding files to the
   database, but it may be less apparent because the process of
   reading files in is already very time consuming and I/O-intensive.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-patch-max-megapixels.patch
Type: application/octet-stream
Size: 5639 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20170529/0cf9695c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-patch-fast-remove.patch
Type: application/octet-stream
Size: 14290 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20170529/0cf9695c/attachment-0001.obj>