I listened to your feedback, and made the most requested improvements in this version - without changing much of what you, as a developer, will need to implement in order to use MUPhotoView. Here’s a list of what’s new:
- Photo Removal Support: Whether you implement MUPhotoView via bindings or via delegate, the new photo removal methods will notify you when the user attempts to delete and give you a chance to modify the deletion set.
- Performance Enhancements: The view will draw scaled-down images during window resize, during selection, and during photo resize. This provides a huge speed boost. And if you want to alter the behavior at all - to draw regular photos during selection, for example - then simply modify or override the built-in NSView -inLiveResize method.
As always, full docs and source code included.
Click here to download version 1.1.
This version retains the sameCreative Commons Attribution-ShareAlike 2.5 license as the last version. This info and URL are included in the download.
Nice work, Blake. I like the new behaviors mostly. I think it’ll be worth looking at how to expire the image resizing faster so there’s an immediate de-blurring when the user releases the slider. Also, it doesn’t seem fair that the images should have to blur when doing a selection, since there is no image resizing going on. I think there’s a disconnect for the user since there is no blurring when scrolling, for example.
Actually I think the performance is pretty good, even resizing the whole view, when I turn off blurring altogether. Granted, I’m on a Dual G5, but that’s quickly becoming a slow-poke in a world of zippy Intel Macs
I debated about blurring during selection. I added it for two reasons: (1) for large images, selection can be VERY slow - I thought it was slow enough to deserve a solution. If your original images are small, this isn’t much of a problem, though. This is the case with iPhoto as well - but iPhoto has the benefit of storing multiple versions of an image, so in many cases, it’s using a smaller version, so the selection speed isn’t so bad; (2) Since the code is included, and there’s only one method to change in order to disable it, I figured that somebody using the code could turn it off themselves. Maybe I should have it be a binding/accessor in the future?
I’m getting a 404 error when I try to download the new version…
blake: any ideas why this might be happening?
Hey Michael - give it another try. Somehow I lost that whole directory while mucking around with another project on my site today. MUPhotoView is back up…
Thanks
Hey Blake, why does it take so long to show the images initially? Even a modest number of images (say 100) takes minutes on my machine.
I would really like to use the MUPhotoView in a project of mine but it needs to get a lot faster on loading. Are there any chances?
Cheers
marc
Hey Marc,
The view itself does not load any images - that’s something it defers to your application. If you’re using delegation, it directly asks for them. If you’re using bindings, it expects an array of NSImage objects. In both cases, it’s the app’s responsibility to load the images from their appropriate location - file, url, etc.
So any speed hit in the initial display is your app (or my app, in the case of the demo) reading the images from disk to start with. It should be fairly easy to NOT load them all at once - which should be pretty quick.
-Blake
Hi Blake,
I have an NSImage array created via initByReferencingFile: which actually takes no time as NSImage objects are loaded lazily only when needed.
Using setPhotosArray: somehow seems to force loading all of the NSImage objects even though this would not be necessary.
Cheers
marc
Hey Marc,
Every time the view gets a drawRect: call, it determines which photos fit inside that rect, and then attempts to draw them. When the view first displays, it’s probably getting a -drawRect call with it’s entire frame as the rect. You may be able to muck around the code and see if there’s a way to bypass that first draw and instead attempt to just draw the visible rect.
-Blake
Looks great - but what would be the shortest path to putting text beneath these? I may dive into the code but I’m sure you might have some pointers on the quickest route to putting –for example– the image name beneath the photo.
Steven - Hmmm, well, titles are my next “to do”. If you want it to be generic, then there are really 3 ways. The first is via bindings, by including another array of NSString titles. The second is by asking the delegate for the title at a given index. The third is somewhat new for MUPhotoView and involves looking for a title key inside one of the other, already bound, elements - i.e. allowing somebody to bind an object that provides an image and a title. I plan to try and provide all three methods and allow implementers to supply whichever works best for them… but since I have no idea when I’ll get around to adding that, please feel free!
Hi blake,
first of all thanks for this class, it’s really interesting!
Second i’ve noticed a bug (or better an unwanted behavior), when loading the photo in your view, the last photo is selected by begin (also in your demo), if i have time i will discover the problem and send you the patch, if you are more fast than me, i will be happy to use the revised version!
Bye
Whamoo - I’m not sure what you mean?