[KPhotoAlbum] Latest patch

[Risto H. Kurppa]

Great functions, especially I like the possibility to skip RAW files.

Some questions:

- how do I apply a patch? Where do I extract it (I've built my KPA
from the SVN - to some of those folders?), what command to run to
actually apply the patch - and do I do this before or after make
etc..? So I'd be glad to have instructions that (and this:
http://www.kphotoalbum.org/download-svn.htm) would allow me to install
a patch..

-Do you make any documents for the patches? Does it also change some
help file or something? You said you made it possible to jump 10, 100,
1000 images. How to do this? You didnt mention it here so is it up to
user to try & find it or is it documented somewhere?

-Jesper - about how often you make these great patches part of the SVN
versions of KPA? Once in a month or so or only right before releasing
a new stable version?

Thanks!

r

On 7/8/06, Robert L Krawitz <rlk at alum.mit.edu> wrote:
> Here's my latest patch set.  This is the complete list of new
> functionality.  I probably won't have time to do much of anything more
> for a while.
>
> 1) A new option to permit smooth scaling vs. non-smoothed scaling
>    (which is much, much faster, particularly with large images).  I
>    think there's still an issue with image preloading sometimes taking
>    priority over responding to a user command in at least some cases
>    (so that sometimes there's a short pause that I don't think is
>    strictly necessary), but image display is a *lot* faster if smooth
>    scaling is turned off.
>
> 2) A new viewer option to permit showing image size in the info box.
>
> 3) A new viewer option to permit showing file name in the info box.
>
> 4) An option to allow specifying thumbnail size.
>
> 5) A new command in the viewer to zoom pixel for pixel (if the image
>    is larger than the viewer, of course :-( ) -- typing `=' will do
>    this.
>
> 6) Ability to scale to less than full screen.  This means that
>    displaying pixel for pixel will always display pixel for pixel, in
>    addition to the ability to zoom out beyond that point.
>
> 7) A new "standard size" setting, which can be one of three things:
>
>    * Full screen (the default, as today)
>
>    * Natural size (i. e. pixel for pixel)
>
>    * Natural size if possible (pixel for pixel if it would fit,
>      otherwise full screen).
>
>    In addition to being saved in the preferences, typing the `/' key
>    at any time will display the image at "standard size".
>
>    This isn't perfect.  In at least some cases it initially flashes
>    the image at full size before rescaling it up or down.  Fixing this
>    will require more extensive work.  In particular, doing most
>    efficiently will require reorganizing the cache so that it actually
>    keeps track of the image sizes rather than assuming that they're at
>    the display size, and the cache code in general will require some
>    work.  I probably won't have time to do this before I go back to
>    work.
>
> 8) New options to skip forward and backward by 10, 100, and 1000
>    images.  This was inspired by our 3500 photos from Alaska that
>    we're trying to categorize.  We did some of them last night, and I
>    want to restart in the middle (I know where we left off, but it's a
>    pain to find it in the thumbnail view and then select everything
>    from that point on).
>
> 9) The display code checks if the stored size is -1 (i. e. KPhotoAlbum
>    doesn't know what size it is), and fixes it up (and calls back to
>    the viewer to update the image box).  This could happen in cases
>    other than already-present thumbnails; for example, if you try to
>    view images for which thumbnails aren't yet created.
>
> 10) A new option to specify whether or not to load RAW files if
>    corresponding JPEG or TIFF files also exist.  Default is that it
>    doesn't, which is a change from the current behavior.  This is
>    useful with cameras that store both a raw image and a JPEG or
>    TIFF.  Related to this, I've changed the new image finder code to
>    pass the entire filename to canReadImage rather than just the file
>    extension.  I believe this is the right thing to do because it
>    allows the code to determine whether it actually can read the file
>    or not.
>
> _______________________________________________
> KPhotoAlbum mailing list
> KPhotoAlbum at kdab.net
> http://mail.kdab.net/mailman/listinfo/kphotoalbum
>
>
>
>